Making Design Class Diagram

Lecture 05
Course Instructor: Dr Usman Nasir
Course Code: SE331
Spring 2020

Y2020 Ver 1.0

Exercise: 01
— From the given sequence diagram identify classes
and methods and then write C++ code of all three
classes.
:Register :Sale
:SalesLineItem
makeNewSale()

create()

create()
Exercise: 02
— Write C++/Java code for this Communication
diagram…
enterItem (itemID, quantity)
:Register

1: getSpecification(itemID)

:ProductCatalog

1.1: spec:= find(itemID)

:ProductSpecification
Visibility
Visibility
— Visibility is the ability of an
object to “see” or have addLineItem(itemID, quantity)

reference to another object.

— The sender must have some :Register
kind of reference (or pointer)
to the receiver object.
— The getSpecification message sent
from a Register to a 1: getSpecification (itemID)
ProductCatalog, implies that the
ProductCatalog instance is :ProductCatalog
visible to the Register instance.
— How do we determine whether one resource (such
as an instance) is within the scope of another?
— Visibility can be achieved from object A to object B
in four common ways:
— 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.
Attribute Visibility
— Attribute visibility from A to B exists when B is an
attribute of A.
— It is a relatively permanent visibility, because it persists as
long as A and B exist.
— In the addLineItem collaboration diagram, Register
needs to send message getSpecification message to a
ProductCatalog.
— Thus, visibility from Register to ProductCatalog is
required.
 Attribute Visibility

addLineItem(itemID, quantity) class Register {

private:
ProductCatalog catalog;
public:
:Register void addLineItem (int itemID, int
quantity){

ProductSpecification spec =
catalog.getSpecification(itemID);
1: spec :=
getSpecification(itemID) }

:ProductCatalog
Parameter Visibility
— Parameter visibility from A to B exists when B is
passed as a parameter to a method of A.
— It is a relatively temporary visibility, because it persists
only within the scope of the method.

— When the makeLineItem message is sent to a Sale

instance, a ProductSpecification instance is passed as
a parameter.
— There is no need to declare ProductSpecification as instance
variable in Sale
 void makeLineItem(ProductSpecification spec, int quantity) {
…
sli = new SalesLineItem(spec, quantity);
…
}

addLineItem(itemID,quantity) 2: makeLineItem(spec, quantity)

:Register :Sale

1: spec := getSpecification(itemID) 2.1: create(spec, quantity)

: ProductCatalog sli: SalesLineItem

— When Sale creates a new SalesLineItem, it passes a
ProductSpecification to its constructor.
— We can assign ProductSpecification to an attribute in the
constructor, thus transforming parameter visibility to
attribute visibility.
class SalesLineItem{
// constructor
private:
ProductSpecification productSpec;
public:
SalesLineItem(ProductSpecification spec, int quantity) {
// parameter to attribute visibility
productSpec = spec;
}
Local Visibility
— Locally declared visibility from A to B exists when B
is declared as a local object within a method of A.
— It is relatively temporary visibility because it persists only
within the scope of the method.
— This can be achieved as follows:
— Create a new local instance and assign it to a local variable.
— Assign the return object from a method invocation to a local
variable.
void addLineItem(int itemID, int quantity) {
…
ProductSpecification spec = catalog.getSpecification(itemID);
...
}
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.
— One way to achieve this is to assign an instance to a
global variable (possible in C++ but not in Java).
Design Class Diagrams
Design Class Diagram (DCD)
— A Design class diagram (DCD) shows software
entities using UML notation to define design details
in static structure.
— We need to identify the specification for the
software classes.
— The DCD depends upon the Domain Model and
interaction diagrams.
— Typical information in a DCD includes:
— Classes, associations and attributes
— Functions or Methods in class
— Attribute type information
— Navigability
— Inheritance (if any!!)
DCD: An Example
Three section box Navigability

Register Sale

Date
isComplete : Boolean
1 Captures 1 time
addLineItem(…)
… makeLineItem()

parameters can be specified Type information

NextGen POS DCD
— Steps
— Identify all the classes participating in the software
solution.
— Drawing a class diagram by analyzing the interaction
diagrams and duplicate the attributes from the associated
concepts in the Domain Model.
— Add method names by analyzing the interaction diagrams.
— The methods for each class can be identified by analysing
the interaction diagrams.
 Sale
If the message makeLineItem is
sent to an instance of class date
Sale, then class Sale must isComplete
define a makeLineItem function. time

makeLineItem()

3: makeLineItem(spec, quantity)
:Register :Sale
— Add type information to the attributes and methods.

Register ProductCatalog ProductSpecification Payment

description amount
price
endSale() getSpecification() itemID
addLineItem()
makeNewSale()
makePayment() Sale

date SalesLineItem
isComplete: Boolean
Store time Quantity: Integer

Address: String becomeComplete() getSubtotal()

Name: String makeLineItem()
makePayment()
addSale() getTotal()
Method Names -Multiobjects
— The find message to the multi-object should
be interpreted as a message to the container/
collection object. 1: spec := getSpecification(id)
— The find method is not part of the
ProductSpecification class.
:ProductCatalog

1.1: spec := find(id)

— Find,Add, Delete to multi-objects
are treated same :ProductSpecification
Associations & Navigability
— Add the associations necessary to support the
required attribute visibility.
— Each end of an association is called a role.
— Navigability is a property of the role implying
visibility of the source to target class.
— Attribute visibility is implied.
— Add navigability arrows to the associations to indicate the
direction of attribute visibility where applicable.
 — Common situations suggesting a need to define an
association with navigability from A to B:
— A sends a message to B.
— A creates an instance of B.
— A needs to maintain a connection to B
— Dependency Relationships lines indicate non-
attribute visibility.
Creating a NextGen POS DCD
Register class will probably Navigability arrow indicates
have an attribute pointing to a Register objects are connected
Sale object. uni-directionally to Sale objects.

Register Sale

Date
1 Captures 1 isComplete : Boolean
time
endSale()
addLineItem()
makeLineItem()
makePayment()

Absence of navigability arrow

indicates no connection from
Sale to Register.
 Uses
Store 1 ProductSpecification
address : Address 1
1 name : Text description : Text
ProductCatalog price : Money
addSale() Contains *
itemID: itemID
1 1
1 Looks-in getSpecification()
1
Houses
Describes
1 Illustrates non-attribute visibility
1 *
Register
Sale SaleLineItem
Captures Contains
Date : Date quantity : Integer
endSale() 1 1 1
isComplete : Boolean * getSubtotal()
enterItem() time : Time
makePayment() becomeComplete()
makeLineItem()
makePayment() Payment
getTotal()
amount : Money
* 1
Logs-completed
Paid-by 1
Mapping Designs to Code
Class with Methods & Attributes

class SalesLineItem {
private:
double quantity;
ProductSpecification productSpec;
public :
SalesLineItem( ProductSpecification spec, double qty) {...}
double getSubtotal( ) {…}
… }

ProductSpecification
SalesLineItem description : Text
1 Described-by 1
quantity : Double price : Money
itemID : int
getSubtotal():double
 Implementing Methods from Interaction
Diagrams

addLineItem(itemID, quantity)
2 : makeLineItem(spec, quantity)
:Register

1:spec := getSpecification(itemID) :Sale

:ProductCatalog

1.1:spec := find(itemID) 2.2 : add(sli) 2.1 : create(spec, quantity)

:ProductSpecification sli:SalesLineItem
:SalesLineItem
class Register {
private:
ProductCatalog catalog;
Sale tempSale;
public:
void addLineItem(int itemID, double quantity){
ProductSpecification spec;
spec = catalog.getSpecification(itemID);//1
tempSale.makeLineItem(spec, quantity);//2 }
}//end of class
class Sale{
private: SalesLineItem sale_items[100]; int count;
public:
void makeLineItem(ProductSpecification spec, double
quantity){

SalesLineItem sli(spec, quantity); //2.1

sale_items [count]=sli;//2.2 add to SalesLineItem
Collection
count++;
}
//Try writing SalesLineItem class on your own now….
class ProductCatalog {
private:
ProductSpecification productSpecs [100];
int count;
public:
ProductSpecification getSpecification(int itemID) {
for (int i=0; i < count, i++){
if(productSpecs[i].getitemID() == itemID)
return productSpecs[i];
}
return null;
} //Try writing ProductSpecification class on your
own now….
Register – addLineItem method
— The addLineItem collaboration diagram will be used to
illustrate the C++ definition of the addLineItem
method.
— In which class does addLineItem belong to?
— The addLineItem message is sent to a Register instance,
therefore the addLineItem method is defined in class Register.
— public void addLineItem(int itemID, int quantity);
— Message 1. A getSpecification( ) message is sent to the
ProductCatalog to retrieve a ProductSpecification
— ProductSpecification spec = catalog.getSpecification(itemID);
— Message 2: The makeLineItem message is sent to the Sale.
— sale.makeLineItem(spec, quantity);
Skeletal Definition
— Skeletal Definition is class definition with
method/function declarations, attributes and
visibility of each class

— Skeletal definition for classes can be drawn using

collaboration diagram or even DCDs.
— Interaction diagram lead to implementation too, but
DCD alone can only give skeletal definition of
classes
— Write Skeletal
definitions for this ProductCatalog

class diagram?
getSpecification()

Looks-in

1 Sale
Register
Date : Date
Captures isComplete : Boolean
1 time : Time
endSale() 1
becomeComplete()
addLineItem()
makeLineItem()
makeNewSale()
makePayment()
makePayment()
getTotal()
Thank you!!!!
— Chapter 18,19, 20 …..
— Must read Chapter 19 Section 19.5 and 19.6 for
details