Date post: | 04-Jan-2016 |
Category: |
Documents |
Upload: | magdalen-hodge |
View: | 216 times |
Download: | 1 times |
INFO 620 Lecture #8 1
Information Systems Analysis and Design
Class Diagram Refinement
INFO 620
Glenn Booker
INFO 620 Lecture #8 2
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 620 Lecture #8 3
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 620 Lecture #8 4
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 620 Lecture #8 5
Showing Generalization
• The open triangle shows generalization
CashPayment
Payment
CreditPayment CheckPayment
INFO 620 Lecture #8 6
Superclass versus Subclass
• A superclass is more general, vague, or broad than a subclass
CashPayment
-amount : Currency
Payment
CreditPayment CheckPayment
Superclass
Subclass
INFO 620 Lecture #8 7
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 620 Lecture #8 8
Generalization
CashPayment
-amount : Currency
Payment
CreditPayment CheckPayment
Sale
1 1
Pays-for
CashPayment
-amount : Currency
Payment
CreditPayment CheckPayment
Sale
1
1 Pays-for
1
1
Pays-for
11
Pays-forThese diagrams both mean the same thing
INFO 620 Lecture #8 9
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 620 Lecture #8 10
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 620 Lecture #8 11
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 620 Lecture #8 12
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 620 Lecture #8 13
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 620 Lecture #8 14
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
Sale SalesLineItem
1 *
Contains
Person PhoneNumber
1 *
Has
INFO 620 Lecture #8 15
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 620 Lecture #8 16
Association Classes
• Employment is an association class between Company and Person
• Association classes are also good for time-dependent associations
Company Person
startdate : Datesalary : Currency
Employment
* *
INFO 620 Lecture #8 17
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 620 Lecture #8 18
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
BachelorsDegree Course
1 *
INFO 620 Lecture #8 19
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
Package Element
* *
References
INFO 620 Lecture #8 20
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 620 Lecture #8 21
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 recordsProductSpecification -starttime : Date
-endtime : Date-price : Currency
ProductPrice
* 1..*
Priced-by
INFO 620 Lecture #8 22
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 areflexive association
Person
-parent2
-child
*
Creates
INFO 620 Lecture #8 23
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 620 Lecture #8 24
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 manuallywith a forward slash prefix
-date-time-/total
Sale
INFO 620 Lecture #8 25
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 methodProductCatalog ProductSpecificationitemID
1 1
INFO 620 Lecture #8 26
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) roleSale SalesLineItem
1 1..*{ordered}
INFO 620 Lecture #8 27
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 620 Lecture #8 28
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 620 Lecture #8 29
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”
Sale Core
INFO 620 Lecture #8 30
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 620 Lecture #8 31
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 620 Lecture #8 32
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 620 Lecture #8 33
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 620 Lecture #8 34
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 620 Lecture #8 35
• 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
+getSubTotal() : Currency+add_productSpecification()+delete_productSpecification()
-quantity : Integer-productSpec : ProductSpecification
SalesLineItem
-description : String-price : Currency
ProductSpecification
* 1
Described-by
>
INFO 620 Lecture #8 36
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
+add_rental()+delete_rental()
-rentals:collection
Customer
+add_customer()+delete_customer()
-cust : Customer
Rental
1 0..*
Rents