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

Information Systems Analysis
and Design
Class Diagram Refinement
INFO 620
Glenn Booker
INFO 620
Lecture #8
1
Iteration 3 of Text
• Iteration 3 in Larman covers additional
refinement of the design
–
–
–
–
–
INFO 620
Relating use cases (“include”)
Generalization of classes
Architecture analysis
Additional patterns
Frameworks
Lecture #8
2
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
3
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
4
Showing Generalization
• The open triangle shows generalization
Payment
CashPayment
INFO 620
CreditPayment
Lecture #8
CheckPayment
5
Superclass versus Subclass
• A superclass is more general, vague, or
broad than a subclass
Payment
Superclass
-amount : Currency
CashPayment
CreditPayment
CheckPayment
Subclass
INFO 620
Lecture #8
6
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
7
Generalization
Payment
Sale
Pays-for
-amount : Currency
1
1
Payment
CashPayment
CreditPayment
CheckPayment
-amount : Currency
CashPayment
These diagrams both
mean the same thing
CreditPayment
CheckPayment
Pays-for
1
1
1
Pays-for
Sale
1
1
Pays-for
1
INFO 620
Lecture #8
8
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
9
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
10
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
11
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
12
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
13
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
Has
Person
PhoneNumber
1
*
– Sale has many SalesLineItem
Sale
Contains
1
INFO 620
Lecture #8
SalesLineItem
*
14
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
15
Association Classes
• Employment is an association class between
Company and Person
• Association classes are also good for
time-dependent associations
Employment
startdate : Date
salary : Currency
*
*
Company
INFO 620
Person
Lecture #8
16
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
17
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
18
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
*
INFO 620
Element
References
*
Lecture #8
19
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
20
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
ProductPrice
ProductSpecification
Priced-by
*
INFO 620
1..*
Lecture #8
-starttime : Date
-endtime : Date
-price : Currency
21
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
*
Person
• This example is also a
-child
reflexive association
2
-parent
Creates
INFO 620
Lecture #8
22
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
23
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
Sale
-date
• Show derived status manually
-time
-/total
with a forward slash prefix
INFO 620
Lecture #8
24
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
ProductCatalog
itemID
1
INFO 620
ProductSpecification
1
Lecture #8
25
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
Sale
SalesLineItem
1
INFO 620
1..*
{ordered}
Lecture #8
26
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
27
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
28
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
INFO 620
Lecture #8
Core
29
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
30
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
31
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
32
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
33
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
34
Reference Attributes
• 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
SalesLineItem
-quantity : Integer
-productSpec : ProductSpecification
+getSubTotal() : Currency
+add_productSpecification()
+delete_productSpecification()
INFO 620
Described-by
*
Lecture #8
ProductSpecification
: String
>-description
-price : Currency
1
35
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
Customer
Rents
-rentals:collection
+add_rental()
+delete_rental()
INFO 620
1
0..*
Lecture #8
Rental
-cust : Customer
+add_customer()
+delete_customer()
36