CS8592 Object Oriented Analysis & Design - UNIT II

UNIT II Static UML Diagrams

1. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 1

CS8592 – Object Oriented Analysis and Design
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
2.1 ELABORATION
 It is an activity in which the information about the requirements is expanded and
refined. Information is gained during inception phase.
 The elaboration consists of several modeling and refinement tasks. In this process,
several user scenarios are created and refined. Basically these scenarios describe how
end-user will interact with the system.
 During elaboration, each user scenario is parsed and various classes are identified.
These classes are business entities that are visible to end users. Then the attributes and
methods of these classes are defined. Then the relationship among these classes is
identified.
 Finally various UML are developed during this task
 Elaboration is conducted within two or more iterations. Each iteration executes for two
or three weeks. Each iteration is time-boxed.
 Elaboration is neither a design step nor a phase in which a fully developed model for
implementation is prepared.
 In this phase, executable architecture or architectural baseline of the system is
prepared.
2.1 Elaboration Phase includes,
 The core architecture of the system is built
 High risk elements are resolved
 Majority of requirements are discovered and stabilized
 A rough estimation of overall project and schedule is done
2.2 Key Ideas and Best Practices
 Each risk-driven iteration must be time-boxed
 Start programming early
 Test early, often, realistically
 Adapt based on feedback from tests, users, developers
 Develop most of the use cases in detail
 Adaptively design, implement, and test the core and risky parts of the architecture

2. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 2

2.3 Elaboration Artifact
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 Architecture
Document
A learning aid that summarizes the key architectural issues and their
resolution in the design. It is a summary of the 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 Storyboards,
UI Prototypes
A description of the user interfaces, paths of navigation, usability models,
and so forth.

2.2 DOMAIN MODEL
 A domain model is a visual representation of conceptual classes or real-situation
objects in a domain.
 Domain models have also been called conceptual models domain object models, and
analysis object models.
Definition
 In the UP, the term "Domain Model" means a representation of real-situation
conceptual classes, not of software objects.
 The domain model focuses on explaining the core things and products of the
business domain.
 Using the UML modeling the domain model can be represented using a class
diagram.
 The domain model represents,
o Domain objects or Conceptual classes
o Associations between conceptual classes
o Attributes of conceptual classes
2.2.1 Domain Model as a Visual Dictionary
 Domain Model visualizes and relates words or concepts in the domain.
 It also shows an abstraction of the conceptual classes.
 The domain model is a visual dictionary of the noteworthy abstractions, domain
vocabulary, and information content of the domain.
 The information in domain model can be expressed in plain text.

3. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 3

 The conceptual classes and their relationship with other classes can be expressed
using visual language using a domain model.
2.2.2 Domain Model and Software Business Objects
 “Domain Model” is a conceptual perspective of objects in a real situation of the
world, not a software perspective.
 Domain model is a visualization of real world entities and not the representation of
software business objects.
 Elements not suitable in domain model are:
o Software artifacts such as database or file
o Responsibilities or methods or functions
 The layer of software objects below the presentation or UI layer that is composed of
domain objects.

Fig: Domain Model shows real - situation conceptual classes, not software classes








Fig: Domain Model does not show software artifacts or classes
2.2.3 What are Conceptual Classes?
 A conceptual class is an idea, thing, or object.
 It may be considered in terms of its symbol, intension, and extension.

4. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 4

o Symbol: Words or images representing a conceptual class.
o Intension: The definition of a conceptual class.
o Extension: The set of examples to which the conceptual class applies.
2.2.4 Why create a Domain Model?
 Here‟s a source code payroll program written in 1953:
10000101010001111010101010100010101010101111…..
 As computer science people, we know it runs, but gap between this software
representation and our mental model of the payroll domain is huge.

Fig. Lower Representational Gap with OO Modeling
2.2.5 How to Create a Domain Model?
1. Find the conceptual classes (see a following guideline).
2. Draw them as classes in a UML class diagram.
3. Add associations and attributes.
2.2.6 How to Find Conceptual Classes?
Three Strategies to find Conceptual Classes:
1. Reuse or modify existing models.
2. Use a category list.
3. Identify noun phrases.
Main Success Scenario (or Basic Flow):
1. Customer arrives at a POScheckout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.

5. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 5

4. System records sale line item and presents item description, price, and running
total. Price calculated from a set of price rules.
5. System presents total with taxes and asks for payment
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 to external accounting
9. System presents receipt
10. Customer leaves with receipt and goods


Fig. Initial POS Domain Model
2.2.7 When to Model with 'Description' Classes?
 A class which describes some entity
 Example: A Product Description that records the price, picture, and text
description of an Item.
2.2.8 Why use “Description” Classes?
 An “item” instance represents a physical item in a store; as such, it may even have
a serial number.

2.2.9 When are Description Classes useful?
 There needs to be a description about an item or service, independent of the current
existence of any examples of those items or services.

6. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 6

 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.

2.3 CLASS DIAGRAM
 The UML includes class diagrams to illustrate classes, interfaces, and their associations.
 They are used for static object modeling.
 A class diagram describes the types of objects in the system and the various kinds of
static relationships that exist among them.
 A graphical representation of a static view on declarative static elements.
2.3.1 Common Class Diagram Notation

7. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 7

A class notation consists of three parts:
1. Class Name
 The name of the class appears in the first partition.
2. Class Attributes
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
 Operations are shown in the third partition. They are services the class provides.
 The return type of a method is shown after the colon at the end of the method
signature.
 The return type of method parameters are shown after the colon following the
parameter name.
 Operations map onto class methods in code.
2.3.2 Design Class Diagram

Fig. UML Class Diagrams in two perspectives
 In a conceptual perspective the class diagram can be used to visualize a domain
model.
 In the UP, the set of all DCDs form part of the Design Model.
 Other parts of the Design Model include UML interaction and package diagrams.
Classifier
 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.
Notes, Comments, Constraints, and Method Bodies
A UML note symbol is displayed as a dog-eared rectangle with a dashed line to the
annotated element.

8. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 8

 A UML note or comment, which by definition has no semantic impact.
 A UML constraint, in which case it must be encased in braces '{…}' .
 A method body the implementation of a UML operation.
Keywords
A UML keyword is a textual adornment to categorize a model element.
Keyword Meaning Example Usage
«actor» classifier is an actor in class diagram, above classifier name
«interface» classifier is an interface in class diagram, above classifier name
{abstract}
abstract element; can't be
instantiated
in class diagrams, after classifier name or
operation name
{ordered}
a set of objects have some
imposed order
in class diagrams, at an association end
Stereotypes, Profiles, and Tags
A stereotype represents a refinement of an existing modeling concept and is defined within
a UML profile informally, a collection of related stereotypes, tags, and constraints to
specialize the use of the UML.

2.3.4 Attributes
An attribute is a logical data value of an object.
Example:
 Sale needs a dateTime attribute.
 Store needs a name and address.
 Cashier needs an ID.

9. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 9

Applying UML - Attribute Notation
Attributes are shown in the second compartment of the class box. Their type and other
information may optionally be shown.

More Notation
The full syntax for an attribute in the UML is:
visibility name : type multiplicity = default {property-string}

Multiplicity can be used to indicate the optional presence of a value, or the number of
objects that can fill a (collection) attribute.
Derived Attributes
This is a noteworthy attribute, but it is derivable  Use the UML convention: a / symbol
before the attribute name.
Guidelines
1. When to show attributes?
Include attributes that the requirements suggest or imply a need to remember information.
2. Where to record attribute requirements?
Suggest placing all attribute requirements in UP Glossary which serves as a data
dictionary.

2.3.5 Data types
 Attributes in the domain model should generally be data types
 Informally these are "primitive" types such as number, boolean, character, string, and
enumerations (such as Size = {small, large}).
Example:
 Separate instances of the Integer 5.
 Separate instances of the String 'cat'.
 Separate instance of the Date "Nov. 13, 1990".

10. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 10

Guidelines:
1. When to define New Data type Classes?
Represent what may initially be considered a number or string as a new data type class in the
domain model if:
 It is composed of separate sections. Ex: phone number, name of person
 There are operations associated with it, such as parsing or validation. Ex: social
security number
 It has other attributes. Ex: promotional price could have a start (effective) date and
end date
 It is a quantity with a unit. Ex: payment amount has a unit of currency
 It is an abstraction of one or more types with some of these qualities.
Where to Illustrate These Data Type Classes?

2. No Attributes Representing Foreign Keys (Do not use attributes as foreign keys)

3. Modeling Quantities and Units (Most numeric quantities should not be represented as
plain numbers.)

11. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 11

Example: Attributes in the Domain Models - Case Study: NextGen POS
CashPayment amountTendered: To determine if sufficient payment was provided, and to
calculate change, an amount (also known as "amount tendered") must be
captured.
Product-
Description
description: To show the description on a display or receipt.
itemId: To look up a ProductDescription.
price: To calculate the sales total, and show the line item price.
Sale dateTime: A receipt normally shows date and time of sale, and this is useful
for sales analysis.
SalesLineItem quantity: To record the quantity entered, when there is more than one item in
a line item sale (for example, five packages of tofu).
Store address, name: The receipt requires the name and address of the store.

12. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 12

2.3.6 Association
 An association is a relationship between classes (more precisely, instances of those
classes) that indicates some meaningful and interesting connection.
 In the UML, associations are defined as "the semantic relationship between two or more
classifiers that involve connections among their instances."

When to show an Association?
 Associations for which knowledge of the relationship needs to be preserved for some
duration such as milliseconds or years.
 Associations derived from the Common Associations List.
Guidelines
1. Avoid Adding Many Associations
 During domain modeling, an association is not a statement about data flows, database
foreign key relationships, instance variables, or object connections in a software
solution.
 It is a statement that a relationship is meaningful in a purely conceptual perspective-in
the real domain.
Applying UML: Association Notation

2. 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.
Applying UML: Roles
Each end of an association is called a role. Roles may optionally have:
 Multiplicity Expression
 Name
 Navigability
Applying UML: Multiplicity
It defines how many instances of a class A can be associated with one instance of a class B.

13. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 13

Multiplicity Values

Applying UML: Multiple Associations between Two Classes
The domain of the airline is the relationships between a Flight and an Airport the flying-
to and flying-from associations are distinctly different relationships, which should be
shown separately.

3. To Find Associations with a Common Associations List
Roles as Concepts versus Roles in Associations
 In a domain model, a real-world role especially a human role may be modeled in a
number of ways, such as a discrete concept, or expressed as a role in an association.
 For example, the role of cashier and manager may be expressed in at least the two
ways illustrated in Fig.

14. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 14

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.
 An association with a qualifier is a qualified association.

Reflexive Associations
 A concept may have an association to itself.

Example: Associations in the Domain Models - Case Study: NextGen POS
 Transactions related to another transactionSale Paid-by CashPayment.
 Line items of a transactionSale Contains SalesLineItem.
 Product for a transaction (or line item) SalesLineItem Records-sale-of Item.

15. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 15

2.4 DOMAIN MODEL REFINEMENT
Objectives
 Refine the domain model with generalizations, specializations, association classes, time
intervals, composition, and packages.
 Generalization and specialization are fundamental concepts in domain modeling that
support an economy of expression.
 Conceptual class hierarchies are the basis for software class hierarchies that exploit
inheritance
 Association classes capture information about an association itself.
 Time intervals capture the important concept that some business objects are valid for a
limited time.
 Packages are a way to organize large domain models into smaller units.
2.4.1 Generalization and Specialization
 The concepts CashPayment, CreditPayment, and CheckPayment are all very similar.
 In this situation, it is possible (and useful) to organize them into a generalization-
specialization class hierarchy (or simply class hierarchy) in which the super
classPayment represents a more general concept, and the subclasses more specialized
ones.

 Generalization is the activity of identifying commonality among concepts and defining
superclass (general concept) and subclass (specialized concept) relationships.

Defining Conceptual Superclasses and Subclasses
Definition: A conceptual superclass definition is more general or encompassing than a
subclass definition.

16. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 16

Definition: All members of a conceptual subclass set are members of their superclass set.

Conceptual Subclass Definition Conformance
When a class hierarchy is created, statements about superclasses that apply to subclasses are
made.
Example: All Payments have an amount and are associated with a Sale.


Conceptual Subclass Set Conformance
A conceptual subclass should be a member of the set of the superclass.
Example: CreditPayment should be a member of the set of Payments.

When to Define a Conceptual Subclass?
 The subclass has additional attributes of interest.
 The subclass has additional associations of interest.
 The subclass concept is operated on, handled, reacted to, or manipulated differently than
the superclass or other subclasses, in ways that are of interest.
 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?
 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 that can be factored out and expressed in the
superclass.
 All subclasses have the same association that can be factored out and related to the
superclass.

17. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 17

Example: NextGen POS Conceptual Class Hierarchies

Fig. Payment subclasses



AuthorizationService hierarchy

18. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 18

Abstract Conceptual Classes
Definition: If every member of a class C must also be a member of a subclass, then class C is
called an abstract conceptual class.


Abstract Class Notation in the UML: To review, the UML provides a notation to indicate
abstract classes the class name is italicized.


2.4.2 Association
A simple structural connection or channel between classes and is a relationship where all
objects have their own lifecycle and there is no owner.

19. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 19

2.4.3 Aggregation
 It is a vague kind of association in the UML that loosely suggests whole-part
relationships.
 It has no meaningful distinct semantics in the UML versus a plain association, but the
term is defined in the UML.
 It is a specialize form of Association where all object have their own lifecycle but there is
a ownership like parent and child.


2.4.4 Composition
 Composition is again specialize form of Aggregation.
 It is a strong type of Aggregation.
 The Parent and Child objects have coincident lifetimes.
 Child object does not have it's own lifecycle and if parent object gets deleted, then all of
it's child objects will also be deleted.


2.4.5 Dependency
 Exists between two classes if changes to the definition of one may cause changes to the
other (but not the other way around).

20. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 20

2.4.6 Packages
 When the domain model gets too large, factor it into packages of strongly related
concepts.
 A UML package is shown as a tabbed folder, with subordinate packages in it.
 <<import>> - one package imports the functionality of other package.
 <<access>> - one package requires help from functions of other package.
Example:


2.5 When to Use Class Diagram?
For modeling
 The vocabulary of the system: Represents the abstractions and their responsibilities
 The collaboration of the system: Collection of classes, interfaces and other elements to
work together.
 The logical database schema: Conceptual design of the databases.

2.6 Relationship between Sequence Diagrams and Use Cases
 Sequence Diagrams are interaction diagrams that detail how operations are carried out.
 They illustrate how the different parts of a system interact with each other to carry out a
function, and the order in which the interactions occur when a particular use case is executed.
2.6.1 Notations Used
 Lifeline Notation
o A sequence diagram is made up of several of these lifeline notations.
o No two lifeline notations should overlap each other.
o They represent the different objects that interact with each other in the system.

21. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 21

o A lifeline notation with an actor element symbol is used when the sequence diagram is
owned by a use case.

Lifeline Activation Bar
 Activation Bar
o Activation bar is the box placed on the lifeline.
o It indicates that an object is active (or instantiated) during an interaction between two
objects.
o The length of the rectangle indicates the duration of the interaction.
 Message Arrows
o An arrow from the Message Caller to the Message Receiver specifies a message.
o The message can flow in any direction; from left to right, right to left and back to the
caller itself.
o The description of the message should go on the arrow.
o Arrow heads may change according to different message types.
o Message Types:
 A synchronous message is used when the sender waits for the receiver to process
the message and return before carrying on with another message
 An asynchronous message is used when the message caller does not wait for the
receiver to process the message and return before sending other messages to other
objects within the system
 A return message is used to indicate that the message receiver is done processing
the message and is returning control over to the message caller.
 When an object sends a message to itself, it is called a reflexive message. It is
indicated with a message arrow that starts and ends at the same lifeline
 Participant Creation Message: Objects can be created in the middle of a
sequence. The dropped participant box notation is used when you need to show
that the particular participant did not exist until the create call was sent.
 Participant Destruction Message: Participants, when no longer needed, can also
be deleted from a sequence diagram. This is done by adding an „X‟ at the end of
the lifeline of the said participant.

22. CS8592 Object Oriented Analysis and Design Unit II

III IT Prepared by Kaviya.P, AP/IT Page 22


 Comments
o UML generally permits the annotation of comments in all UML diagram types.
o The comment object is a rectangle with a folded-over corner as shown below.
o The comment can be linked to the related object with a dashed line.
2.6.2 How to draw Sequence Diagram?
 A sequence diagram represents the scenario or flow of events in one single use case.
 The message flow of the sequence diagram is based on the narrative of the particular use
case.
 Before you start drawing the sequence diagram or decide what interactions should be
included in it, you need to ready a comprehensive description of the particular use case.
Steps:
1. Identify the objects or participants in the use case.
2. List down the steps involved in the execution of the use case.
3. Identify which messages should be passed between the objects we identified earlier as the
system executes these steps. Then draw the sequence diagram.