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

INFO 620 Lecture #8 1

Information Systems Analysis and Design

Class Diagram Refinement

INFO 620

Glenn Booker


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


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


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


Showing Generalization

• The open triangle shows generalization

CashPayment

Payment

CreditPayment CheckPayment


Superclass versus Subclass

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

CashPayment

-amount : Currency

Payment


Superclass

Subclass


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


Generalization

CashPayment

-amount : Currency

Payment


Sale

1 1

Pays-for

CashPayment

-amount : Currency

Payment


Sale

1

1 Pays-for

1

1

Pays-for

11

Pays-forThese diagrams both mean the same thing


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???


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


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)


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)


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


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


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


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

* *


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”


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 *


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


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


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


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


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)


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


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


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}


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)


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


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


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


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)


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!!



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



• 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


• 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


+getSubTotal() : Currency+add_productSpecification()+delete_productSpecification()

-quantity : Integer-productSpec : ProductSpecification

SalesLineItem

-description : String-price : Currency

ProductSpecification

* 1

Described-by

>



• 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

Documents

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