Visibility and Class DiagramsS a leS to r eS a le s L in e Ite mP a y m e n t

12/25/2014
Visibility and Class Diagrams
Design Model: Determining Visibility

Objectives
Identify four kinds of visibility
Design to establish visibility
Illustrate kinds of visibility in the UML notation
Visibility between Objects
Visibility is the ability of one object to see or have reference to
another. The designs created for the system events (enterItem in
Figure 11.1) illustrate messages between objects.
For a sender object to send a message to a receiver object, the
sender must be visible to the receiver the sender must have
some kind of reference or pointer to receiver object.
When creating a design of interacting objects, it is necessary to
ensure that the visibility is present to support message
interaction.
Visibility
and Class
Diagrams
MTI8305 - Software Modeling
12/25/2014
Visibility between Objects

For example, the getSpecification message sent from a Register to a
ProductCatalog implies that the ProductCatalog instance is visible to
the Register instance as shown in Figure 11.1 below:
class Register
{
...
private ProductCatalog catalog;
...
}
: Register
: ProductCatalog
enterItem
(itemID, quantity)
spec := getSpecification( itemID )
{
public void enterItem( itemID, qty )
{
...
spec = catalog.getSpecification(itemID)
...
}
}
Figure 11.1: Visibility from the Register to ProductCatalog is required.

Visibility
and Class
Diagrams
Visibility
Visibility is the ability to an object to see or have a reference to another
object.
It is related to issue of scope: Is one resource (e.g. instance) within
scope of another? Four common ways that visibility can be achieved from
object A to object B are:
Attribute Visibility B is an attribute of A.
Parameter Visibility B is a parameter of a method of A.
Local Visibility B is a (non-parameter) local object in a method of A.
Global Visibility B is in some way globally visible.
The motivation to consider visibility is:
For an object A to send a message to an object B, B must be visible to
A.
For example, to create an interaction diagram in which a message is
sent from a Register instance to a ProductCatalog instance, the
Register must have visibility to the ProductCatalog.
A typical visibility solution is that a reference to the ProductCatalog
instance is maintained as an attribute of the Register.
Visibility
and Class
Diagrams
12/25/2014
1. Attribute Visibility
Attribute visibility from A to B exists when B is an attribute
of A, a common visibility in object-oriented systems.
It is a relatively permanent visibility because it persists as
long as A and B exist.
To illustrate, in a Java class definition, a Register instance
may have attribute visibility to a ProductCatalog, since it is
an attribute (Java instance variable) of the Register
public class Register {
private ProductCatalog catalog {

.
}
}
Visibility
and Class
Diagrams
This visibility is required because in the enterItem

diagram in Figure 11.2, a Register needs to send the
getSpecification message to a ProductCatalog
{
public void enterItem(itemID, qty)
{
...
spec = catalog.getSpecification(itemID)
...
}
}
class Register
{
...
private ProductCatalog catalog;
...
}
: Register
: ProductCatalog
enterItem
(itemID, quantity)
Figure 11.2: Attribute visibility

Visibility
and Class
Diagrams
12/25/2014
2. Parameter Visibility
Parameter visibility from A to B exists when B is passed
as a parameter to a method of A and second most
common visibility in object-oriented systems after

attribute visibility.
It is a relatively temporary visibility because it persists
only within the scope of the method.
It is common to transform parameter visibility into
attribute visibility.
To illustrate, when the makeLineItem message is sent to a
Sale instance, a ProductSpecification instance is passed
as a parameter.
Visibility
and Class
Diagrams
Within the scope of makeLineItem method, the Sale has

parameter visibility to a ProductSpecification as in Figure
11.3.
enterItem(id, qty)
:Register
2: makeLineItem(spec, qty)
:Sale
2: spec := getSpecification(id)
2.1: create(spec, qty)
:Product
Catalog
sl : SalesLineItem
// initializing method (e.g., a Java constructor)

{
SalesLineItem(ProductSpecification spec, int qty)
{
...
productSpec = spec; // parameter to attribute visibility
...
}
}
Figure 11.3: Parameter Visibility

Visibility
and Class
Diagrams
12/25/2014
3. Local Visibility
Local visibility from A to B exists when declared as a local object
within a method of A, a third most common visibility after
parameter visibility in object-oriented systems.
It is relatively temporary visibility because is persists only within
the scope of the method.
As with parameter visibility, it is common to transform locally
declared local visibility into attribute visibility.

Two common means by which local visibility is achieved are
Create a new local instance and assign it to a local variable.
Assign the returning object from a method invocation to a local
variable.
Visibility
and Class
Diagrams
An example of second variation (assigning the returning

object to a local variable) can be found in the enterItem
method of class Register as shown Figure 11.4.
{
enterItem(id, qty)
{
...
// local visibility via assignment of returning object
ProductSpecification spec = catalog.getSpecification(id);
...
}
}
: Register
: ProductCatalog
enterItem
(itemID, quantity)
Figure 11.4: Parameter to attribute visibility

Visibility
and Class
Diagrams
10
12/25/2014
4. Global Visibility
Global visibility from A to B exists when B is global to A. It is a
relatively permanent visibility because it persists as long as A
and B exist, a least common visibility in object-oriented
systems.
One way to achieve visibility is to assign an instance to a
global variable possible in C++.
The preferred method to achieve global visibility is to use the
Singleton pattern. In software engineering, the singleton
pattern is a design pattern that is used to restrict instantiation
of a class to one object.
This is useful when exactly one object is needed to coordinate
actions across the system. Sometimes it is generalized to
systems that operate more efficiently when only one or a few
objects exist.
Visibility
and Class
Diagrams
11
Illustration of visibility in UML notation to show the kind of visibility

in a collaboration diagram as shown in Figure 11.5.
association is used for
attribute visibility
1: msg()
association
:A
2: msg()
parameter
3: msg()
local
:B
:C
:D
4: msg()
global
:E
Figure 11.5: Sample design class diagram

Visibility
and Class
Diagrams
12
12/25/2014
Design Class Diagrams (DCD)

Objectives
Create design class diagrams
(DCDs).
Identify the classes, methods and
associations to show in a DCD.
Three section box for

class definition.
Sale
Creation of DCDs
DCDs are usually created in
parallel with interaction diagrams
Example DCD
Figure 11.6 illustrates a partial
software definition of the Register
and Sale classes.
Besides to basic associations and
attributes, the diagram is extended
to illustrate, for example, the
methods of each class, attribute
type information and attribute
visibility and navigation between
objects.
Visibility
and Class
Diagrams
Navigability
Register
Captures
1
date
isComplete : Boolean
1 time
enterItem(...)
makeLineItem(...)
methods; there are parameters, but unspecified
type information
Figure 11.6: Sample design class diagram
13
DCD and UP Terminology

A design class diagram (DCD) illustrates the specifications for
software classes and interfaces (e.g. Java are related methods
with empty bodies) in an application.
Typical information includes:
Classes, associations and attributes
Interfaces with their operations and constants
Methods
Attribute type information
Navigability
Dependencies
In contrast to conceptual classes in the Domain Model, design
classes in the DCDs show definitions for software classes rather
than real-world concepts.
In UP it is common to speak of design class diagrams, that is

shorter and implies class diagrams in the Design Model.
Visibility
and Class
Diagrams
14
12/25/2014
Domain Model vs. Design Model Classes

To reiterate, in UP Domain
Model, a Sale does not
represent a software
definition; it is an
abstraction of a real-world
concept which we are
Concept; conceptual class

Sale
Register
Captures
1
Domain Model
date
1 isComplete : Boolean
time
interested in making a
statement.
Register
By contrast, DCDs express

for the software application
- the definition of classes as
software components.
...
Design Model
endSale()
enterItem(...)
makePayment(...)
Captures
1
date
1 time
makeLineItem(...)
software class
In these diagrams, a Sale

represents of software
class in Figure 11.7.
Visibility
and Class
Diagrams
Sale
Figure 11.7: Domain model vs.

Design Model Classes
15
Creating a POS DCD

The first step in creation of DCDs as part of the solution model is to identify
those classes that participate in the software solution.
These can be found by scanning all the interaction diagrams and listing the
classes mentioned.
For the POS application these are: Register, Sale, ProductCatalog,
ProductSpecification, Store, SalesLineItem and Payment.
The next step is to draw a class diagram for these classes and include the
attributes previously identified in the Domain Model that are also used in the
design as Figure 11.8.
R e g is te r
P r o d u c tC a ta lo g
P r o d u c tS p e c if ic a t io n
d e s c r ip tio n
p ric e
ite m I D
...
...
...
P a ym e n t
a m o u n t
...
...
S to re
a d d re s s
n a m e
S a le
S a le s L in e Ite m
d a te
is C o m p le te
tim e
q u a n tity
...
...
...
Figure 11.8: Software classes in the application

Visibility
and Class
Diagrams
16
12/25/2014
Adding Method Names

Method names of each class can
be identified by analyzing the
interaction diagrams.
Sale
..
For example, if message

makeLineItem is sent to an
instance of class Sale, then class
Sale must define a makeLineItem
method as in Figure 11.9.
2: makeLineItem(spec, qty)
:Register
Generally, set of all messages

sent to a class X across all
interaction diagrams indicates
the majority of methods that
class X must define.
Visibility
and Class
Diagrams
makeLineItem(.. )
:Sale
Figure 11.9: Method names from

interaction diagrams
17
Adding Method Names contd

The inspection of POS yields
allocation of methods in
Figure 11.10.
...
...
Method names issues include:

Interpretation of the
create message
endSale()
enterItem(...)
makeNewSale()
makePayment(...)
getSpecification()
Depiction of accessing
methods
Store
Register
ProductCatalog
addSale(...)
Language-dependent
syntax
Visibility
and Class
Diagrams
description
price
itemID
Payment
amount
...
...
Sale
date
isComplete
time
address
name
Interpretation of
messages to multi-objects
ProductSpecification
SalesLineItem
quantity
becomeComplete()
makeLineItem(...)
makePayment(...)
getTotal()
getSubtotal()
Figure 11.10: Methods in the application
18
12/25/2014
Adding More Type Information
The types of attributes, method parameters and

method return values may all be optionally be shown.
The DCD should be created by considering the
audience:
If it is being created in a CASE tool with automatic
code generation, full and exhaustive details are
necessary.
If it is being created for software developers to read,
exhaustive low-level detail may adversely affect
noise-to-value ratio.
The amount of information shown depends on the
intended audience as in Figure 11.11.
Visibility
and Class
Diagrams
19
Adding More Information

Register
ProductCatalog
...
description : Text
price : Money
getSpecification(id: ItemID) : ProductSpecification
itemID : ItemID
...
endSale()
enterItem(id : ItemID, qty : Integer)
makeNewSale()
makePayment(cashTendered : Money)
...
Store
Sale
address : Address
name : Text
SalesLineItem
date : Date
time : Time
quantity : Integer
getSubtotal() : Money
addSale(s : Sale)
becomeComplete()
Payment
makeLineItem(spec : ProdSpecification , qty : Integer)
makePayment(cashTendered : Money)
amount
: Money
getTotal() : Money
...
Return type of method
void; no return value
Figure 11.11: Adding Type Information.

Visibility
and Class
Diagrams
20
10
12/25/2014
Adding Associations and Navigability

Each end of an
association is called a
role, and in the DCDs the
role may decorated with
navigability arrow.
Register class will

have an attribute pointing to a
Sale object.
Navigability arrow indicates

Register objects are connected
uni-directionally to Sale
objects.
Sale
Register
Navigability is a property
of role that indicates that
it is possible to navigate
uni-directionally across
association from objects
of source target class.
the currentSale
attribute is often
excluded, as it is
implied by the
navigable
association from
Register to Sale.
Captures
endSale()
enterItem(...)
makeNewSale()
makePayment(...)
1 becomeComplete()
makeLineItem(...)
makePayment(...)
getTotal()
Absence of navigability
arrow indicates no
connection from Sale to
Register.
Navigability implies
visibility usually
attribute visibility as in
Figure 11.12.
Visibility
and Class
Diagrams
currentSale : Sale
date
isComplete
time
Figure 11.12: Showing navigability

or attribute visibility
21
Associations and Navigability

The required visibility and
associations between classes
are indicated by interaction
diagrams, with common
situations suggesting an
association with a navigability
adornment from A to B:
A sends a message to B.
A creates an instance of B.
A needs to maintain a
connection to B.
create()
2: create(pc)
:Store
1: create()
:Register
1.1: create()
1.2.2*: add(ps)
pc:
ProductCatalog
:Product
Specification
1.2.1*: create(id, price, description)

1.2: loadProdSpecs()
Example is from interaction

diagram in Figure 11.13
starting with the create
message to a Store.
Visibility
and Class
Diagrams
ps:
Figure 11.13: Navigability is identified

from interaction diagrams
22
11
12/25/2014
Navigability and Dependency Relationships

Navigability
Starting from create message to a Store and the
interaction diagram in Figure 11.13, Store has connection
to Register and ProductCatalog instances it created.
Further the ProductCatalog needs an ongoing connection
to the ProductSpecifications it created.
Based in above criterion for associations and navigability,
analysis of POS application yields class diagram 11.14,
shown by the arrows.
Adding Dependency Relationships
UML includes a general dependency relationship which
indicates that one element has knowledge of another
element.
It is illustrated by the dashed arrow lines.
Visibility
and Class
Diagrams
Store
1
23
Uses
address : Address
name : Text
1
1
ProductCatalog
addSale(...)
1
Looks-in
Contains
...
1..*
description : Text
price : Money
itemID: ItemID
getSpecification(...)
...
Houses
1
Register
...
Captures
endSale()
enterItem(...)
makeNewSale()
makePayment(...)
1
Describes
Sale
Logs-completed
4
date : Date
time : Time
1
becomeComplete()
makeLineItem(...)
makePayment(...)
getTotal()
*
SalesLineItem
Contains
quantity : Integer
1..*
getSubtotal()
Payment
Paid-by
1
A dependency of Register knowing about

ProductSpecification.
amount : Money
...
Recommended when there is parameter,

global or locally declared visibility.
Figure 11.14: Association with navigability adornment and dependency relationships indicating non-attribute
Visibility
and Class
Diagrams
24
12
12/25/2014
Exercises
1. (Group) Information system for a Library
Using the confirmMembership operation contract as a starting hint,
complete the UML collaboration diagram. Annotate every message
with the hint GRASP (Expert, Creator, and so on) and/or other
pattern that justifies it. If you add responsibilities not explicit in the
contract (because you think they are important to fulfill), please
briefly explain these additions.
by Controller
confirmMembership(membershipID)
Visibility
and Class
Diagrams
25
Exercises
2. (Individual) Information system for a Car Rental Centre
Using the confirmMembership operation contract as a starting hint,

complete the UML collaboration diagram. Annotate every message with
the hint GRASP (Expert, Creator, and so on) and/or other pattern that
justifies it. If you add responsibilities not explicit in the contract
(because you think they are important to fulfill), please briefly explain
these additions.
Visibility
and Class
Diagrams
26
13
12/25/2014
Ole Sangale Road, Madaraka Estate. PO Box 59857-00200, Nairobi, Kenya

Tel +254 (0)20 606155, 606268, 606380 Fax +254 (0)20 607498
Mobile +254 (0)722 25 428, (0)733 618 135 Email info@strathmore.edu
www.strathmore.edu
14

Visibility and Class DiagramsS a leS to r eS a le s L in e Ite mP a y m e n t

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Visibility and Class DiagramsS a leS to r eS a le s L in e Ite mP a y m e n t

Caricato da

Copyright:

Formati disponibili

12/25/2014

Visibility and Class Diagrams

Design Model: Determining Visibility

MTI8305 - Software Modeling

Visibility between Objects

Figure 11.1: Visibility from the Register to ProductCatalog is required.

MTI8305 - Software Modeling

MTI8305 - Software Modeling

private ProductCatalog catalog {

MTI8305 - Software Modeling

This visibility is required because in the enterItem

Figure 11.2: Attribute visibility

MTI8305 - Software Modeling

common visibility in object-oriented systems after

MTI8305 - Software Modeling

Within the scope of makeLineItem method, the Sale has

// initializing method (e.g., a Java constructor)

Figure 11.3: Parameter Visibility

MTI8305 - Software Modeling

declared local visibility into attribute visibility.

MTI8305 - Software Modeling

An example of second variation (assigning the returning

Figure 11.4: Parameter to attribute visibility

MTI8305 - Software Modeling

MTI8305 - Software Modeling

Illustration of visibility in UML notation to show the kind of visibility

Figure 11.5: Sample design class diagram

MTI8305 - Software Modeling

Design Class Diagrams (DCD)

Three section box for

MTI8305 - Software Modeling

Figure 11.6: Sample design class diagram

DCD and UP Terminology

than real-world concepts.

In UP it is common to speak of design class diagrams, that is

MTI8305 - Software Modeling

Domain Model vs. Design Model Classes

Concept; conceptual class

By contrast, DCDs express

MTI8305 - Software Modeling

In these diagrams, a Sale

Figure 11.7: Domain model vs.

Creating a POS DCD

Figure 11.8: Software classes in the application

MTI8305 - Software Modeling

Adding Method Names

For example, if message

Generally, set of all messages

Figure 11.9: Method names from

MTI8305 - Software Modeling

Adding Method Names contd

Method names issues include:

MTI8305 - Software Modeling

Figure 11.10: Methods in the application

Adding More Type Information

The types of attributes, method parameters and

MTI8305 - Software Modeling

Adding More Information

Return type of method

void; no return value

Figure 11.11: Adding Type Information.

MTI8305 - Software Modeling