UNIT II

STATIC UML DIAGRAMS

 SYLLABUS
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
 ELABORATION
Process: Inception and Elaboration
What Happened in Inception?
The inception phase of the case studies may last
only one week.
 Inception is a short step to elaboration.
 It determines basic feasibility, risk, and scope,
to decide if the project is worth more serious
investigation.
Activities and artifacts in inception
 A short requirements workshop
 Most actors, goals, and use cases named
 Most use cases written in brief format;
 most influential and risky quality requirements
identified
 Version one of the Vision and Supplementary
Specification written
 Risk list
Plan for the first iteration.
 high-level candidate architecture and components
proposed
Elaboration
 Elaboration is the initial series of iterations
 The core, risky software architecture is programmed and
tested
The majority of requirements are discovered and
stabilized
 The major risks are mitigated or retired
 Elaboration is the initial series of iterations during
which the team does
serious investigation,
Implements the core architecture,
clarifies most requirements,
tackles the high-risk issues.
Elaboration
 Elaboration often consists of two or more iterations
 Each iteration is timeboxed .
 Elaboration is not a design phase or a phase of
implementation.
 During this phase the code and design are
production - quality portions of the final system.
 It is also called the executable architecture or
architectural baseline.
 Elaboration in one sentence:
Build the core architecture, resolve the high-risk
elements, define most requirements, and
estimate the overall schedule and resources.
Elaboration
 Some key ideas
 do short time boxed risk-driven iterations
 start programming early
 adaptively design, implement, and test the core
and risky parts of the architecture
 test early, often, realistically
 adapt based on feedback from tests, users,
developers
 write most of the use cases and other
requirements in detail
Elaboration Artifacts
Artifact Comment
This is a visualization of the domain
Domain Model
concepts

This is the set of diagrams that

Design Model
describes the logical design.
A learning aid that summarizes the key
Software Architecture
architectural issues and their resolution
Document
in the design.
This includes the database schemas,
Data Model and the mapping strategies between
object and non-object representations
A description of the user interface,
Use-Case Storyboards, UI
paths of navigation, usability models,
Prototypes
and so forth.
 Domain Models
Introduction
 A domain model is the most important—and
classic—model in OO analysis.
 It illustrates noteworthy concepts in a domain.
Example
 It illustrates that the conceptual
classes of Payment and Sale are significant in
this domain
 Payment is related to a Sale
 Sale has a date and time, information attributes
 Domain Models

Partial domain model—a visual dictionary.

Applying the UML class diagram notation for a
domain model yields a conceptual
perspective model.
Identifying a rich set of conceptual classes is at
the heart of OO analysis.
If it is done with skill and short time
investment
 What is Domain Models
 A domain model is a visual representation of
conceptual classes or real-situation objects in a
domain.
 “Domain Model” means a representation of real-
situation conceptual classes, not of software objects.
 The term does not mean a set of diagrams describing
software classes, the domain layer of a software
architecture, or software objects with responsibilities.
 Domain models have also been called conceptual
models, domain object models, and analysis object
models.
 What is Domain Models
 Applying UML notation, a domain model is
illustrated with a set of class diagrams
 No operations (method signatures) are defined.
 It provides a conceptual perspective.
 It may show:
 domain objects or conceptual classes
 associations between conceptual classes
 attributes of conceptual classes
 Why Call a Domain Model a “Visual
Dictionary”?
 Domain model class diagram how it visualizes
and relates words or concepts in the domain.
It's easy to understand the terms and especially
their relationships in a visual language
 since our brains are good at understanding visual
elements and line connections.
 It also shows an abstraction of the conceptual
classes.
 Is a Domain Model a Picture of
Software Business Objects?
 A UP Domain Model, is a visualization of things
in a real-situation domain of interest, not of
software objects such as Java or C# classes, or
software objects with responsibilities.
 Therefore, the following elements are not suitable
in a domain model:
 Software artifacts, such as a window or a database,
unless the domain being modelled is of software
concepts, such as a model of graphical user interfaces.
 Responsibilities or methods.
 What are Conceptual Classes?
 The domain model illustrates conceptual classes
or vocabulary in the domain.
 Informally, a conceptual class is an idea, thing, or
object.
 Conceptual class may be considered in terms of
 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.
 How to Create a Domain Model?
1. Find the conceptual classes
2. Draw them as classes in a UML class diagram.
3. Add associations and attributes.
 1. How to Find Conceptual Classes?

Three Strategies to Find Conceptual Classes

i. Reuse or modify existing models.
ii. Use a category list.
iii. Identify noun phrases.
 i. Reuse or modify existing models.

 This is the first, best, and usually easiest

approach
 There are published, well-crafted domain models
and data models for many common domains.
 Example, inventory, finance, health, and so
forth.
 ii. Use a Category List
 We can kick-start the creation of a domain model
by making a list of candidate conceptual classes.
 Many common categories that are usually worth
considering, with an emphasis on business
information system needs.
Conceptual Class Category Examples
business transactions Sale, Payment
Guideline: These are critical (they Reservation
involve money), so start with
transactions.
transaction line items SalesLineItem
Guideline: Transactions often come
with related line items, so consider
these next.
product or service related to a Item
transaction or transaction line item Flight, Seat, Meal
Guideline: Transactions
are for something (a product or
service).
Conceptual Class Category Examples
where is the transaction recorded? Register, Ledger
Guideline: Important.

roles of people or organizations Cashier, Customer

related to the transaction; actors in
the use case
Guideline: We usually need to know
about the parties involved in a
transaction.

place of transaction; place of service Store

noteworthy events, often with a time Sale, Payment

or place we need to remember
Conceptual Class Category Examples
physical objects Item, Register
Guideline: This is especially relevant Board
when creating device-control
software, or simulations.
descriptions of things ProductDescription
catalogs ProductCatalog
Guideline: Descriptions are often in a
catalog.
containers of things Store
things in a container Item Square (in a
Board)
other collaborating systems CreditAuthorizatio
nSystem
Conceptual Class Category Examples
records of finance, work, contracts, Receipt
legal matters
financial instruments Cash, Check,
schedules, manuals, documents that DailyPriceChange
are regularly referred to in order to List
perform work RepairSchedule
 iii. Finding Conceptual Classes with
Noun Phrase Identification
 Another useful technique is linguistic analysis.
 linguistic analysis: Identify the nouns and noun
phrases in textual descriptions of a domain
 The fully dressed use cases are an excellent
description to draw from for this analysis.
 Example
 Main Success Scenario (or Basic Flow):
1. Customer arrives at a 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.
 Example: Find and Draw
Conceptual Classes
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 CashPayment

Customer SalesLineItem Store
Item ProductDescripti Register
on
ProductCatalog Ledger
 When to Model with 'Description'
Classes?
 A description class contains information that
describes something else.
 Example : ProductDescription that records the
price, picture, and text description of an Item.
 Why Use 'Description' Classes?
 The store sells out, implying that
all Item instances are deleted from computer
memory.
 The model, if implemented in software similar to
the domain model, has duplicate data, is space-
inefficient, and error-prone.
 When Are Description Classes
Useful?
 Add a description class (for example, Product
Description) when:
 There needs to be a description about an item or
service.
 Deleting instances of things they describe (for
example, Item) results in a loss of information.
 It reduces redundant or duplicated information.
 Associations
 An association is a relationship between classes
that indicates some meaningful and interesting
connection.
 When to Show an Association?
 Associations for which knowledge of the
relationship needs to be preserved for some
duration (“need-to-remember” associations).
 Associations derived from the Common
Associations List.
 Applying UML: Association
Notation
 An association is represented as a line between
classes with a capitalized association name.

 Applying UML: Association
Notation
 The ends of an association may contain a
multiplicity expression indicating the numerical
relationship between instances of the classes.
 The association is inherently bidirectional.
 An optional “reading direction arrow” indicates
the direction to read the association name.
HOW TO NAME AN ASSOCIATION
IN UML?
 Name an association based on a ClassName-
VerbPhrase-ClassName format where the verb
phrase creates a sequence that is readable and
meaningful.
 Association names should start with a capital letter.
 classifier of links between instances.
 classifiers should start with a capital letter.
 legal formats
Records-current
RecordsCurrent
 Applying UML: Roles
 Each end of an association is called a role.
 Roles may optionally have:
 multiplicity expression
 name
 navigability
 Applying UML: Multiplicity
 Multiplicity defines how many instances of a
class A can be associated with one instance of a
class B.

 Applying UML: Multiplicity
 A single instance of a Store can be associated
with “many” (zero or more, indicated by the
*) Item instances.
 How to Find Associations with a
Common Associations List
 It contains common categories,
Category Examples
A is a transaction related to CashPayment—Sale
another transaction B
A is a line item of a transaction B SalesLineItem—Sale
A is a product or service for a Item—SalesLineItem
transaction (or line item) B (or Sale)
A is a role related to a transaction Customer—Payment
B
 Attributes
 An attribute is a logical data value of an object.
When to Show Attributes?
 Include attributes that the requirements need to
remember information.
 Example
 Sale needs a dateTime attribute.
 Store needs a name and address.
 Cashier needs an ID.
Applying UML: Attribute Notation
 Attributes are shown in the second compartment
of the class box.
 Their type and other information may optionally
be shown.
Applying UML: Attribute Notation
Syntax
 visibility name : type multiplicity = default
{property-string}
visibility name
 private visibility (-)
 public visibility(+)
 Protected visibility(#)
property-string
 {readOnly} is probably the most common
property string for attributes.
Applying UML: Attribute Notation
 visibility name : type multiplicity = default
{property-string}
multiplicity
 Multiplicity can be used to indicate the optional
presence of a value
Applying UML: Attribute Notation
DERIVED ATTRIBUTES
 The total attribute in the Sale can be calculated or
derived from the information in the
SalesLineItems.
 When we want to communicate that
1) this is a noteworthy attribute,
2) it is derivable, we use the UML convention:
a / symbol before the attribute name.
Applying UML: Attribute Notation
DATA TYPES
 Atributes in the domain model should generally
be data types; informally these are “primitive”
types such as number, boolean, character, string,
and enumerations.
 For example
 Separate instances of the Integer 5.
 Separate instances of the String 'cat'.
 Separate instance of the Date “Nov. 13, 1990”.
 Class diagrams
 A class diagram in the Unified Modeling
Language is a type of static structure diagram that
describes the structure of a system by showing
the system's classes, their attributes, operations,
and the relationships among objects.
 Three Compartments
1. Class Name
2. Attributes
3. Methods
 Class diagrams
 The UML includes class diagrams to illustrate
classes, interfaces, and their associations.
 They are used for static object modeling.

CLASS NAME

ATTRIBUTES

OPERATION OR
METHODS
Applying UML: Common Class Diagram
Notation
 Relationship Notation
 Generalization

 Association

 Aggregation

 Composition

 Dependency
 Definition: Classifier
 A UML classifier is “a model element that
describes behavioral and structure features”.
 Classifiers can also be specialized.
 In class diagrams, the two most common
classifiers are regular classes and interfaces.
Attribute Text and Association Lines
 Attributes of a classifier (also called structural
properties in the UML) are shown several ways:
 attribute text notation, such as currentSale : Sale.
 association line notation
 both together
 The full format of the attribute text notation is:
visibility name : type multiplicity = default
{property-string}
Attribute Text and Association Lines
 A navigability arrow pointing from the source
(Register) to target (Sale) object.
 A multiplicity at the target end
 A rolename (currentSale) only at the target end
Attribute Text and Association Lines
 Data type
 Boolean, Date (or DateTime), Number,
Character, String (Text), Time, Address, Color,
Geometrics (Point, Rectangle), Phone Number,
Social Security Number, Universal Product Code
(UPC), SKU, ZIP or postal codes, enumerated
types.
public class Register
{
private int id;
private Sale currentSale;
private Store location;
// ... }
The UML Notation for an Association
End
 navigability arrow
 rolename - to indicate the attribute name
 multiplicity
 property string
 {ordered} or {unique}
 {ordered, List}
{ordered} or {unique} - UML - defined keyword that
implies the elements of the collection are (the suspense
builds...) ordered.
{List} - the collection attribute lineItems
 Operations and Methods
 Third compartment in UML Class diagram is
operation or Methods
 Syntax:
visibility name (parameter-list) : return-type
{property-string}
 property string {name1=value1,
name2=value2} format,
 such as {abstract, visibility=public}.
 Dependency
 The UML includes a general dependency
relationship that indicates that a client element
has knowledge of another supplier element and
that a change in the supplier could affect the
client.
 Dependency is illustrated with a dashed arrow
line from the client to supplier.
 when to show a dependency
 There are many kinds of dependency
 having an attribute of the supplier type
 sending a message to a supplier
 receiving a parameter of the supplier type
 the supplier is a superclass or interface
when to show a dependency
 In class diagrams use the dependency line to
 global parameter variable
 local variable
 static-method (when a call is made to a static method
of another class)
 Example of dependency
public class Sale {
public void updatePriceFor( ProductDescription
description ) {
Money basePrice = description.getPrice();
//...
}
// ...
}
Example of dependency
 Domain Model Refinement
 Generalization and specialization are fundamental
concepts in domain modeling.
 Conceptual class hierarchies are often the basis of
inspiration for software class hierarchies.
 Software class hierarchies
 exploit inheritance
 reduce duplication of code.
 Generalization
 Generalization is the activity of identifying
commonality among concepts and defining
superclass (general concept) and subclass
(specialized concept) relationships.
 Notation
 Example
The concepts CashPayment, CreditPayment,
and CheckPayment are all very similar.

superclass - more general

Payment concept

these are conceptual

classes, not software
classes
subclass - more
Cash Credit Check specialized concept
Payment Payment Payment
 Alternate notation


Payment Payment

Cash Credit Check Cash Credit Check

Payment Payment Payment Payment Payment Payment
Conceptual Superclasses and Subclasses
Conceptual superclass
 A conceptual superclass definition is more
general or encompassing than a subclass
definition
 For example, consider the superclass Payment
and its subclasses (CashPayment, and so on).
Payment

amount : Money

Cash Credit Check

Payment Payment Payment
Conceptual Superclasses and Subclasses
Conceptual subclass
 All members of a conceptual subclass set are
members of their superclass set.
 Venn Diagram view:
 All instances of “cash payment” are also
members of the “payment class.
Payment

CashPayment CreditPayment CheckPayment

 General rule for Subclass
100% Rule
 100% of the conceptual superclass's definition
should be applicable to the subclass. The subclass
must conform to 100% of the superclass's:
attributes
associations
Is-a or Is-kind-of Rule
 All the members of a subclass set must be
members of their superclass set.
 When to use a subclass
 Start with the super-class and look at differences
to find the sub-classes that make sense.
 Subclass has additional attributes
 Subclass has additional associations
 Subclass usage differs from superclass
 Subclass represents an animate entity that behaves
differently
 When to define a superclass
 Start with a set of sub-classes and look for
commonalities that help the model.
 Potential subclasses represent variations of concept
 Subclasses meet “is-a” rule and 100% rule
 All subclasses have common attributes that can be
factored out
 All subclasses have the same association that can be
factored out
 Specialization
 Specialization is the reverse process of
generalization.
 Specialization is the creating new sub-classes
from an existing class.
Specialization
 Aggregation
 A special type of association. It represents a "part
of" relationship.
 Notation
 Aggregation
 Class2 is part of Class1.
 Many instances (denoted by the *) of Class2 can
be associated with Class1.
 Objects of Class1 and Class2 have separate
lifetimes.
 A solid line with an unfilled diamond at the
association end connected to the class of
composite
 Composition
 A special type of aggregation where parts are
destroyed when the whole is destroyed.
 Notation
 Composition
 Objects of Class2 live and die with Class1.
 Class2 cannot stand by itself.
 A solid line with a filled diamond at the
association connected to the class of composite
 Qualified Associations
 A qualifier may be used in an association
 It distinguishes the set of objects at the far end of
the association based on the qualifier value.
(a) Product Contains Product
Catalog Description
1 1..*

1 1
Product Contains Product
(b) itemID
Catalog Description

qualifier multiplicity reduced to 1

 Reflexive Associations
 A concept may have an association to itself; this
is known as a reflexive association

Person

2
*
parent child

Creates 4