Unit III

Elaboration

System sequence diagrams for use case model, Domain model : identifying concepts, adding
associations, adding attributes, Interaction Diagrams, Introduction to GRASP design Patterns
,Design Model: Use case realizations with GRASP patterns, Design Class diagrams in each
MVC layer Mapping Design to Code, Design class diagrams for case study and skeleton code

System sequence diagrams for use case model

SSD(System Sequence Diagram) is a fast and easily created artifact that illustrate input and
output events related to the system.

Sequence Diagrams

UML provides a graphical means of depicting object interactions over time in Sequence
Diagrams. These typically shows an user or actor, and the objects or components they interact
within the execution of a use case.

One sequence diagram typically represents a single use case 'scenario' or flow of events.

Sequence diagrams are an excellent way to document users scenarios and to capture required
objects early in analysis and to verify its object usage later in design.

Sequence diagram shows the flow of messages from one object to another and as such
correspond to the methods and events supported by a class/object.

The diagram illustrated below shows an example of a sequence diagram with the user or actor on
the left initiating a flow of events and messages that correspond to the use case scenario.

The messages that pass between objects will become class operations in the final model.
 Use case scenario

SSD:

Use case describes how external actors interact with the system. During interaction, an actor
generates system events to a system representing some system operation.

Sequence diagram also says the actor interaction and the operations initiated by them .

SSD shows one particular scenario of use case

• Events that actors generate

• Their order

• Inter system event

We have to design the software to handle these events and execute a response. These works are
done by SSD.

Basically software system reacts three things

• External events from actor

• Time events

• Fault or exceptions
External events:

It affects the system events.

Used for analyzing the system behavior.

It explains what a system does and it does not explain what a system is doing.

Applying UML: Sequence Diagram

Interaction frame is used to show loops in sequence diagram.

Relationship between SSD and use case:

SSD shows the system event for one scenario of use case. Use case generates the system events.

Interaction Diagrams

UML includes interaction diagram to show how two objects interact through Messages.

Two types of interaction diagram are

1. Sequence diagram: It is the important and commonly used diagram.

2. Communication interaction diagram

Sequence and communication interaction diagram express similar interaction. It provides a big
picture overview of how asset of interaction diagram are related in terms of logical flow and
process flow.

The most important diagram now is sequence diagram.

Sequence diagram:

It is in the fence format.

New objects are added in the right side.

Messages are passed in the time ordering.

Communication interaction diagram:

Messages are passed in number ordering.

Strength and weakness of sequence vs communication diagram:

TYPES STRENGTH WEAKNESS

• Clearly shows sequence or time • Forced to extend to the right when
ordering messages. adding new objects.
Sequence
• It has large set of detailed notations. • Consumes horizontal spaces.
Basic sequence diagram notations:

Lifeline boxes and lifeline:

The lifeline boxes including a vertical line extended below. These are the actual lifeline of the
objects.

The lifeline is indicated as dashed line, the lifeline boxes are used for indicating boxes and
objects.

Messages:

Each message between the objects is represented with a message expression on a filled arrowed
solid line between the vertical lifelines.

Diagram frames in UML sequence diagram:

Frames are also called as interaction frame or diagram frames. It is a region or fragmentation of
the diagram. Frame has label, operator and guard.

Types of frames:

Frame operator Meaning

It is alternative fragment for mutual exclusion

Alt
conditional logic expressed in guards.

Loop fragment while guard is true can also

Loop
write loop(n) to indicate looping n times

Opt Optional fragment that executes if guard is true.

Par Parallel fragment that executes if guard is true.

Critical region within which only one thread

Region
can run.

Basic communication diagram notations:

Link:

It is the path of communication between two objects.

It indicates the form of navigation and visibility between the object. It is an instance of an
association.
Messages:

Each message between object is represented with a message expression and a small arrow
indicating the direction of messages.

Messages to "self" or "this": A message can be send from an object to itself with messages
flowing along the link.

Domain model : identifying concepts, adding associations, adding attributes

A domain model is a visual representation of conceptual classes or real-world objects in a

domain of interest.They have also been called conceptual models , domain object models and
analysis object models.

The UP defines a Domain Model as one of the artifacts that may be created in the Business
Modeling workflow. Using UML notation, a domain model is illustrated with a set of class
diagrams in which no operations are defined. It may show:

• Domain objects or conceptual classes

• Associations between conceptual classes

• Attributes of conceptual classes

ARTIFACT

Its development entails identifying a rich set of conceptual classes, and is at the heart of object
oriented analysis. It is a visual representation of the decomposition of a domain into individual
conceptual classes or objects. It is a visual dictionary of noteworthy abstractions.
For example, Figure below shows a partial domain model. It illustrates that the conceptual class
of Payment and Sale are significant in this domain, that a Payment is related to a Sale in a way
that is meaningful to note, and that a Sale has a date and time.
This discipline in the software development life cycle is also termed as ―Domain Modeling‖,
which is the main artifact of the Elaboration phase of the Unified Process (UP). It represents the
real world conceptual classes - not the software classes. And, therefore, it is different from object
modeling that is more design and implementation oriented.

Apart from the visual representation of conceptual classes, in the domain modeling, two major
skills are required :

(1) Adding associations and

(2) Adding attributes.

Domain / Conceptual models

•The domain objects required for the modeling are obtained from decomposition of the domain
of interest (division by conceptual classes).

• It is a visual representation of real world objects in the domain, hence sometimes called domain
objects model.

• The UML notation illustrates a set of class diagrams without operations, but showing domain
objects, their associations and attributes.

• Key ideas of domain model are

o Domain model is a visual dictionary of abstractions.

o Domain models are not models of software components.

Conceptual classes

· They are either an idea, or thing or an object, identified as a result of different level of
abstraction of the domain.
They have three parts:

o Symbol: usually represented by a rectangle.

o Intension: The definition of the class.

o Extension: It is object instances of the classes. (generally absent)

Symbols and Intensions are the practical considerations when creating a domain model.

Conceptual class identification

A domain model is built incrementally over a number of iterations in the elaboration phase. In
each build, all possible conceptual classes and relationships of the current scenario are added to
the prior model. Therefore, the central task is to identify the domain objects related to scenario.

Guidelines for identifying conceptual classes: -

· Try to identify as much of the conceptual classes as possible.

· Do not worry about missing some of the conceptual classes, but make sure that they will be
incorporated later when they are identified in the process of identifying attributes and
associations among domain objects.

· Include in the model also those conceptual classes that are not indicated clearly by the
requirements.

· Classes not having attributes or having only behavioral role could also be taken as a conceptual
class.

Strategies to identify conceptual classes

1. Reuse or Modify existing models

2. Use a conceptual class category list.
3. Identify noun phrases

Use a conceptual class category list.

Conceptual Class Category Examples

Physical or tangible objects Register
Specifications, designs, or descriptions of
ProductSpecification
things
Places Store
Transactions Sale, Payment
Transaction line items SalesLineItem
Roles of people Cashier
Containers of other things Store, Bin
Things in a container Item
Other computer or electro-mechanical systems
CreditPaymentAuthorizationSystem
external to the system
Abstract noun concepts Hunger
Organizations SalesDepartment
Events Sale, Payment, Meeting
Processes(often Not represented as a concept,
SellingAProduct
but may be)
Rules and policies RefundPolicy
Catalogs ProductCatalog
Records of finance, work, contracts, legal
Receipt, Ledger, EmploymentContract
matters
Financial instruments and services LineOfCreditStock
Manuals, documents, reference papers, books DailyPriceChangeList

Domain modeling guidelines

Ways to make a domain model:

· Prepare the conceptual Class Category List

· Use noun phrase identification technique

· Draw these objects in a domain model

· Add necessary associations

· Add required attributes

The Mapmaker method

· Use the existing vocabulary in the domain

· Exclude the irrelevant noun phrases

· Do not add the classes not present in the domain

Domain model in UP

Inception

· Domain modeling is not recommended

Elaboration

· Primarily created in early iterations

· Incrementally grows the model

Adding Associations to Domain Model

An association is a semantic relationship between things, concepts or ideas. It represents

meaningful connection.

An association is represented as a line between classes with an association name. Associations

are inherently bidirectional. Optional reading direction arrow is only an aid to the reader of the
diagram.
Terminology in Association

· Role

· Association Name

· Multiplicity

Useful Associations

· Need-to-know associations: relationships that are to be preserved for later use.

· Associations derived from the Common Associations List.

The common categories that are worth considering are:

Implementation of Associations

· It is more important to identify conceptual classes that associations at the Elaboration phase.

· Some associations of domain model may not be required to be implemented.

· Some associations might be discovered at the time of implementation only and the domain
model should have to be changed to reflect these discoveries.

Adding Attributes to Domain Model

An attribute is a logical data value of an object that is stored persistently.

Guidelines in adding attributes:

1. Keep attributes simple

Make attributes of primitive data type as far as possible. Complex attributes can often be
identified as a new role (conceptual class) and hence are related with the original one with an
association.

2. Attributes should be data types

We decide a thing (noun phrase) whether it should be an association or an attribute according to

the ―Thumb Rule.‖ If it can be expressed in terms of data types (integer, text etc.), then we will
take it as an attributes. The primitive data types are the simpler ones but there might be complex
concepts that could be of non-primitive type.

3. Make model free from design decisions

Some of the associations between objects expressed in the domain model will be implemented as
attributes. The design decision will have to be deferred in the conceptual modeling. Design
solutions may be different depending upon the tools.

3.2 Introduction to GRASP design Patterns ,Design Model

General Responsibility Assignment Software Patterns(GRASP) :

GRASP consists of guidelines for assigning responsibility to objects and classes in object-
oriented design.

The different principles and patterns used in GRASP are: Information Expert, Controller,
Creator, Low Coupling, High Cohesion, Pure Fabrication, Polymorphism, Indirection and
Protected Variations.

All these patterns answer some software problems and in almost every case these problems are
common to almost every software development project.

And these techniques have not been invented to create new ways of working but to better the
document and standardize the old, and tested the programming principles in object oriented
design.

It has been said that "the critical design tool for software development is a bit, well educated in
design principles. It is not the UML or any other technology".

Thus, General Responsibility Assignment Software Patterns is really a mental tool set, a learning
aid to help in the design of object oriented software.

Design pattern is an instructive information that captures the essential structure and the insight of
a successful family of proven design solutions for the recursively occurring problem which arises
within a certain context.

Gang of four (GoF) [The gang includes Erich Gamma, Ralph Johnson, Richard Helm and John
Vlissides] introduced the design patterns concepts..

Characteristics of Design Patterns:

1. It solves the problem - Design patterns are not just abstract representations of the theoretical
research. It has to be accepted as a pattern and it should also have some proven practical
experiences.

2. It’s a proven concept that patterns have a successful history.

3. It describes a relationship - Patterns do not specify a single class, instead it specifies more than
one classes and their relationships.

4. It has a human component - Good patterns make the programmers job easy and time saving.

Contents of Design Pattern:

• Name of the pattern is used to identify the pattern as well as description of the problem solution
in general. Easy to remember and context related names makes remembering patterns easy.

• The Context of the pattern describes when and where the pattern is applicable. It also describes
the purpose of the pattern and also the place where it is not applicable due to some specific
conditions.

• Solution of the design pattern describes how to build the appropriate design.

• Consequences of design patterns describe the impact of choosing a particular design pattern in
a system.

The Singleton Design Pattern:

1. Pattern Name - Singleton.

2. Intent - To ensure, a class has only one instance for a global point of access to it.

3. Motivation - It is common in software development where some of the component developers

specify that more than one object of a class alive make systems ambiguous.

4. Applicability - Singleton can be used in design pattern where there must be exactly one object
and it must be accessible to multiple clients/objects.

5. Structure:
Singleton class definition

6. Participants - Singleton class defines a class function that can be accessed by the clients for
creating instance.

7.Collaborations - Clients access a singleton object solely through instance operation.

8. Consequences - Controlled access to the single instance, reduced name space can be sub
classed and more behaviors of it can be added, and can be modified for existence of more than
one objects(BASED ON THE DOMAIN).

Implementation:

class singleton

private:

static int numofobj;

static singleton * pointer_instance;

// other private data members and member functions

public:
static singleton * create_instance()

if (numofob==0)

pointer_instance=new singleton;

numofobj=1;

return pointer_instance;

}}

//function f() uses the following statement to create a new instance:

singleton s=singleton::create_instance();

Singleton

Static int count

*Other singleton data*

Static singleton *

create_Instance()

*Other singleton

behaviour*

Generative Patterns: Patterns that suggest the way of finding the solution.

Non Generative patterns: They do not suggest instead they give a passive solution. Non
Generative patterns cannot be used in all the situation.

Use case realizations with GRASP patterns

To quote, ―A use-case realization describes how a particular use case is realized within the
design model, in terms of collaborating objects‖ [RUP]. More precisely, a designer can describe
the design of one or more scenarios of a use case; each of these is called a use-case realization.
Use-case realization is a UP term or concept used to remind us of the connection between the
requirements expressed as use cases, and the object design that satisfies the requirements.

UML interaction diagrams are a common language to illustrate use-case realizations. And as was
explored in the prior chapter, there are principles and patterns of object design, such as
Information Expert and Low Coupling, that can be applied during this design work.

The use case suggests the system events that are explicitly shown in system sequence diagrams.

Details of the effect of the system events in terms of changes to domain objects may optionally
be described in system operation contracts.

The system events represent messages that initiate interaction diagrams, which illustrate how
objects interact to fulfill the required tasks and this is called as use case realization.

The interaction diagrams involves message interaction between the software objects whose
names are sometimes encouraged by the names of the conceptual classes in the Domain Model,
and other classes of objects.

Interaction Diagrams and Use-Case Realizations

In the current iteration we consider the various scenarios and system events like:

Process Sale: makeNewSale, enterItem, endSale, makePayment

If collaboration diagrams are used in illustrating the use-case realizations, a different

collaboration diagram would be needed to exhibit the handling of each system event message.
For eg:

Collaboration diagrams and system event message handling.

On the other hand, if sequence diagrams are used, it is possible to fit all the system event
messages on the same diagram, as shown in the below figure:
 One sequence diagram and system event message handling

But, it is often the case that the sequence diagram is then too complex or long. It is legal, that
with interaction diagrams, to use a sequence diagram for each system event message, as shown
in the below figure.

Multiple sequence diagrams and system event message handling.

Contracts and Use-Case Realizations

To reiterate, it is possible to design the use-case realizations directly from the use case text. In
addition, for some system operations, contracts may have been written that add greater detail .

For example:

Contract CO2:
Cross References: Use Cases: Process Sale

Operation: enterItem(itemID : ItemID, quantity : integer)

Preconditions: There is a sale underway.

Postconditions: – A SalesLineItem instance sli was created (instance creation).

In conjunction with contemplating the use case text, for each contract, we work through the
postcondition state changes and the design message interactions to satisfy the requirements. For
example, when this is the given partial enterItem system operation, a partial interaction diagram
is shown in figure below that satisfies the state change of SalesLineItem craetion of instance.

Partial interaction diagram

 Design Class diagrams in each MVC layer Mapping Design to Code, Design class
diagramsfor case study and skeleton code

One general approach for designing the web application by using the layered architecture which
is known as the Model View Controller (MVC).

Model is an application business layer that indicates the business entities like customers,
employee, products, sales ,etc

View is an application user interface. It is layout or the look and feel of the web application.

Controller is a user action that manages events which are processed in the application.
Practically, the controller chooses which method & view are to be used to build a page.

In simple term, MVC separates between the business layer and the user interface layer. Also with
this layered design, all the staff on team may work at the same time because they work
independently to others.

A lot of live example on the application layer around us. For example PayPal API payment
gateway. Paypal provides a way to make a payment button that can be pluged into member
website. Member just copy & paste the button tag based on product & price they specified into
their html page. If users visit their website and click Buy Now button, users will redirected to
paypal site and fill in credit card information. Finally a fund already appear on paypal member
page without knowing what happen or code that run behind payment process.

Here’s a simple example of model layer that contains business entity, products, model.php :

class model_product {

function construct() { }

function products() {

return array("Bike", "Car", "Accessories");

View Layer: It is the user interface design, off course this produces html tags. view.php :
class view_product {

function construct() {}

function view($product) {

echo "<table>"

foreach ($product as $pr) {

echo "<tr><td>".$pr."</td></tr>";

echo "</table>";

Controller: Like its name, it is to control (choose) which model and view layer class that suitable
to related application or page, controller.php:

include "model.php";

include "view.php";

class product_controller {

private $p;

function construct() {

$this->p = new model_product();

function load_product() {

$v = new view_product();

$v->view($this->p->products());

}
HTML Page:

<html>

<body>

<?php

include "controller.php";

$cp = new product_controller();

$cp->load_product();

?>

</body>

</html>

Lets try several scenario. First, easiest case, products need to be added. Only programmer that
work on model layer need to be informed. We can modify model_product class only. View &
constructor are not affected.

Second, view to represent product need to be modified. Change only on view_product class.
Model & controller are independent from view.

Third, maybe for some reason constructor need to change/add type of product. So, constructor
can choose another model_product class i.e modelproduct2 or other else. Model & view them
self remain the same. Of course, before constructor can choose model_product2, we already have
the class that requested from business requirement or class diagram.

Class diagram is important to ensure we can write MVC layers together in the same time not
waiting others finishing their tasks. Class diagram is tool to coordinate between programmers in
team. Beside that, some meetings and planning might be needed.

Case Study : Point-of-Sale System

We use Point-of-Sale (POS) System case study. POS is a sale system which is used at checkout
counters in a super store where the customers come up with different items to purchase. There
are two reasons for selecting POS as a case study: firstly, it is a well-known case study;
secondly, it requires all the aspects focused in our code generation technique such as user
interactions, object manipulations, etc. The designed Process Sale use-case from a POS system
but changed according to our requirements.
The set of UML diagrams consists of one UML class diagram, thirtyseven UML sequence
diagrams, and sixty UML activity diagrams. The Process Sale use-case is specified as customer
comes to a shop counter with some selected items from a shop. The cashier initiates a new sale.
The cashier checks whether the customer is new or already existing. In the case of an existing
customer, the customer record is retrieved from the system. A list of items is included in a new
sale against a specific customer. Finally, a receipt is generated and the sale is saved in the
database.

Figure below shows POS UML class diagram which consists of PointOfSale base package
containing Person, Item, Sale, and clsDB classes with Persist interface. Person and Item classes
implement Persist interface. Person and Item classes are also composed in Sale class. clsDB class
is used to store the records in database.

Generated Code Demonstration:

Figure below shows the partial Java code generated for POS case study.
The tool also provides the facility to compile and execute the generated code shown. Figure
below presents the demonstration of the POS case study generated code. Although it generates
complete implementation of all the classes including their methods, but the main method have to
be implemented to run the generated code. In future, we will look into the generation of main
method to provide system level flow of control for the generated code.