OOAD Static UML Diagram

1. Object Oriented Analysis and Design
(CS8592)
VELAMMAL ENGINEERING COLLEGE
An Autonomous Institution, Affiliated to Anna University Chennai,
& Approved by AICTE Delhi

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

3. 1.0 Class Diagram
Class Diagram:
The UML includes class diagrams to illustrate classes,
interfaces, and their associations. They are used for static
object modeling. We've already introduced and used this
UML diagram while domain modeling, applying class
diagrams in a conceptual perspective.
Applying UML: Common Class Diagram Notation
Much of the high-frequency class diagram notation can be
summarized (and understood) in one figure:Most elements
in ​Figure 16.1 are optional (e.g., +/- visibility​, parameters,
compartments). Modelers draw, show or hide them
depending on context and the needs of the reader or UML
tool.

5. Class Diagram
Design Class Diagram
The same UML diagram can be used in multiple perspectives (​Figure
16.2​). In a conceptual perspective the class diagram can be used to
visualize a domain model. A common modeling term for this
purpose is design class diagram (DCD), 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.
Figure 16.2. UML class diagrams in two
perspectives​.

6. Classifier
Classifier
• A UML classifier is "a model element that
describes behavioral and structure features".
Classifiers can also be specialized. They are a
generalization of many of the elements of the
UML, including classes, interfaces, use cases,
and actors. In class diagrams, the two most
common classifiers are ​regular classes and
interfaces​.

7. UML Attributes
Ways to Show UML Attributes: Attribute Text and
Association Lines
• Attributes of a classifier (also called structural properties in
the UML) are shown several ways:Often shortened to
"property" with the disadvantage of causing ambiguity
versus the more general definition of a UML property .
• attribute text notation, such as currentSale : Sale.
• association line notation
• both together
• Figure 16.3 shows these notations being used to indicate
that a Register object has an attribute (a reference to) one
Sale object.

8. Fig 16.3:notations to represent
attribute

9. UML NOTATION-ASSOCIATION END
The UML Notation for an Association End
• The end of an association can have a navigability arrow. It can also include
an optional rolename (officially, an association end name) to indicate the
attribute name. And of course, the association end may also show
a multiplicity such as '*' or '0..1'. Notice in ​Figure 16.3 that the
rolename currentSale i​s used to indicate the attribute name.
• And as shown in ​Figure 16.6​, a property string such as {ordered} or
{ordered, List} is possible. {ordered} is a UML-defined keyword that implies
the elements of the collection are (the suspense builds…) ordered.
Another related keyword is {unique}, implying a set of unique elements.
Figure 16.6. Two ways to show a collection attribute in the UML.

10. Figure 16.7. How to show a method
body in a class diagram.
An operation is not a method. A UML operation is a declaration,
with a name, parameters, return type, exceptions list, and possibly
a set of constraints of pre-and post-conditions.
How to Show Methods in Class Diagrams?
A UML method is the implementation of an operation; if constraints
are defined, the method must satisfy them. A method may be
illustrated several ways, including:
•in interaction diagrams, by the details and sequence of messages
in class diagrams, with a UML note symbol stereotyped with
«method»

11. A few sample predefined UML
keywords include
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
in class diagrams, at
an association end
order

12. Generalization, Abstract Classes,
Abstract Operations
• Generalization A taxonomic relationship between a more
general classifier and a more specific classifier. Each
instance of the specific classifier is also an indirect instance
of the general classifier. Thus, the specific classifier
indirectly has features of the more general classifier.
• Abstract classes and operations can be shown either with
an {abstract} tag (useful when sketching UML) or by
italicizing the name (easy to support in a UML tool).
• The opposite case, final classes and operations that can't be
overridden in subclasses, are shown with the {leaf} tag.

13. Dependency
• Dependency lines may be used on any diagram, but are especially common on class and package
diagrams. The UML includes a general dependency relationship that indicates that a client
element (of any kind, including classes, packages, use cases, and so on) 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.
• Dependency can be viewed as another version of ​coupling​,a traditional term in software
development when an element is coupled to or depends on another.
• There are many kinds of dependency; here are some common types in terms of objects and class
diagrams:
– having an attribute of the supplier type
– sending a message to a supplier; the visibility to the supplier could be:
• an attribute, a parameter variable, a local variable, a global variable, or class visibility
(invoking static or class methods)
– receiving a parameter of the supplier type
– the supplier is a superclass or interface
• In class diagrams use the dependency line to depict global, parameter variable, local variable,
and static-method (when a call is made to a static method of another class) dependency between
objects.

14. For example, the following Java code shows an updatePriceFor method in the
Sale class:
public class Sale
{
public void updatePriceFor( ProductDescription description )
{
Money basePrice = description.getPrice(); //…
}
– …
}
The updatePriceFor method receives a ProductDescription parameter object
and then sends it a getPrice message. Therefore, the Sale object has
parameter visibility to the ProductDescription, and message-sending
coupling, and thus a dependency on the ProductDescription. If the latter
class changed, the Sale class could be affected. This dependency can be
shown in a class diagram (​Figure 16.9​).

15. Figure 16.9. Showing dependency.

16. Interfaces
The UML provides several ways to show interface implementation, providing an interface to
clients, and interface dependency (a required interface). In the UML, interface implementation is
formally called interface realization
Figure 16.12. Different notations to show interfaces in UML

17. Composition Over Aggregation
• Aggregation is a vague kind of association in the UML that loosely suggests whole-part
relationships (as do many ordinary associations).
• Composition​, is a strong kind of whole-part aggregation and is useful to show in some
models. A composition relationship implies that 1) an instance of the part (such as a Square)
belongs to only one composite instance (such as one Board) at a time, 2) the part must
always belong to a composite (no free-floating Fingers), and 3) the composite is responsible
for the creation and deletion of its partseither by itself creating/deleting the parts, or by
collaborating with other objects.
• The UML notation for composition is a filled diamond on an association line, at the
composite end of the line (see ​Figure 16.13​).

18. Constraints
Constraints may be used on most UML diagrams, but are especially common on class
diagrams. A UML constraint is a restriction or condition on a UML element. It is visualized in
text between braces; for example: { size >= 0 }.

19. Qualified Association
• A qualified association has a qualifier that is used to select an object (or objects) from a
larger set of related objects, based upon the qualifier key.
• For example, if a ProductCatalog contains many ProductDescriptions, and each one can be
selected by an itemID, then the UML notation in ​Figure 16.15​can be used to depict this.
• Figure 16.15. Qualified associations in the UML​.

20. Association Class
• An association class allows you treat an association itself as a class, and model it with
attributes, operations, and other features. For example, if a Company employs many Persons,
modeled with an Employs association, you can model the association itself as the
Employment class, with attributes such as startDate.
• In the UML, it is illustrated with a dashed line from the association to the association class.
See ​Figure 16.16.

21. Singleton Classes
In the world of OO design patterns, there is one that is especially common, called the Singleton pattern.
There is only one instance of a class instantiated never two. In other words, it is a "singleton" instance. In a
UML diagram, such a class can be marked with a '1' in the upper right corner of the name compartment.
• Figure 16.17. Showing a singleton

22. Template Classes and Interfaces
Many languages (Java, C++, …) support templatized types, also known (with shades of variant meanings)
as templates, parameterized types, and generics. They are most commonly used for the element type of
collection classes, such as the elements of lists and maps. For example, in Java, suppose that a Board
software object holds a List (an interface for a kind of collection) of many Squares
public class Board
{
private List<Square> squares = new ArrayList<Square>();
…
}
Figure 16.18. Templates in the UML.

23. User-Defined Compartments
In addition to common predefined
compartments class compartments such as
name, attributes, and operations, user-
defined compartments can be added to a class
box

24. Active Class
An active object runs on and controls its own
thread of execution. Not surprisingly, the class
of an active object is an active class. In the
UML, it may be shown with double vertical
lines on the left and right sides of the class
box

25. 2.0 DOMAIN MODEL
what is a 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 (the term used in the first edition of this book), domain object
models, and analysis object models.
• They are also related to conceptual entity relationship models, which are capable of showing purely conceptual
views of domains, but that have been widely re-interpreted as data models for database design. Domain models
are not data models.
Definition
• In the UP, the term "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.
• More precisely, the UP Domain Model is a specialization of the UP Business Object Model (BOM) "focusing on
explaining 'things' and products important to a business domain.
• Applying UML notation, a domain model is illustrated with a set of class diagrams in which 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

26. 2.1 Conceptual classes
Definition: 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. More formally, a conceptual
class may be considered in terms of its symbol, intension, and extension. (see ​Figure
9.5​).
• 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.

27. Guideline: How to Create a Domain
Model?
• Find the conceptual classes (see a following guideline).
• Draw them as classes in a UML class diagram.
• Add associations and attributes​.
Guideline: How to Find Conceptual Classes?
• Since a domain model shows conceptual classes, a central question is: How do I find them?
What are Three Strategies to Find Conceptual Classes?
• Reuse or modify existing models.
• Use a category list.
• Identify noun phrases.
Method 2: Use a Category List
We can kick-start the creation of a domain model by making a list of candidate conceptual classes. ​Table 9.1
contains many common categories that are usually worth considering, with an emphasis on business
information system needs. The guidelines also suggest some priorities in the analysis. Examples are drawn
from the 1) POS, 2) Monopoly, and 3) airline reservation domains.

28. Conceptual Class Category Examples
business transactions
Guideline: These are critical (they involve
money),
So start with transactions.
Sale, Payment
Reservation
transaction line items
Guideline: Transactions often come with
related line items, so consider these next. SalesLineItem
product or service related to a transaction
or transaction line item
Guideline: Transactions are for something
(a product or service). Consider these
next.
Item
Flight, Seat, Meal
where is the transaction recorded?
Guideline: Important.
Register, Ledger
FlightManifest
roles of people or organizations related
to the transaction; actors in the use case
Guideline: We usually need to know
about the parties involved in a
transaction.
Cashier, Customer, Store
MonopolyPlayer
Passenger, Airline

29. Conceptual Class Category Examples
roles of people or organizations related to
the transaction; actors in the use case
Guideline: We usually need to know about
the parties involved in a transaction
Cashier, Customer, Store MonopolyPlayer
Passenger, Airline
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
Guideline: This is especially relevant when
creating device-control software, or
simulations. Item, Register Board, Piece, Die 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

30. Conceptual Class Category Examples
things in a container Item Square (in a Board) Passenger
other collaborating systems
CreditAuthorizationSystem
AirTrafficControl
records of finance, work, contracts, legal
matters
Receipt, Ledger
MaintenanceLog
financial instruments
Cash, Check, LineOfCredit
TicketCredit
schedules, manuals, documents that are
regularly referred to in order to perform
work
DailyPriceChangeList
RepairSchedule
Method 3: Finding Conceptual Classes with Noun Phrase Identification
Another useful technique (because of its simplicity) suggested is linguistic analysis: Identify
the nouns and noun phrases in textual descriptions of a domain, and consider them as
candidate conceptual classes or attributes.

31. Example: Find and Draw Conceptual
Classes

32. 3.0 Description Classes
Guideline: When to Model with 'Description'
Classes?
A description class contains information that
describes something else. For example, a
ProductDescription that records the price,
picture, and text description of an Item. This
was first named the Item-Descriptor pattern.

33. Description classes
Guideline: When Are Description Classes Useful?
Guideline
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

34. Description classes
Example: Descriptions in the Airline Domain
As another example in fig 9.10, consider an airline company that suffers a
fatal crash of one of its planes. Assume that all the flights are cancelled for
six months pending completion of an investigation. Also assume that
when flights are cancelled, their corresponding Flight software objects are
deleted from computer memory. Therefore, after the crash, all Flight
software objects are deleted.
Figure 9.10. Descriptions about other things.

35. 4.0 Associations
An ​association is a relationship between
classes (more precisely, instances of those
classes) that indicates some meaningful and
interesting connection (see ​Figure 9.11​).

36. Association
Guideline: Why Should We Avoid Adding Many Associations?
A domain model with 20 classes could have 190 associations lines! Many lines on the diagram
will obscure it with "visual noise.“
Perspectives: Will the Associations Be Implemented In Software?
Many of these relationships will be implemented in software as paths of navigation and
visibility (both in the Design Model and Data Model). But the domain model is not a data
model; associations are added to highlight our rough understanding of noteworthy
relationships, not to document object or data structures.
Applying UML: Association Notation
An association is represented as a line between classes with a capitalized association name.See
Figure 9.12.​

37. UML:Roles
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 (see ​Figure 9.13​).

38. • Some examples of multiplicity expressions are
shown in ​Figure 9.14​.
• Figure 9.14. Multiplicity values.

39. MULTIPLICITY
The multiplicity value is dependent on our
interest as a modeler and software developer,
because it communicates a domain constraint
that will be (or could be) reflected in software.
See ​Figure 9.15 for an example and
explanation.

40. Multiple association between 2 classes
Applying UML: Multiple Associations Between Two Classes
Two classes may have multiple associations between them in a UML class
diagram; this is not uncommon. There is no outstanding example in the POS or
Monopoly case study, but an example from the domain of the airline is the
relationships between a Flight (or perhaps more precisely, a FlightLeg) and an
Airport (see ​Figure 9.16​); the flying-to and flying-from associations are
distinctly different relationships, which should be shown separately.

41. Association
Example: Associations in the Domain Models
Case Study: NextGen POS
Figure 9.17. NextGen POS partial domain model.

42. 5.0 Attributes
Attributes
It is useful to identify those attributes of conceptual classes that are needed to satisfy the information
requirements of the current scenarios under development. An ​attribute is a logical data value of an object.
Guideline: When to Show Attributes?
• Include attributes that the requirements (for example, use cases) suggest or imply a need to remember
information.
• For example, a receipt (which reports the information of a sale) in the Process Sale use case normally includes a
date and time, the store name and address, and the cashier ID, among many other things. Therefore,
• 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 (see ​Figure 9.19​). Their type and other
information may optionally be shown.

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

44. Attributes
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, but 2) it is derivable, we use the UML convention: a / symbol before the
attribute name.
• As another example, a cashier can receive a group of like items (for example, six
tofu packages), enter the itemID once, and then enter a quantity (for example, six).
Consequently, an individual SalesLineItem can be associated with more than one
instance of an item.
• The quantity that is entered by the cashier may be recorded as an attribute of the
SalesLineItem (​Figure 9.21​). However, the quantity can be calculated from the
actual multiplicity value of the association, so it may be characterized as a derived
attribute one that may be derived from other information.

45. CASE STUDY:NEXTGEN POS

46. Case Study: Monopoly

47. 6.0 Relationship between sequence
diagrams and use cases

48. 7.0 Aggregation and Composition
BASIS FOR COMPARISON AGGREGATION COMPOSITION
Basic In aggregation there
exhibita relationship where
a child can exist
independently of the
parent.
In composition the child
cannot exist independently
of the parent.
Type of Relationship “has-a” “Part of”
Association type Weak association Strong association
UML Design Symbol Represented by a hollow
diamond next to assembly
class.
Represented by a solid
diamond next to assembly
class
Function The deletion of assembly
doesn't affect its parts.
If the owning class object
is deleted it could
significantly affect the
containing class object.

49. Aggregation
The aggregation is a type of association which
describes a​“has a”​type of relationship
between the objects. For instance, ​a car “has
a” gearbox, and a car “has an” engine​. For the
one-to-many relationship, an example is ​a car
“has” many wheels​.

50. COMPOSITION
• The composition ​is also a type of association but a
more restrictive form. It is represented in UML by a
tinysolid diamond adjacent to the assembly
class.
• composition signifies ownership of the constituent
part of the whole. This would ultimately increase the
convenience for the programming. The composition
can trigger the deletion of the constituent object by
the deletion of an assembly object.
• The composition describes a​“part of”​relationship. For
example, ​a leaf is a part of a tree​,if the tree is
destroyed, then leaves also must be destroyed.

51. 8.0 Domain Model Refinement
Generalization
• Generalization is the activity of identifying commonality among concepts
and defining superclass (general concept) and subclass (specialized
concept) relationships.
• The concepts CashPayment, CreditPayment, and CheckPayment are all
very similar. In this situation, it is possible (and useful[1]) to organize them
(as in Figure 32.1) into a generalization-specialization class hierarchy (or
simply class hierarchy) in which the superclass Payment represents a
more general concept, and the subclasses more specialized ones.

52. Class Hierarchy

53. Class Set
Generalization and Class Sets
• Conceptual subclasses and superclasses are related in terms of set
membership.
Definition
• All members of a conceptual subclass set are members of their superclass
set
For example, in terms of set membership, all instances of the set CreditPayment are
also members of the set Payment. In a Venn diagram, this is shown as in Figure 32.4

54. Subclass conformance
Subclass Definition Conformance
• When a class hierarchy is created, statements about superclasses that apply to
subclasses are made. For example, Figure 32.5 states that all Payments have an amount
and are associated with a Sale.
• All Payment subclasses must conform to having an amount and paying for a Sale. In
general, this rule of conformance to a superclass definition is the 100% Rule:
Guideline: 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

55. Subclass conformance
Guideline: Is-a Rule
• All the members of a subclass set must be
members of their superclass set.
• In natural language, this can usually be informally
tested by forming the statement: Subclass is a
Superclass.
Correct Conceptual Subclass?
A potential subclass should conform to the:
• 100% Rule (definition conformance)
• Is-a Rule (set membership conformance)

56. Conceptual Superclass
When to Define a Conceptual Superclass?
Create a 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 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.

57. NextGen POS Conceptual Class
Hierarchies

58. NextGen POS Conceptual Class
Hierarchies

59. Partition 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

60. Domain Packages

61. 9.0 WHEN TO USE CLASS DIAGRAM
• Describing the static view of the system.
• Showing the collaboration among the
elements of the static view.
• Describing the functionalities performed by
the system.
• Construction of software applications using
object oriented languages

62. Sample Class Diagrams

63. Online Shopping-Class Diagram

65. THANK U