INFO 620Lecture #81 Information Systems Analysis and Design Class Diagram Refinement INFO 620 Glenn Booker

INFO 620Lecture #82 Iteration 3 of Text Iteration 3 in Larman covers additional refinement of the design –Relating use cases (“include”) –Generalization of classes –Architecture analysis –Additional patterns –Frameworks

INFO 620Lecture #83 Generalization Generalization and specialization are refinements of the class diagrams –May apply to all types of class diagrams Want to use them to reduce duplication of code by exploiting inheritance First focus on conceptual classes, not software classes

INFO 620Lecture #84 Look for Similar Concepts To identify generalization, look for all of the concepts which are classes in your system Text example has three Payment classes, and two AuthorizationService classes Any time there are very similar classes might be an opportunity for generalization

INFO 620Lecture #85 Showing Generalization The open triangle shows generalization

INFO 620Lecture #86 Superclass versus Subclass A superclass is more general, vague, or broad than a subclass

INFO 620Lecture #87 The 100% Rule All attributes of a superclass must also exist for all of its subclasses All associations of a superclass must also apply to all of its subclasses –Subclasses may have associations not shared by the superclass

INFO 620Lecture #88 Generalization These diagrams both mean the same thing

INFO 620Lecture #89 Generalization Association The association between generalized classes is “is-a-kind-of”, or “is-a” for short –“CreditPayment is-a Payment” –“Subclass is-a Superclass” –Human is-a Mammal Notice that the reverse is not always true –“Superclass is-a Subclass” is incorrect! –Mammal is-a Human???

INFO 620Lecture #810 Why Generalize? Keep in mind the system focus for our analysis –If the classes are to be meaningful, they must help our system work better Create conceptual subclass when –Subclass has different attributes and/or associations –Subclass behaves or is handled differently

INFO 620Lecture #811 Abstract Conceptual Classes If every member of the superclass is also a member of one subclass, then the superclass is an abstract conceptual class –Payment is an abstract conceptual class iff the only kinds of payment accepted are credit, cash, or check Show abstract conceptual class by making the class name italics (check “IsAbstract” in Visio)

INFO 620Lecture #812 Changing States It may be tempting to define subclasses for different states of a class, e.g. Authorized and Unauthorized Payments Don’t! Instead, make that state a separate abstract class, with subclasses for each possible state (p. 408)

INFO 620Lecture #813 Inheritance Inheritance is when a subclass inherits the attributes and associations of its superclass Inheritance is heavily implementation language-specific, so it doesn’t apply to conceptual class generalization –Conceptual classes may be collapsed or expanded to become software classes

INFO 620Lecture #814 Class Modeling If a class C has many possible values of attribute A for a single member of C, put A in its own class associated with C –Person has many PhoneNumber –Sale has many SalesLineItem

INFO 620Lecture #815 Association Classes But sometimes that isn’t enough… A class whose existence depends on two other classes at once can be an association class, shown by a dashed line Usually an association class is needed for some attributes or associations Association classes can be used to bridge many-to-many associations

INFO 620Lecture #816 Association Classes Employment is an association class between Company and Person Association classes are also good for time-dependent associations

INFO 620Lecture #817 Aggregation When a class makes you mad, that’s aggregation. No? Aggregations are associations where the entire thing (called the composite) is made up of some number of specific parts Aggregations association are often left unnamed, since it would be “Has-part”

INFO 620Lecture #818 Composite Aggregation A composite aggregation is when the composite lives and dies with its parts –When the composite is created, so are the parts It is shown with a filled-in (black) diamond on the side of the composite

INFO 620Lecture #819 Shared Aggregation Shared Aggregation is very rare, occurs with non-physical classes It occurs when the multiplicity at the composite side may be greater than one Hence it is when the same part may occur in more than one whole at the same time

INFO 620Lecture #820 Aggregation Show aggregation when –There is logical or physical whole-part connection –The lives of the part and whole are linked –Properties and/or operations of the whole also pertain to the part When in doubt, leave aggregation out

INFO 620Lecture #821 Time Intervals Attributes which change over time, and you need to know that history of change, may need their own classes –Often needed for measurements, legal or accounting records

INFO 620Lecture #822 Association Role Names The end of each association is a role Each role can have a name to help clarify its purpose, if needed Role name is given in lower case This example is also a reflexive association

INFO 620Lecture #823 Modeling Human Roles Human roles (student, teacher, architect, etc.) can be modeling as an association –Store Employs-to-manage Person Or human roles can be modeled as classes –Store Employs Manager Since human roles can change fairly easily, and mutating one class into another is difficult, it is better to use the latter (classes)

INFO 620Lecture #824 Derived Elements Attributes and associations may be derived from other attributes and associations They should be avoided, since they add complexity – use when it’s a frequently used term Show derived status manually with a forward slash prefix

INFO 620Lecture #825 Qualified Associations Class A may show a qualifier through which class A associates with class B The qualifier is an attribute of the first class –Helps clarify the association (p. 422) –And may simplify the multiplicity Not the “primary key” description method

INFO 620Lecture #826 Ordered Elements If associated objects are in a significant order (sequence), the association can have the trait “IsOrdered” –Qualified and Ordered are both properties of the (end) role

INFO 620Lecture #827 Packages More info on packages… Each package “owns” the classes in it; can be shown by a class diagram inside package –May need to draw text box and rectangle around class diagram A package may reference classes from other packages using otherpackage::class notation (p. 424)

INFO 620Lecture #828 Packages Packages are grouped by: –Strong association –Same type of concept or purpose (functional) –Are in the same class hierarchy –Are used in the same use cases A package for common functions is often called Core

INFO 620Lecture #829 Package Dependencies Packages can depend on each other Dependency is shown by a dotted line with an open arrowhead Think of dependency as an association called “Uses”

INFO 620Lecture #830 SSD Update While developing the design class diagram, it can be helpful to re-examine the system use cases and sequence diagrams –Clarify what system operations will be needed to support generalization and other refinements –Clarify what calls to external systems are expected, both outgoing and incoming

INFO 620Lecture #831 Object Identity Recall that every object has an object identity (OID), which acts as its equivalent of a primary key Now we can define attributes and methods to allow each object to create other objects, establish associations with those objects, and later destroy them! (this is jumping a little into Chapter 20)

INFO 620Lecture #832 Reference Attributes Associations are implemented via reference attributes and their methods –They are essentially a foreign key Reference attributes are used for association forming Warning: Reference attributes are not shown in the text’s class diagrams!!

INFO 620Lecture #833 Reference Attributes Reference attributes are needed: –For a one-way navigable association, the side which does not have an arrowhead –For two-way navigation, on both sides of the association Methods are needed to use the reference attributes (e.g. add or delete associations)

INFO 620Lecture #834 Reference Attributes The type of a reference attribute is: –If B has multiplicity of one, the reference attribute in class A is of the type B –If B has a multiplicity >1, the reference attribute in class A is a “collection” – a container for multiple objects of type B

INFO 620Lecture #835 This clarifies Figure 20.3, p. 305 –Need reference attribute for SalesLineItem, since only it has no arrowhead –So productSpec is the reference attribute, of type ProductSpecification since multiplicity=1 Reference Attributes >

INFO 620Lecture #836 Reference Attributes Another example: –Let’s say a Customer wants to make a Rental (per Prof. Song’s video rental example) –Association is bidirectional, hence need both reference attributes and their methods