Unit II - STATIC UML DIAGRAMS

Class Diagram–– Elaboration – Domain Model – Finding conceptual classes and description classes –

Associations – Attributes – Domain model refinement – Finding conceptual class Hierarchies –

Aggregation and Composition – Relationship between sequence diagrams and use cases –

When to use Class Diagrams

UML Class Diagram

• A Class Diagram is a diagram describing the structure of a system
• shows the system's
• classes
• Attributes
• operations (or methods),
• Relationships among the classes.
Essential Elements of a UML Class Diagram
• Class
• Attributes
• Operations
• Relationships
– Associations
– Generalization
– Realization
– Dependency
• Constraint Rules and Notes

Class

• Describes a set of objects having similar:

– Attributes (status)
– Operations (behavior)
– Relationships with other classes
• Attributes and operations may
– have their visibility marked:
– "+" for public
– "#" for protected
– "−" for private
– "~" for package
Associations
• An association between two classes indicates that objects at one end of an “recognize”
• objects at the other end and may send messages to them.
• Example: “An Employee works for a Company”
 • To clarify its meaning, an association may be named.
– The name is represented as a label placed midway along the association line.
– Usually a verb or a verb phrase.
• A role is an end of an association where it connects to a class.
– May be named to indicate the role played by the class attached to the end of the
association path.
• Usually a noun or noun phrase
• Mandatory for reflexive associations

Associations (cont.)
Role
name
Association
name
instructor
StaffMember Student
1..* instructs *
Role
Navigable
Multiplicity (uni-directional)
association * pre -
requisites
Courses
0..3
Reflexive
association

• To clarify its meaning, an association may be named.

– The name is represented as a label placed midway along the association line.
– Usually a verb or a verb phrase.
• A role is an end of an association where it connects to a class.
– May be named to indicate the role played by the class attached to the end of the
association path.
• Usually a noun or noun phrase
• Mandatory for reflexive associations

Multiplicity
– the number of objects that participate in the association.
– Indicates whether or not an association is mandatory.
Multiplicity Indicators

Exactly one 1

Zero or more (unlimited) * (0..*)

One or more 1..*

Zero or one (optional 0..1

Specified range 2..4

Multiple, disjoint ranges 2, 4..6, 8

Aggregation
• A special form of association that models a whole-part relationship between an aggregate (the
whole) and its parts.
– Models a “is a part-part of” relationship.

•Aggregation tests:
– Is the phrase “part of” used to describe the relationship?
• A door is “part of” a car
– Are some operations on the whole automatically applied to its parts?
• Move the car, move the door.
– Are some attribute values propagated from the whole to all or some of its parts?
• The car is blue, therefore the door is blue.
– Is there an intrinsic asymmetry to the relationship where one class is subordinate to the
other?
• A door is part of a car. A car is not part of a door.
Composition
• A strong form of aggregation
– The whole is the sole owner of its part.
• The part object may belong to only one whole
– Multiplicity on the whole side must be zero or one.
– The life time of the part is dependent upon the whole.
• The composite must manage the creation and destruction of its parts.
Generalization
• Indicates that objects of the specialized class (subclass) are substitutable for objects of the
generalized class (super-class).
– “is kind of” relationship.

• A sub-class inherits from its super-class

– Attributes
– Operations
– Relationships
• A sub-class may
– Add attributes and operations
– Add relationships
– Refine (override) inherited operations
• A generalization relationship may not be used to model interface implementation.
Realization
• A realization relationship indicates that one class implements a behavior specified by another
class (an interface or protocol).
• An interface can be realized by many classes.
• A class may realize many interfaces.

Dependency
• Dependency is a weaker form of relationship which indicates that one class depends on
another because it uses it at some point in time.
• One class depends on another if the independent class is a parameter variable or local variable
of a method of the dependent class.
• This is different from an association, where an attribute of the dependent class is an instance
of the independent class.
Constraint Rules and Notes
• Constraints and notes annotate among other things associations, attributes, operations and
classes.
• Constraints are semantic restrictions noted as Boolean expressions.
•
UML offers many pre-defined constraints

Class Diagram – Example

• Draw a class diagram for a information modeling system for a school.
– School has one or more Departments.
– Department offers one or more Subjects.
– A particular subject will be offered by only one department.
– Department has instructors and instructors can work for one or more departments.
– Student can enrol in upto 5 subjects in a School.
– Instructors can teach upto 3 subjects.
– The same subject can be taught by different instructors.
– Students can be enrolled in more than one school.
Class Diagram – Example
- School has one or more Departments

◼ Department offers one or more Subjects.

◼ A particular subject will be offered by only one department

• Department has Instructors and instructors can work for one or more departments.
 ◼ Student can enroll in up to 5 Subjects.

– Instructors can teach up to 3 subjects.

– The same subject can be taught by different instructors.

– Students can be enrolled in more than one school.

ELABORATION
• Elaboration is the initial series of iterations during which:
o the majority of requirements are discovered and stabilized
o the major risks are mitigated or retired
o the core architectural elements are implemented and proven
• Refined vision, iterative implementation of the core architecture, resolution of high risks,
identification of most requirements and scope, more realistic estimates.
• It is described as a phase in which throw-away prototypes are created, thus reducing the need
for attention to care in the programming or design. This is not accurate; production-quality
(albeit partial) designs and code are created during elaboration.
 What Artifacts May Start in Elaboration?
Artifact Comment
Domain Model This is a visualization of the domain concepts; it is similar to a
static information model of the domain entities.
Design Model This is the set of diagrams that describes the logical design. This
includes software class diagrams, object interaction diagrams,
package diagrams, and so forth
Software A learning aid that summarizes the key architectural issues and
Architecture their resolution in the design. It is a summary of the
Document outstanding design ideas and their motivation in the system.
Data Model This includes the database schemas, and the mapping strategies
between object and non-object representations.
Use-Case A description of the user interface, paths of navigation, usability
Storyboards, models, and so forth.
UI Prototypes

DOMAIN MODEL
A domain model is a visual representation of conceptual classes or real-world objects in a
domain of interest. They have also been called conceptual models, domain object models, and
analysis object models.
The UP defines a Domain Model as one of the artifacts that may be created in the Business
Modeling discipline.
Using UML notation, a domain model is illustrated with a set of class diagrams in which no
operations are defined.
It may show:
• domain objects or conceptual classes
• associations between conceptual classes
• attributes of conceptual classes
The domain model may be considered a visual dictionary of the noteworthy abstractions,
domain vocabulary, and information content of the domain.
On Naming and Modeling Things: The Mapmaker
The mapmaker strategy/Domain Vocabulary strategy applies to both maps and domain
models.
• Use the existing names in the territory.
• Exclude irrelevant features.

• Do not add things that are not there.

A domain model is a kind of map of concepts or things in a domain, and suggests the following:
• A mapmaker uses the names of the territory—they do not change the names of cities on a map.
For a domain model, this means use the vocabulary of the domain when naming conceptual
classes and attributes. For example, if developing a model for a library, name the customer a
"Borrower" or "Patron"—the terms used by the library staff.
• A mapmaker deletes things from a map if they are not considered relevant to the purpose of the
map; for example, topography or populations need not be shown. Similarly, a domain model
may exclude conceptual classes in the problem domain not pertinent to the requirements. For
example, we may exclude Pen and PaperBagfrom our domain model (for the current set of
requirements) since they do not have any obvious noteworthy role.
• A mapmaker does not show things that are not there, such as a mountain that does not exist.
Similarly, the domain model should exclude things not in the problem domain under
consideration.
How to Create/Make a Domain Model?
I) find the candidate conceptual classes using the Conceptual Class Category List and noun
phrase identification techniques related to the current requirements under consideration.
II) Draw them as classes in a domain model.
III) Add the associations necessary to record relationships for which there is a need to preserve
some memory.
IV) Add the attributes necessary to fulfill the information requirements.
I) How to find conceptual classes?
Conceptual Classes
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a
conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in
terms of its symbol, intension, and extension.
• Symbol—words or images representing a conceptual class.
• Intension—the definition of a conceptual class.
• Extension—the set of examples to which the conceptual class applies.
Three strategies to find conceptual classes
1. Reuse or modify existing models
There are published, well-crafted domain models and data models for many common
domains, such as inventory, finance, health, and so forth. These models can be reused.
2. Use a category list
3. Identify noun phrase
2. Use a Category List
Use a list of categories and see if they apply within your problem domain: this yields
candidate conceptual classes. Examples are drawn from the 1) POS, 2) Monopoly, and 3) airline
reservation domain.

Conceptual Class Category Examples

business transactions Sale, Payment
Guideline: These are critical (they involve money), so start with Reservation
transactions.
transaction line items SalesLineItem
Guideline: Transactions often come with related line items, so consider
these next.
product or service related to a transaction or transaction line item Item
Guideline: Transactions are for something (a product or service). Flight, Seat, Meal
Consider these next.
where is the transaction recorded? Register, Ledger
Guideline: Important.
roles of people or organizations related to the transaction; actors in Cashier, Customer, Store
the use case MonopolyPlayer
Guideline: We usually need to know about the parties involved in a Passenger, Airline
transaction.
place of transaction; place of service Store
Airport, Plane, Seat
noteworthy events, often with a time or place we need to remember Sale, Payment
MonopolyGame
Flight
physical objects Item, Register
Guideline: This is especially relevant when creating device-control Board, Piece, Die
software, or simulations. Airplane
descriptions of things ProductDescription
FlightDescription
catalogs ProductCatalog
Guideline: Descriptions are often in a catalog. FlightCatalog
containers of things (physical or information) Store, Bin
Board
Airplane

things in a container Item

Square (in a Board)
Passenger
other collaborating systems CreditAuthorizationSystem
AirTrafficControl
3. Identify noun phrase
• Another useful technique suggested in linguistic analysis.
• Identify noun (and noun phrases) in textual descriptions of the problem domain, and consider
them as candidate conceptual classes or attributes.
• The fully dressed use cases are an excellent description to draw from for this analysis.
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the external Accounting
system (for accounting and commissions) and Inventory system (to update inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
…
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the cash drawer.
3. Cashier deposits cash tendered and returns balance in cash to Customer.
4. System records the cash payment
Example: Case Study: POS domain
From the category list and noun phrase analysis, a list is generated of candidate conceptual
classes for the domain.
Sale Cashier
Payment Customer
SalesLineItem Store
Item ProductSpecification
Register ProductCatalog
Manager

II) Draw conceptual classes

Immediately draw a UML class diagram of the conceptual classes.
When to model with Description/Specification classes?
It contains information that describes something else.
Example: a ProductSpecification that records the price picture and text description of an item
Why use description classes?/When are Description classes useful?
Add a specification or description conceptual class (for example, ProductSpecification)when:
• There needs to be a description about an item or service, independent of the current existence
of any examples of those items or services.
• Deleting instances of things they describe (for example, Item) results in a loss of information
that needs to be maintained, due to the incorrect association of information with the deleted
thing.
• It reduces redundant or duplicated information.

Example: POS

III) Association

Associations are relationships between classes in a UML Class Diagram. They are
represented by a solid line between classes. Associations are typically named using a verb or verb
phrase which reflects the real world problem domain.
How to Find Associations?
Two main ways:
– By reading the current, relevant, requirements and asking ourselves what information is
needed to fulfil these requirements
– Using a list of association categories.
Association Category Examples
A is a transaction related to another transaction B Payment-Sale
Cancellation-Reservation
A is a line item of a transaction B SalesLineItem-Sale
A is a product or service for a transaction (or line item) B Item-SalesLineItem
A is a role related to a transaction B Customer-Payment
A is a physical or logical part of B Drawer-Register
Square-Board
Seat-Airplane
A is physically or logically contained in/on B Register-Store
Item-Shelf
A is a description for B ProductDescription-Item
A is known/logged/recorded/reported/captured in B Sale-Register
A is a member of B Cashier-Store
A is an organizational subunit of B Department-Store
A uses or manages or owns B Cashier-Register
Player-Piece

A is next to B SalesLineItem-SalesLineItem
The following sample of associations is justified in terms of a need-to-know. It may be
justifiable to delete the associations in question.

Sale Paid-by To know if the sale has been paid,relate the amount tendered to thesale
Payment total, and print a receipt.

SalesLineItem The requirements do not indicate a need-toknowor maintain inventory

Records-sale-ofItem information.
Store Stocks Item The requirements do not indicate a need-toknowor maintain inventory
information.

IV) Attributes
An attribute is a logical data value of an object. Include attributes that the requirements (for
example, use cases) suggest or imply a need to remember information.
Example:
Sale - dateTime
Store – name and address
Cashier – ID

Attribute Notation

Valid Attribute Types

The attributes in a domain model should preferably be simple attributes ordata types.Very
common attribute data types include:
Boolean, Date, Number, String(Text), Time
Other common types include:
Address, Color, Geometries (Point, Rectangle), Phone Number, Social Security Number,
Universal Product Code (UPC),ZIP or postal codes, enumerated types.

Example: Case Study: NextGen POS

The attributes chosen reflect the information requirements for this iteration—the Process Sale
cash-only scenarios of this iteration.

Payment Amount Tendered—To determine if sufficient payment was

provided, and to calculate change, an amount (also known
as "amount tendered") must be captured.
Product-Specification Description—To show the description on a display or
receipt.
id—To look up a ProductDescription
Price—To calculate the sales total, and show the line item
price.
Sale date, time—A receipt normally shows date and time of sale.
SalesLineItem Quantity—To record the quantity entered, when there is
more than one item in a line item sale.
Store Address, name—The receipt requires the name and address
of the store.
DOMAIN MODEL REFINEMENT

Refine the domain model with

i. Generalizations and Specializations
ii. Association Classes
iii. Time Intervals
iv. Composition
v. Packages

i) Generalizations and Specializations

Generalization is the activity of identifying commonality among concepts and defining
superclass (general concept) and subclass (specialized concept) relationships. It is a way to construct
taxonomic classifications among concepts which are then illustrated in class hierarchies.
In the UML the generalization relationship between elements is indicated with a large hollow
triangle pointing to the more general element from the more specialized one. Either a separate target
or shared target arrow style may be used.
Defining Conceptual Superclasses and Subclasses
A conceptual superclass definition is more general or encompassing than a subclass definition.
All the members of a conceptual subclass set are members of their superclass set.
When to Define a Conceptual Subclass/ Motivations to Partition a Conceptual Class into
Subclasses
A conceptual class partition is a division of a conceptual class into disjoint subclasses.
The following are strong motivations to partition a class into subclass:
Create a conceptual subclass of a superclass when:
1. The subclass has additional attributes of interest.
2. The subclass has additional associations of interest.
3. The subclass concept is operated on, handled, reacted to, or manipulated differently than the
superclass or other subclasses, in ways that area of interest.
4. The subclass concept represents an animate thing (for example, animal, robot) that behaves
differently than the superclass or other subclasses, in ways that are of interest.
When to Define a Conceptual Superclass
Generalization into a common superclass is usually advised when commonality is identified
among potential subclasses. The following are motivations to generalize and define a superclass:
Create a conceptual superclass in a generalization relationship to subclasses when:
• The potential conceptual subclasses represent variations of a similar concept.
• The subclasses will conform to the 100% and Is-a rules.
• All subclasses have the same attribute which can be factored out and expressed in the
superclass.
 All subclasses have the same association which can be factored out and related to the

superclass.Example: NextGen POS Conceptual Class Hierarchies

When to Model with 'Description ‘Classes?

A description class contains information that describes something else. For example,
aProductDescription that records the price, picture, and text description of an Item.

71
When Are Description Classes Useful?
Add a description class (for example, ProductDescription) when:
• There needs to be a description about an item or service, independent of the current existence
of any examples of those items or services.
• Deleting instances of things they describe (for example, Item) results in a loss of information
that needs to be maintained, but was incorrectly associated with the deleted thing.
• It reduces redundant or duplicated information.

ii) Association Classes

It allows you to treat an association itself as a class, and model it with attributes, operations,
and other features.Itis shown as a class symbol attached by a dashed line to an association path. Its
lifetime is dependent on the association.

Example: A Person may work for a single Company. We need to keep information about the period
of time that each employee works for each Company. We can do this by adding a dateRange attribute
to the association.

Guidelines for adding association classes include the following:

• An attribute is related to an association.
• Instances of the association class have a life-time dependency on the association.
• There is a many-to-many association between two concepts, and information associated with
the association itself.

iii) Time Intervals

If a SalesLineItemalways retrieved the current price recorded in a Product-Specification, then
when the price was changed in the object, old sales would refer to new prices, which is incorrect.

72
What is needed is a distinction between the historical price when the sale was made, and the current
price.
Depending on the information requirements, there are at least two ways to model this.
• Simply copy the product price into the SalesLineltem, and maintain the current price in
the ProductDescription.

•
Associate a collection of ProductPrices with a ProductDescriptions, each with an associated applicable
time interval. Thus the aggregation can record all past prices and also record future planned price.

iv) Aggregation and Composition

Aggregation

A special type of association. The relationship is displayed as a solid line with a hollow
diamond at the association end, which is connected to the class that represents the aggregate .
• It represents a "part of" relationship.
• Objects of both classes have separate lifetimes.
Example: Passengers are part of Car

Composition

A special type of aggregation where parts are destroyed when the whole is destroyed. The
relationship is displayed as a solid line with a filled diamond at the association end, which is
connected to the class that represents the whole or composite.
Example: Objects of Engine live and die with Car. Engine cannot stand by itself.
How to Identify Composition
Consider showing Composition when:
• The lifetime of the part is bound within the lifetime of the composite —there is a create-delete
dependency of the part on the whole.

• There is an obvious whole-part physical or logical assembly.

• Some properties of the composite propagate to the parts, such as the location.
• Operations applied to the composite propagate to the parts, such as destruction, movement,
and recording.
v) Using Packages to Organize the Domain Model
A domain model can easily grow large enough that it is desirable to factor it into packages of
strongly related concepts, as an aid to comprehension and parallel analysis work in which different
people do domain analysis within different sub-domains.
A UML package is shown as a tabbed folder. Subordinate packages may be shown within it.
The package name is within the tab if the package depicts its elements; otherwise, it is centered
within the folderitself.

Ownership and References

An element is owned by the package within which it is defined, but may be referenced in other
packages. In that case, the element name is qualified by the packagename using the pathname format
PackageName::Element Name

Package Dependencies
If a model element is in some way dependent on another, the dependency may be shown with
a dependency relationship, depicted with an arrowed line.
Example: Sales package has a dependency on the Core Elements package

How to Partition the Domain Model

To partition the domain model into packages, place elements together that:
• are in the same subject area — closely related by concept or purpose
• are in a class hierarchy together
• participate in the same use cases
• are strongly associated
Example: POS Domain Model Packages
Core Package

Products Package

System Sequence Diagram (SSD)

System Sequence diagram Definition

A System Sequence Diagram is an artifact that illustrates input and output events related to
the system under discussion. They are input to operation contracts and object design.

System Sequence Diagrams are typically associated with use-case realization in the logical
view of system development.
 Sequence Diagrams (Not System Sequence Diagrams) display object interactions arranged
in time sequence.

Sequence Diagram

Sequence Diagrams depict the objects and classes involved in the scenario and the
sequence of messages exchanged between the objects needed to carry out the functionality of the
system.
Sequence diagrams can be used to drive out testable user interface requirements.

What are System Sequence diagrams?

A System sequence diagram is a picture that shows, for one particular scenario of a usecase,
the events that external actors generate, their order, and inter-system events. All systems are treated
as a Black-box; the emphasis of the diagram is events that cross the system boundary from actors to
systems.

SSD - System Behaviour

Basically a system reacts to three things: 1) External events from actors (humans or computers)
2) timer events 3) Faults or exceptions(which are often from external Sources) Therefore it is
necessary to know what are the external input events i.e the system events. They are an important
part of analysing system behaviour.

System behaves as “Black Box”. Before proceeding to a logical design of how a software
application will work, it is useful to investigate and define its behavior as a "black box." System
behavior is a description of what a system does, without explaining how it does it. One part of that
description is a system sequence diagram. Other parts include the use cases, and system contracts.
In SSD, interior objects are not shown, as they would be on a Sequence Diagram.

System
In System Sequence Diagrams, Use cases describe:

• How actors interact with system.

• Typical course of events that external actors generate
• The order of the events.
For a particular scenario of use-case an SSD shows-

• The external actors that interact directly with the system.

• The System (as a black box).
• The system events that the actors generate.
• The operations of the system in response to the events generated.
• The temporal order of the events.
System Sequence Diagrams should be done for the main success scenario of the use-case, and
frequent and alternative scenarios.
Notations

Object:

Objects are instances of classes. Object is represented as a rectangle which contains the name of
the object underlined.
Because the system is instantiated, it is shown as an object.

:Object1

Actor: An Actor is modeled using the ubiquitous symbol, the stick figure.

actor 1

Lifeline: The LifeLine identifies the existence of the object over time. The notation for a Lifeline is a
vertical dotted line extending from an object.

Message: Messages, modeled as horizontal arrows between Activations, indicate the communications
between objects.

messageName(argument)

Examples of SSD

Following example shows the success scenario of the Process Sale use case.
Events generated by cashier (actor)-
makeNewSale, enterItem, endSale and makePayment.
SSD for Process Sale Scenario
 Relationship between System Sequence Diagrams and Use Cases
System Sequence Diagram is generated from inspection of a use case.
Constructing a systems sequence diagram from a use case:
• Draw a line representing the system as a black box.
• Identify each actor that directly operates on the system. Draw a line for each such actor.
• From the use case, typical course of events text, identify the system (external) events that each
actor generates. They will correspond to an entry in the right hand side of the typical use case.
Illustrate them on the diagram.
• Optionally, include the use case text to the left of the diagram.
SSDs are derived from Use Cases

System Events and System Boundary

Identifying the System events-

1. Determine the actors that directly interact with the system.

In the process Sale example, the customer does not directly interact with the POS system. Cashier
interacts with the system directly. Therefore cashier is the generator of the system events.
Defining the System Boundary
Naming System Event and System Operations

System events- They are external input events generated by an actor and they initiate a
responding operation by system. System events should be expressed at the abstract level of intention
rather than in terms of the physical input device.

Which is better, scan(itemId) or enterItem(itemId)?

"enteritem" is better than "scan" (that is, laser scan) because it captures the intent of the operation
while remaining abstract and noncommittal with respect to design choices about what interface is
used to capture the system event. It also improves clarity to start the name of a system event with a
verb (add..., enter..., end..., make...), since it emphasizes the command orientation of these events.

System operation-Operation invoked in response to system event.

Choose an Event and Operations Names at Abstract Level

Modelling SSDs involving other external systems

SSDs can be used to illustrate collaborations between systems, such as

between the NextGen POS and the external credit payment authorizer.

SSDs and the Glossary

The terms shown in SSDs (operations, parameters, and return data) are
terse. These may need proper explanation so that during design work it is clear
what is coming in and going out. If this was not explicated in the use cases, the
Glossary could be used.

For eg: Changedue, receipt – It is a vague description and a complex report. So the
glossary can have a receipt entry, which shows sample receipts and detailed contents
and layout.

SSDs within the UP

Inception—SSDs are not usually motivated in inception.

Elaboration—Most SSDs are created during elaboration, when it is useful

to identify the details of the system events to clarify what major operations the
system must be designed to handle, write system operation contracts and
possibly support estimation.