RT41052 UML & DESIGN PATTERNS

Course Objectives:

The focus of this course is on design rather than implementation.

1. Introducing the Unified Process and showing how UML can be used within the process.

2. Presenting a comparison of the major UML tools for industrial-strength development.

3. introduction to design patterns, practical experience with a selection of central patterns.

Unit I

Introduction

Introduction to OOAD; typical activities / workflows / disciplines in OOAD, Introduction to

iterative development and the Unified Process, Introduction to UML; mapping disciplines to
UML artifacts,Introduction to Design Patterns - goals of a good design, Introducing a case study
& MVC architecture

1.1 Introduction to OOAD

Object-Oriented Analysis and Design:

In object-oriented analysis, there is an emphasis on finding and describing the objects or its
concepts in the problem domain.

For example, in the case of the flight information system, some of the concepts includes Plane,
Flight, and Pilot.

In object-oriented design, there is an emphasis on defining software objects and how they
collaborate with each other to fulfill the requirements.

The combination of these two concepts shortly known as object oriented analysis and design.

1.1.1 Typical activities / workflows / disciplines in OOAD

1
Activity

Roles have activities that define the work they perform. An activity is something that a role does
that provides a meaningful result in the context of the project.

An activity is a unit of work that an individual playing the described role might be asked to
perform.

The activity has a very clear purpose, normally expressed in terms of creating or updating some
artifacts,like a model, a class, a plan. Each and every activity is assigned for a specific role. The
granularity of an activity is basically a few hours to a few days, it generally involves one role,
and affects one or only a small number of the artifacts. An activity must be used as an element of
planning and progress.If it is too small, then it will be neglected, and if it is too large, then the
progress would have to be expressed in terms of an activity’s parts.

Activities should be repeated number of times on same artifact, especially when going from one
of the iteration to another, refining and expanding the system, by means of the same role, but not
necessarily of the same individual.

Steps

Activities are broken down into several steps. Steps fall into the three main categories:

2
• Thinking steps: is a step where the individual performing the role understands the nature of
task,gathers and then examines the input artifacts, and formulates the outcome.

• Performing steps: is a step where the individual performing the role creates or updates certain
artifacts.

• Reviewing steps: is a step where the individual performing the role inspects the results against
some criteria.

It is not necessary to perform these steps each time an activity is invoked, and so they can even
be expressed in the form of alternate flows.

Example of steps:

The Activity: Find use cases and actors decomposes into the following steps:

Step1. Find actors

Step2. Find use cases

Step3. Describe how actors and use cases interact

Step4. Package use-cases and actors

Step5. Present the use-case model in use-case diagrams

Step6. Develop a survey of the use-case model

Step7. Evaluate your results.

The finding part [steps 1 to 3] needs some thinking.The performing part [steps 4 to 6] involves
capturing the result in use-case model; the reviewing part [step 7] is the one where the individual
performing the role evaluates the result to assess the completeness, robustness, intelligibility, or
other qualities.

Work Guideline

Activities can have associated Work Guidelines, that present techniques and practical advice
which is useful to the role performing the activity.

3
Workflow

A mere enumeration of all the roles, activities and artifacts do not constitute a process.we require
a way to describe meaningful sequences of activities which produce some valuable result, and
also to show interactions between the roles. A workflow is a sequence of activities that produces
a result of observable value.

In UML terms, a workflow may be expressed as a sequence diagram, a collaboration diagram, or

even as an activity diagram. We use a form of activity diagrams in the RUP. For each and every
discipline, an activity diagram is presented. This diagram shows the workflow, that is expressed
in terms of the workflow details.The great difficulties of describing the process is that there are
number of ways in order to organize the set of activities into the workflows. RUP is organized
using the following:

• Disciplines

• Workflow details

Workflow Detail

For most of the disciplines, you may also find the workflow detail diagrams,that shows the group
of activities which are often performed "together".

4
These diagrams show the roles involved, input and output artifacts and also the activities
performed. The workflow detail diagrams are there for the following reasons:

The activities of a workflow are neither done all at once, nor performed in sequence. The
workflow detail diagram says how often it works in workshops or in team meetings when
performing a workflow. Typically we work in parallel on more than one activity and look at more
than one artifact while doing that. There are various workflow detail diagrams for a particular
discipline.

It becomes too complex in order to show the input and the output artifacts for all the activities of
a discipline in one diagram. The workflow detail diagram allows you to show the activities and
artifacts together, for one part of a workflow at a time.

The disciplines are not completely independent of one another. For example, integration occurs
in both implementation and also in test disciplines, and in reality you never really do one without
other. The workflow detail diagram may show a group of activities and artifacts in the discipline,
together along with closely related activities in another discipline.

5
Sample activity diagram, from requirements discipline, showing workflow details and transitions

Discipline

A discipline is a collection of related activities which are related to a major “area of concern”
within overall project. The grouping activities into disciplines is mainly an aid in understanding
the project from a “traditional” waterfall perspective - For example, it is more common to
perform certain requirements activities in close coordination with the analysis and design
activities. Separating these activities into separate disciplines helps in making the activities easier
to comprehend but more difficult to schedule.

Just Like workflows,workflow of a discipline is a semi ordered sequence of activities that are
performed to achieve a particular result. The "semi ordered" nature of the discipline workflows
emphasizes that,discipline workflows could not present the actual nuances of scheduling "real
work", which they may not depict the optionality of activities or iterative nature of the real
projects. Yet they still have value as a way for us to understand the process by breaking it into

6
much smaller 'areas of concern'.Each 'area of concern' or discipline has associated with it one or
more 'models', which are in turn composed of associated artifacts.

Each discipline is associated with a particular set of models.

The most important artifacts are the models which each discipline yields: use-case model, design
model, implementation model and the test suite.

An activity overview is presented for each discipline. The activity overview shows all the
activities in the discipline along with the role that performs the activity. An artifact overview
diagram is also been presented. This diagrams shows all the artifacts and the roles that are
involved in the discipline.It is important to note that the “discipline-centric” organization of
artifacts sometimes slightly differs from the artifact set organization of the artifacts.The reason
for this is simple: some artifacts are used across number of disciplines; a strict discipline-centric
grouping makes this more difficult to present an integrated process. If only a part of the process
is being used, then the discipline-centric artifact overviews will prove it to be more useful.

1.2 Unified Process

The Unified Process has emerged as a popular iterative software development process for
building the object oriented systems.

Unified process is an iterative, risk driven process and architecture centric approach for software
development. It comes under software development process.

The Unified Software Development Process is a popular iterative and incremental software
development process framework.

The best known and extensively documented refinement of the Unified Process is the Rational
Unified Process (RUP).

7
UP Phases:

(i) Inception:

Inception is the initial stage of project. It deals with approximate vision, business case, scope of
project and vague estimation.

Inception is the smallest phase in the project and ideally it should be quite short.

If this phase is long, then it may be an indication of excessive up -front specification which is
contrary to the spirit of the Unified Process.

The below are the typical goals for the inception phase:

• Establish a justification or the business case for the project.

• Establish the project scope and boundary conditions.

• Outline the use cases and key requirements that will drive the design tradeoffs.

• Outline one or more candidate architectures.

• Identify risks in the project.

• Prepare a preliminary project schedule and cost estimate.

• The life cycle objective milestone marks the end of this inception phase.

Advantages of inception:

• Estimation of plans are expected to be reliable.

• After inception, design architecture can be made easy because all the use cases are written in
detail.

(ii) Elaboration:

During this phase, the project team is expected to capture majority of the system requirements.

However, the primary goals of elaboration is to address known risk factors and to establish and
validate the system architecture.

The common processes undertaken in this phase include the creation of use case diagrams,
conceptual diagrams and package diagrams (architectural diagrams). The following are typical
goals for the Elaboration phase:

8
• Refined vision

• Core architecture

• Resolution of high risk

• Identification of requirements and scope

• Realistic estimate.

(iii) Construction:

It is the largest phase in the project development. In the construction phase, the remainder of the
system is built on the foundation laid in the Elaboration.

The system features are implemented in a series of short, time boxed iterations. Each and every
iteration results in an executable release of the software. It is customary to write the full text use
cases during the construction phase after which each one becomes the start of a new iteration.

The Common Unified Modeling Language diagrams that is used during this phase includes the
Sequence, Activity,State Transition, Collaboration and Interaction overview diagram.

The initial operational capability milestone marks the end of the construction phase.

(iv) Transition:

The Transition is the final project phase. In this phase, the system is deployed to the target users.

The feedback received from an initial release may result in the further refinements that is to be
incorporated over the course of several transition phase iterations.

This transition phase includes user training and the system conversions. The product release
milestone is used to mark the end of transition phase.

9
1.2.1 Introduction to iterative development

Iterations

Iterative development is the key characteristic of a successful software development projects.

Within an iterative software development life cycle, various passes are made through each of the
disciplines. Each pass is known as an iteration. An iteration is a distinct, time-boxed sequence of
number of activities that results in a release of an executable product. As the project progresses,
releases evolve from subset of the final product even to the final system. An iterative
development process is similar to that of a "growing" software, where the end product matures
over time. Each iteration results in a better understanding of the requirements, a more robust
architecture, a more experienced development organization, and a more complete
implementation.

The below figure illustrates how the focus of a project shifts across the successive iterations. The
size of the boxes in each of the disciplines illustrates the relative time spent for performing the
activities within that discipline. Each discipline is addressed during every iteration, but relative
emphasis shifts as the project progresses from Requirements to Analysis and Design to
Implementation to Test, and at last to Deployment.

10
The following list provides some important characteristics of a successful iteration.

• The iteration has a planned capability that is demonstrable.

• The iteration has clear evaluation criteria.

• During the iteration, the system is integrated and tested.

• The iteration is concluded by a minor milestone, where the result of the iteration is assessed
relative to the objective success criteria of that particular iteration.

• During the iteration, artifacts are updated .

Benefits of iterative development include:

• early feedback, user engagement, and adaptation, leading to a refined system that more closely
meets the real needs of the stakeholders.

• early visible progress.

• early rather than late mitigation of high risks (technical, requirements, objectives, usability, and
so forth).

• the learning within an iteration can be methodically used to improve the development process
itself, iteration by iteration.

11
• managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and
complex steps .

Iterative and incremental development

1.3 Introduction to UML

The Unified Modeling Language(UML) is a visual language for constructing, specifying and
documenting the artifacts of systems.

Unified Modeling Language is a standardized general-purpose modeling language in the

software engineering field.

The standard is managed and created by the Object Management Group. Here UML includes the
set of graphic notation techniques in order to create the visual models of the software-intensive
systems.

The Unified Modeling Language is generally used to visualize and construct systems which are
software intensive.

Software has become much more complex in recent times, developers find it more challenging to
build complex applications within short time periods.

When they do so, these software applications are often filled with bugs, and it can take
programmers a weeks to find and fix them.

12
Thus, the time has been wasted, since an approach which would have reduced the number of
bugs before the application process starts could have been used .

Three methods to apply UML:

1. UML as programming language:

Complete executable specification of software system in an UML.

2. UML as sketch:

Informal and incomplete diagrams created to explore difficult parts of the problem.

3. UML as blueprint:

Detailed design diagram used for better understanding of code.

Three perspectives to apply UML:

1. Conceptual perspective:

In conceptual perspective, diagrams describe the things in situation to real world. Raw UML
object diagram notation is used to visualize.

2. Specification perspective:

In specification perspective, diagrams describe software abstractions or its components with

specifications and interfaces, but no commitment to a particular implementation

3. Implementation perspective:

The diagrams describes the software implementation in a typical technology. UML language is
being used for the purpose of visualizing, specifying, constructing and then documenting the
software systems throughout the stages of development . Unified Modeling Language is used to
model systems that is build through the Unified Approach.

Models may be represented at different levels based on abstraction and refinement. A complete
model can be obtained only after the continuous refinement of the UML diagrams.

UML is composed of 9 graphical diagrams.They are as follows,

1) Use Case Diagram

2) Class Diagram

3) Behavior Diagram

13
a. Interaction Diagram

i.. Collaboration Diagram

ii. Sequence Diagram

b. Activity Diagram

c. State Chart Diagram

4) Implementation Diagram

a. Deployment Diagram

b. Component Diagram

1.3.1 Mapping disciplines to UML artifacts, Introduction to Design Patterns - goals of a good
design

The UP describes work activities, such as writing a use case, within disciplines (originally
known as the workflows).

Informally, a discipline is a set of activities in one subject area, like the activities with in the
requirements analysis. In the Unified Process, an artifact is the general term for a work product:
Web graphics,code,text documents,database schema, diagrams, models, and many more.

There are various disciplines in the UP.They are,

• Requirements—Requirements analysis for an application, such as writing use

• Design—All aspects of design, including the overall architecture, objects, databases,

networking, and the like.cases and identifying non-functional requirements.

• Business Modeling—When developing a single application, this includes domain object

modeling. When engaged in large-scale business analysis or business process reengineering, this
includes dynamic modeling of the business processes across the entire enterprise.

14
In the UP, Implementation means programming and building the system, not deployment. The
Environment discipline is one establishes the tools and customizes the process for the project
which means, setting up the tool and process environment.

Design Pattern

They are the class combinations and accompanying algorithms which fulfill common design
purposes. Design patterns are the descriptions of communicating objects and the classes which
are customized to solve a basic design problem in a particular context.

"Each pattern describes a problem that occurs over and over again in our environment, and then
describes the core of the solution to that particular problem, in a way that you may use this
solution even for a million times over, without doing it the same way twice".

The Need for design pattern

The DP satisfy this need for good ,simple and reusable solutions. DP catalogs the common
interactions between objects that programmers have often found useful.

It is an abstracts a recurring design structure. This comprises class and/or object that are
dependencies.

• Conventions

15
• Interactions

• Structures

It is used in the names & species the design structure explicitly distills the design experience.

In software engineering, a design pattern is a basic reusable solution to commonly occurring

problem in software design . A design pattern is not a finished design that may be transformed
directly into the code. It is a description or template for how to solve a problem that may be used
in many varying situations. Object-oriented design patterns shows the relationships and
interactions between the classes or objects, without specifying the final application classes or
objects which are involved.

Pattern elements

1.Name -A meaningful pattern identifier.

2. Problem description -When to apply the pattern.

3.Solution description -Elements that make up the pattern, their relationships, responsibilities,
and collaborations.

4. Consequences -The results and trade-offs of applying the pattern.

Types of Design Patterns

• Structural patterns

Representing a collection of related objects.

• Behavioral patterns

Capturing behavior among a collection of objects.

• Creational patterns

Creating a collection of objects in flexible ways.

Describing Design Patterns

• Also Known As

Any aliases this pattern is known by

• Intent

16
Short description of the pattern & its purpose

• Applicability

Circumstances in which pattern applies

• Motivation

Motivating scenario demonstrating pattern’s use

• Structure

Graphical representation of the pattern using modified UML notation

• Collaborations

How participants cooperate to carry out their responsibilities

• Participants

Participating classes and/or objects & their responsibilities

• Consequences

The results of application, benefits, liabilities Implementation pitfalls, hints, techniques, plus
language-dependent issues

• Known Uses

Examples drawn from existing systems

• Sample Code

Sample implementations in C++, Java, C#, Smalltalk, C, etc.

• Related Patterns

Discussion of other patterns that relate to this one.

Catalog of design patterns:

There are two criteria.They are,

Purpose:

Creational: concern the process of object creation.

17
Structural: the composition of classes or objects.

Behavioral: characterize the ways in which classes or objects interact and distribute
responsibility.

Scope: whether the pattern applies primarily to classes or to objects.

Goals

1.Facilitate restructuring/refactoring

• Additional flexibility.

• Patterns are interrelated.

2. Give design structures explicit names

• Greater expressiveness.

• Common vocabulary.

• Reduced complexity.

3.Codify good design

• Abstract how to think about design.

• Distill and disseminate experience.

• Aid to novices and experts alike.

4.Capture and preserve design information

• Improve documentation.

• Articulate design decisions succinctly.

1.4 Introducing a case study & MVC architecture

Case stuty: The NextGen POS System

The case study is the NextGen point-of-sale (POS) system. In this type of apparently
straightforward problem domain, we can see that interesting requirement and design problems

18
are there to solve. Additionally, it is a realistic problem;organizations really do write POS
systems using the object technologies.

POS system is one which is a computerized application that is used to record sales and handle
the payments; it is particularly used in retail stores. This includes hardware components like a
computer and bar code scanner,and a software that is to run the system. It interfaces to several
service applications, like a third-party tax calculator and an inventory control. These systems
should be relatively fault-tolerant; This means that ,even if remote services are temporarily
unavailable , they should still be capable of capturing the sales and be capable of handling at
least cash payments .

A POS system should increasingly support the multiple and varied client-side terminals and
interfaces. These include a thin-client Web browser terminal, touch screen input, a regular
personal computer with something like a Java Swing graphical user interface,wireless PDAs, and
so on. Moreover, we are creating a commercial POS system that we may sell to different clients
with desparate needs in terms of business rule processing. Each client will required or desire a
unique set of logic in order to execute at certain predictable points in scenarios of using the
system, such as when a new sale is initiated or when a new line item is added. Therefore, we will
need a mechanism in order to provide this flexibility and customization.

By using an iterative development strategy, we are now proceeding through requirements, object-
oriented analysis, design, and finally implementation.

Architectural Layers and Case Study Emphasis

Sample layers and objects in an object-oriented system, and case study focus

19
A typical object-oriented information system is designed in terms of different architectural layers
or as shown in the above shown figure. The following is not a complete list, yet it shows an
example:

• User Interface—graphical interface; windows.

• Technical Services—It is a general purpose objects and subsystems which the provide
supporting technical services, like interfacing with database or an error logging. These services
are genarally application-independent and can be reused across several systems.

• Application Logic and Domain Objects—The software objects that represents the domain
concepts

OOAD is most relevant for modeling application logic and technical service layers.

NextGen case study primarily highlights the problem of domain objects, and also in allocating
responsibilities to them to fulfill the requirements of application. Object-oriented design is
applied in order to create a technical service subsystem for interfacing this with a database.

In this design approach, the User Interface layer has very little responsibility i.e. it is considered
to be thin. Windows do not contain code which performs the application logic or processing.
Rather, task requests are forwarded on to some other layers.

MVC architecture

MVC or Model View Controller as it is popularly known, is a software design pattern for web
applications development . A Model View Controller pattern is made up of the following three
parts.They are,

Model - The lowest level of the pattern which is responsible for maintaining the data.

View - This level is responsible for displaying all or a portion of the data to the user.

Controller - Software Code which controls the interactions between the Model and the View.

MVC is popular as it isolates the application logic from the user interface layer and then supports
the separation of concerns. The Controller receives all the requests for the application and then
works with the Model in order to prepare any data that is needed by View. The View then uses
this data which is prepared by the Controller in order to generate a final presentable response.
The MVC abstraction is graphically represented as follows.

20
The model

The model in the MVC layer is responsible for managing data of the application. It responds to
the request from view and it also responds to instructions from controller to update itself.

The view

A presentation of data in a particular format, triggered by decision of the controller to present the
data. They are the script based templating systems such as JSP, ASP, PHP and very easy to
integrate with AJAX technology.

The controller

The controller is responsible for responding to the user input and perform interactions on the data
model objects. The controller receives the input, and it validates the input and then performs the
business operation that modifies the state of the data model.

21