Avoiding Having Instances Change Class - Banking - Lecture Slides, Slides of Banking and Finance

Download Avoiding Having Instances Change Class - Banking - Lecture Slides and more Slides Banking and Finance in PDF only on Docsity! Avoiding having instances change class • An instance should never need to change class Docsity.com 5.5 Object Diagrams • A link is an instance of an association —In the same way that we say an object is an instance of a class Docsity.com When to use an aggregation As a general rule, you can mark an association as an aggregation if the following are true: • You can state that —the parts ‘are part of’ the aggregate —or the aggregate ‘is composed of’ the parts • When something owns or controls the aggregate, then they also own or control the parts Docsity.com Composition • A composition is a strong kind of aggregation —if the aggregate is destroyed, then the parts are destroyed as well • Two alternatives for addresses Docsity.com Aggregation hierarc ny Vehicle I 1 * * Chassis BodyPanel Door y l 1 1 * Frame Engine Transmission Wheel Docsity.com Notes and descriptive text • Descriptive text and other diagrams —Embed your diagrams in a larger document —Text can explain aspects of the system using any notation you like —Highlight and expand on important features, and give rationale • Notes: —A note is a small block of text embedded in a UML diagram —It acts like a comment in a programming language Docsity.com 5.7 Object Constraint Language (OCL) OCL is a specification language designed to formally specify constraints in software modules • An OCL expression simply specifies a logical fact (a constraint) about the system that must remain true • A constraint cannot have any side-effects —it cannot compute a non-Boolean result nor modify any data. • OCL statements in class diagrams can specify what the values of attributes and associations must be Docsity.com OCL statements OCL statements can be built from: • References to role names, association names, attributes and the results of operations • The logical values true and false • Logical operators such as and, or, =, >, < or <> (not equals) • String values such as: ‘a string’ • Integers and real numbers • Arithmetic operations *, /, +, - Docsity.com Genealogy example: Person name sex placeOFBirth dateOfBirth placeOfDeath [child Possible solutions Person name placeOfBirth dateOfBirth placeOfDeath | hill data@fDeath |* dateOfDeath |* aN teartngrasorall [p1,p2 | Parmer) o..2 fnplies plsex<p2.sex)} [y Woman Man Unien femakPariner|0..1 0.1 | malePariner placeOfMarriage ot dateOfMarriage | * * dateOfDivorce Union O.1 placeOfMarriage [oorent dateOfMarriage dateOfDiverce Docsity.com 5.9 The Process of Developing Class Diagrams You can create UML models at different stages and with different purposes and levels of details • Exploratory domain model: —Developed in domain analysis to learn about the domain • System domain model: —Models aspects of the domain represented by the system • System model: —Includes also classes used to build the user interface and system architecture Docsity.com System domain model vs System model Contains elements that do not Contains elerments represent things in that represent Models only things the domain, butare things in the that willactually needed to build a Type of model domain be implemented complete system Exploratory domain model: Yes No No developed in domain analysis to learn about the domain System domain model: models Yes Yes No those aspects of the domain represented by the system System model: includes classes Yes Yes Yes used to build the user interface and system architecture Docsity.com Identifying classes • When developing a domain model you tend to discover classes • When you work on the user interface or the system architecture, you tend to invent classes —Needed to solve a particular design problem —(Inventing may also occur when creating a domain model) • Reuse should always be a concern —Frameworks —System extensions —Similar systems Docsity.com A simple technique for discovering domain classes • Look at a source material such as a description of requirements • Extract the nouns and noun phrases • Eliminate nouns that: —are redundant —represent instances —are vague or highly general —not needed in the application • Pay attention to classes in a domain model that represent types of users or other actors Docsity.com Identifying associations and attributes • Start with classes you think are most central and important • Decide on the clear and obvious data it must contain and its relationships to other classes. • Work outwards towards the classes that are less important. • Avoid adding many associations and attributes to a class —A system is simpler if it manipulates less information Docsity.com