Object Modelling Technique (OMT)

In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.

The three analysis techniques that are used in conjunction with each other for object-oriented
analysis are object modelling, dynamic modelling, and functional modelling.

Object Modelling
Object modelling develops the static structure of the software system in terms of objects. It
identifies the objects, the classes into which the objects can be grouped into and the
relationships between the objects. It also identifies the main attributes and operations that
characterize each class.

The process of object modelling can be visualized in the following steps −

 Identify objects and group into classes

 Identify the relationships among classes

 Create user object model diagram

 Define user object attributes

 Define the operations that should be performed on the classes

 Review glossary

Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to time and external
changes needs to be examined. This is the purpose of dynamic modelling.

Dynamic Modelling can be defined as “a way of describing how an individual object responds
to events, either internal events triggered by other objects, or external events triggered by the
outside world”.

The process of dynamic modelling can be visualized in the following steps −

 Identify states of each object

 Identify events and analyze the applicability of actions

 Construct dynamic model diagram, comprising of state transition diagrams

 Express each state in terms of object attributes

  Validate the state–transition diagrams drawn

Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The functional model
shows the processes that are performed within an object and how the data changes as it moves
between methods. It specifies the meaning of the operations of object modelling and the actions
of dynamic modelling. The functional model corresponds to the data flow diagram of traditional
structured analysis.

The process of functional modelling can be visualized in the following steps −

 Identify all the inputs and outputs

 Construct data flow diagrams showing functional dependencies

 State the purpose of each function

 Identify constraints

 Specify optimization criteria

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of
software development based upon the waterfall model. The phases of development of a system
using SASD are −

 Feasibility Study

 Requirement Analysis and Specification

 System Design

 Implementation

 Post-implementation Review

Now, we will look at the relative advantages and disadvantages of structured analysis approach
and object-oriented analysis approach.

Advantages/Disadvantages of Object Oriented Analysis

Advantages Disadvantages
Focuses on data rather than the procedures as in Functionality is restricted within objects. This may
Structured Analysis. pose a problem for systems which are intrinsically
procedural or computational in nature.

The principles of encapsulation and data hiding It cannot identify which objects would generate an
help the developer to develop systems that cannot optimal system design.
be tampered by other parts of the system.

The principles of encapsulation and data hiding The object-oriented models do not easily show the
help the developer to develop systems that cannot communications between the objects in the system.
be tampered by other parts of the system.

It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.

It can be upgraded from small to large systems at

a greater ease than in systems following
structured analysis.

Advantages/Disadvantages of Structured Analysis

Advantages Disadvantages

As it follows a top-down approach in contrast to In traditional structured analysis models, one

bottom-up approach of object-oriented analysis, it can phase should be completed before the next
be more easily comprehended than OOA. phase. This poses a problem in design,
particularly if errors crop up or requirements
change.

It is based upon functionality. The overall purpose is The initial cost of constructing the system is
identified and then functional decomposition is done for high, since the whole system needs to be
developing the software. The emphasis not only gives a designed at once leaving very little option to
better understanding of the system but also generates add functionality later.
more complete systems.
The specifications in it are written in simple English It does not support reusability of code. So,
language, and hence can be more easily analyzed by the time and cost of development is
non-technical personnel. inherently high.
 Structured Analysis
Analysts use various tools to understand and describe the information system. One of the ways
is using structured analysis.

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.

It has following attributes −

 It is graphic which specifies the presentation of application.

 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development.
They are −

 Data Flow Diagrams

 Data Dictionary

 Decision Trees

 Decision Tables

 Structured English

 Pseudocode

Structured Approach Vs. Object-Oriented Approach

The following table explains how the object-oriented approach differs from the traditional
structured approach −

Structured Approach Object Oriented Approach

It works with Top-down approach. It works with Bottom-up approach.

Program is divided into number of submodules or Program is organized by having number of

functions. classes and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

Structured design programming usually left until Object oriented design programming done
end phases. concurrently with other phases.

Structured Design is more suitable for offshoring. It is suitable for in-house development.

It shows clear transition from design to Not so clear transition from design to
implementation. implementation.

It is suitable for real time system, embedded It is suitable for most business applications, game
system and projects where objects are not the most development projects, which are expected to
useful level of abstraction. customize or extended.

DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart
diagram, and use cases all contribute.

In this, projects can be managed easily due to In this approach, projects can be difficult to
clearly identifiable phases. manage due to uncertain transitions between
phase.

UML Diagrams
The below picture contains the information about UML diagrams related to structural and
behavioral modeling respectively. In addition it also provide the information about which
diagram is most relevant during which phase of software development life-cycle.

There are two broad categories of diagrams and they are again divided into subcategories −

 Structural Diagrams
 Behavioral Diagrams

Structural Diagrams
The structural diagrams represent the static aspect of the system. These static aspects represent
those parts of a diagram, which forms the main structure and are therefore stable.

These static parts are represented by classes, interfaces, objects, components, and nodes. The
four structural diagrams are −

 Class diagram

 Object diagram

 Component diagram

 Deployment diagram
Behavioral Diagrams
Any system can have two aspects, static and dynamic. So, a model is considered as complete
when both the aspects are fully covered.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be
further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams −

 Use case diagram

 Sequence diagram

 Collaboration diagram

 Statechart diagram

 Activity diagram
MODULE 3

Design Issues

 The design process should not suffer from "tunnel vision." A good designer should
consider alternative approaches, judging each based on the requirements of the problem, the
resources available to do the job.
 The design should be traceable to the analysis model. Because a single element of the
design model often traces to multiple requirements, it is necessary to have a means for
tracking how requirements have been satisfied by the design model.
 The design should not reinvent the wheel. Systems are constructed using a set of design
patterns, many of which have likely been encountered before. These patterns should always
be chosen as an alternative to reinvention. Time is short and resources are limited! Design
time should be invested in representing truly new ideas and integrating those patterns that
already exist.
 The design should "minimize the intellectual distance" between the software and the
problem as it exists in the real world. That is, the structure of the software design should
(whenever possible) mimic the structure of the problem domain.
 The design should exhibit uniformity and integration. A design is uniform if it appears
that one person developed the entire thing. Rules of style and format should be defined for a
design team before design work begins. A design is integrated if care is taken in defining
interfaces between design components.
 The design should be structured to accommodate change. The design concepts discussed
in the next section enable a design to achieve this principle.
 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. Well- designed software should never "bomb": it
should be designed to accommodate unusual circumstances, and if it must terminate
processing, do so in a graceful manner.
 Design is not coding, coding is not design. Even when detailed procedural designs are
created for program components, the level of abstraction of the design model is higher than
source code. The only design decisions made at the coding level address the small
implementation details that enable the procedural design to be coded.
 The design should be assessed for quality as it is being created, not after the fact. A
variety of design concepts and design measures are available to assist the designer in
assessing quality.
 The design should be reviewed to minimize conceptual (semantic) errors. There is
sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest
for the trees. A design team should ensure that major conceptual elements of the design
(omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax
of the design model.

GRASP: Designing objects with responsibilities – Creator – Information

expert – Low Coupling –Controller – High Cohesion

General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP,

consist of guidelines for assigning responsibility to classes and objects in object-oriented design.
The different patterns and principles used in GRASP are: Controller, Creator, Indirection,
Information Expert, High Cohesion, Low Coupling, Polymorphism, Protected Variations, and
Pure Fabrication. All these patterns answer some software problem, and in almost every case
these problems are common to almost every software development project. These techniques
have not been invented to create new ways of working, but to better document and standardize
old, tried-and-tested programming principles in object-oriented design.
Creator
Creation of objects is one of the most common activities in an object-oriented system. Which
class is responsible for creating objects is a fundamental property of the relationship between
objects of particular classes.
In general, a class B should be responsible for creating instances of class A if one, or preferably
more, of the following apply:

 Instances of B contain or compositely aggregate instances of A

 Instances of B record instances of A
 Instances of B closely use instances of A
 Instances of B have the initializing information for instances of A and pass it on creation.

Information Expert (also Expert or the Expert Principle) is a principle used to determine
where to delegate responsibilities. These responsibilities include methods, computed fields, and
so on.
Using the principle of Information Expert, a general approach to assigning responsibilities is to
look at a given responsibility, determine the information needed to fulfill it, and then determine
where that information is stored.
Information Expert will lead to placing the responsibility on the class with the most information
required to fulfill it.
Low Coupling
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies
on other elements. Low Coupling is an evaluative pattern, which dictates how to assign
responsibilities to support:

 lower dependency between the classes,

 change in one class having lower impact on other classes,
 higher reuse potential.
High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused,
manageable and understandable. High cohesion is generally used in support of Low Coupling.
High cohesion means that the responsibilities of a given element are strongly related and highly
focused. Breaking programs into classes and subsystems is an example of activities that increase
the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given
element has too many unrelated responsibilities. Elements with low cohesion often suffer from
being hard to comprehend, hard to reuse, hard to maintain and averse to change.

Applying GoF design patterns – adapter, singleton, factory and observer

patterns.
Design patterns represent the best practices used by experienced object-oriented software
developers. Design patterns are solutions to general problems that software developers faced
during software development. These solutions were obtained by trial and error by numerous
software developers over quite a substantial period of time.
Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic, rather than
instantiating objects directly using new opreator. This gives program more flexibility in deciding
which objects need to be created for a given use case.

Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is used to
compose interfaces and define ways to compose objects to obtain new functionalities.

Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

1. Factory Pattern
Factory pattern is one of most used design pattern in Java. This type of design pattern comes
under creational pattern as this pattern provides one of the best ways to create an object.
In Factory pattern, we create object without exposing the creation logic to the client and refer to
newly created object using a common interface.

Implementation
We're going to create a Shape interface and concrete classes implementing theShape interface.
A factory class ShapeFactory is defined as a next step.

FactoryPatternDemo, our demo class will use ShapeFactory to get a Shapeobject. It will pass
information (CIRCLE / RECTANGLE / SQUARE) toShapeFactory to get the type of object it
needs.

2. Singleton Pattern
Singleton pattern is one of the simplest design patterns in Java. This type of design pattern
comes under creational pattern as this pattern provides one of the best way to create an object.

This pattern involves a single class which is responsible to creates own object while making
sure that only single object get created. This class provides a way to access its only object which
can be accessed directly without need to instantiate the object of the class.

Implementation
We're going to create a SingleObject class. SingleObject class have its constructor as private and
have a static instance of itself.
SingleObject class provides a static method to get its static instance to outside
world. SingletonPatternDemo, our demo class will use SingleObject class to get
a SingleObject object.

3. Adapter Pattern
Adapter pattern works as a bridge between two incompatible interfaces. This type of design
pattern comes under structural pattern as this pattern combines the capability of two
independent interfaces.

This pattern involves a single class which is responsible to join functionalities of independent or
incompatible interfaces. A real life example could be a case of card reader which acts as an
adapter between memory card and a laptop. You plugin the memory card into card reader and
card reader into the laptop so that memory card can be read via laptop.

We are demonstrating use of Adapter pattern via following example in which an audio player
device can play mp3 files only and wants to use an advanced audio player capable of playing
vlc and mp4 files.
Implementation
We have a MediaPlayer interface and a concrete class AudioPlayerimplementing
the MediaPlayer interface. AudioPlayer can play mp3 format audio files by default.

We are having another interface AdvancedMediaPlayer and concrete classes implementing

the AdvancedMediaPlayer interface. These classes can play vlc and mp4 format files.

We want to make AudioPlayer to play other formats as well. To attain this, we have created an
adapter class MediaAdapter which implements the MediaPlayerinterface and uses
AdvancedMediaPlayer objects to play the required format.

AudioPlayer uses the adapter class MediaAdapter passing it the desired audio type without
knowing the actual class which can play the desired format.AdapterPatternDemo, our demo
class will use AudioPlayer class to play various formats.

4. Observer Pattern
Observer pattern is used when there is one-to-many relationship between objects such as if one
object is modified, its depenedent objects are to be notified automatically. Observer pattern falls
under behavioral pattern category.
Implementation
Observer pattern uses three actor classes. Subject, Observer and Client. Subject is an object
having methods to attach and detach observers to a client object. We have created an abstract
class Observer and a concrete classSubject that is extending class Observer.

ObserverPatternDemo, our demo class, will use Subject and concrete class object to show
observer pattern in action.

Designing of Visibility
Visibility is the ability of one object to “see” or have reference to another. To send a message
from one object to another, the receiver object must be “visible” to the sender, via a reference
OO programming languages may provide four levels of scope for names:
 Attribute visibility
 Parameter visibility
 Local visibility
 Global visibility

Component Diagram
  A component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces.
 Graphically, a component is rendered as a rectangle with tabs, usually including only its
name.
 An interface is the definition of a collection of one or more methods, and zero or more
attributes, ideally one that defines a cohesive set of behaviors.
 The interface symbols with a complete circle at their end represent an interface that the
component provides -- this lollipop" symbol is shorthand for a realization relationship of
an interface classifier.
 Interface symbols with only a half circle at their end (a.k.a. sockets) represent an
interface that the component requires (in both cases, the interface's name is placed near
the interface symbol itself).

Deployment Diagram
A deployment diagram in the Unified Modeling Language models the physical deployment
of artifacts on nodes.[1] To describe a web site, for example, a deployment diagram would show
what hardware components ("nodes") exist (e.g., a web server, an application server, and a
database server), what software components ("artifacts") run on each node (e.g., web application,
database), and how the different pieces are connected (e.g. JDBC, REST, RMI).
The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within
the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in a
deployment diagram may conceptually represent multiple physical nodes, such as a cluster of
database servers.
There are two types of Nodes:

1. Device Node
2. Execution Environment Node
Device nodes are physical computing resources with processing memory and services to execute
software, such as typical computers or mobile phones. An execution environment node (EEN) is
a software computing resource that runs within an outer node and which itself provides a service
to host and execute other executable software elements.