Information Systems Analysis and Design Class Diagram Refinement

1
Information Systems Analysis and DesignClass
Diagram Refinement

• INFO 620
• Glenn Booker

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

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

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

5
Showing Generalization

• The open triangle shows generalization

6
Superclass versus Subclass

• A superclass is more general, vague, or broad
  than a subclass

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

8
Generalization
These diagrams both mean the same thing
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???

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

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)

12
Changing States

• It may be tempting to define subclasses for
  different states of a class, e.g. Authorized and
  Unauthorized Payments
• Dont!
• Instead, make that state a separate abstract
  class, with subclasses for each possible state
  (p. 408)

13
Inheritance

• Inheritance is when a subclass inherits the
  attributes and associations of its superclass
• Inheritance is heavily implementation
  language-specific, so it doesnt apply to
  conceptual class generalization
• Conceptual classes may be collapsed or expanded
  to become software classes

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

15
Association Classes

• But sometimes that isnt 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

16
Association Classes

• Employment is an association class between
  Company and Person
• Association classes are also good for
  time-dependent associations

17
Aggregation

• When a class makes you mad, thats 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

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

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

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

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 records

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

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)

24
Derived Elements

• Attributes and associations may be derived from
  other attributes and associations
• They should be avoided, since they add complexity
  use when its a frequently used term
• Show derived status manuallywith a forward slash
  prefix

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 method

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) role

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 otherpackageclass notation (p.
  424)

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

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

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

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)
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 texts class diagrams!!

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)

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 gt1, the reference
  attribute in class A is a collection a
  container for multiple objects of type B

35
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 multiplicity1

36
Reference Attributes

• Another example
• Lets say a Customer wants to make a Rental (per
  Prof. Songs video rental example)
• Association is bidirectional, hence need both
  reference attributes and their methods