UNIT 3 (Not complete)
1 Object Oriented Analysis (OOA)
Object Oriented Analysis (OOA) is the first technical activity performed as part of object oriented
software engineering. OOA introduces new concepts to investigate a problem. It is based in a set of
basic principles, which are as follows-
The information domain is modeled.
Behavior is represented.
Function is described.
Data, functional, and behavioral models are divided to uncover greater detail.
Early models represent the essence of the problem, while later ones provide implementation
details.
2 Object oriented design
After the analysis phase, the conceptual model is developed further into an object-oriented model
using object-oriented design (OOD). In OOD, the technology-independent concepts in the analysis
model are mapped onto implementing classes, constraints are identified, and interfaces are designed,
resulting in a model for the solution domain. In a nutshell, a detailed description is constructed
specifying how the system is to be built on concrete technologies
The stages for object–oriented design can be identified as −
Definition of the context of the system
Designing system architecture
Identification of the objects in the system
Construction of design models
Specification of object interfaces
2.1 System Design
Object-oriented system design involves defining the context of a system followed by designing the
architecture of the system.
Context − The context of a system has a static and a dynamic part. The static context of the
system is designed using a simple block diagram of the whole system which is expanded into
a hierarchy of subsystems. The subsystem model is represented by UML packages. The
dynamic context describes how the system interacts with its environment. It is modelled
using use case diagrams.
System Architecture − The system architecture is designed on the basis of the context of the
system in accordance with the principles of architectural design as well as domain
knowledge. Typically, a system is partitioned into layers and each layer is decomposed to
form the subsystems.
2.2 Object-Oriented Decomposition
Decomposition means dividing a large complex system into a hierarchy of smaller components with
lesser complexities, on the principles of divide–and–conquer. Each major component of the system is
called a subsystem. Object-oriented decomposition identifies individual autonomous objects in a
system and the communication among these objects.
The advantages of decomposition are −
The individual components are of lesser complexity, and so more understandable and
manageable.
, It enables division of workforce having specialized skills.
It allows subsystems to be replaced or modified without affecting other subsystems.
2.3 Identifying Concurrency
Concurrency allows more than one objects to receive events at the same time and more than one
activity to be executed simultaneously. Concurrency is identified and represented in the dynamic
model.
To enable concurrency, each concurrent element is assigned a separate thread of control. If the
concurrency is at object level, then two concurrent objects are assigned two different threads of
control. If two operations of a single object are concurrent in nature, then that object is split among
different threads.
Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a clear
strategy needs to be made whenever concurrency is required. Besides, concurrency requires to be
identified at the design stage itself, and cannot be left for implementation stage.
2.4 Identifying Patterns
While designing applications, some commonly accepted solutions are adopted for some categories of
problems. These are the patterns of design. A pattern can be defined as a documented set of building
blocks that can be used in certain types of application development problems.
Some commonly used design patterns are −
Façade pattern
Model view separation pattern
Observer pattern
Model view controller pattern
Publish subscribe pattern
Proxy pattern
2.5 Controlling Events
During system design, the events that may occur in the objects of the system need to be identified
and appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time and space.
There are four types of events that can be modelled, namely −
Signal Event − A named object thrown by one object and caught by another object.
Call Event − A synchronous event representing dispatch of an operation.
Time Event − An event representing passage of time.
Change Event − An event representing change in state.
2.6 Handling Boundary Conditions
The system design phase needs to address the initialization and the termination of the system as a
whole as well as each subsystem. The different aspects that are documented are as follows −
The start–up of the system, i.e., the transition of the system from non-initialized state to
steady state.
, The termination of the system, i.e., the closing of all running threads, cleaning up of
resources, and the messages to be sent.
The initial configuration of the system and the reconfiguration of the system when needed.
Foreseeing failures or undesired termination of the system.
Boundary conditions are modelled using boundary use cases.
3 Object Design
After the hierarchy of subsystems has been developed, the objects in the system are identified and
their details are designed. Here, the designer details out the strategy chosen during the system design.
The emphasis shifts from application domain concepts toward computer concepts. The objects
identified during analysis are etched out for implementation with an aim to minimize execution time,
memory consumption, and overall cost.
Object design includes the following phases −
Object identification
Object representation, i.e., construction of design models
Classification of operations
Algorithm design
Design of relationships
Implementation of control for external interactions
Package classes and associations into modules
3.1 Object Identification
The first step of object design is object identification. The objects identified in the object–oriented
analysis phases are grouped into classes and refined so that they are suitable for actual
implementation.
The functions of this stage are −
Identifying and refining the classes in each subsystem or package
Defining the links and associations between the classes
Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
Designing aggregations
3.2 Object Representation
Once the classes are identified, they need to be represented using object modelling techniques. This
stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
Static Models − To describe the static structure of a system using class diagrams and object
diagrams.
Dynamic Models − To describe the dynamic structure of a system and show the interaction
between classes using interaction diagrams and state–chart diagrams.
3.3 Classification of Operations
In this step, the operation to be performed on objects are defined by combining the three models
developed in the OOA phase, namely, object model, dynamic model, and functional model. An
operation specifies what is to be done and not how it should be done.
The following tasks are performed regarding operations −
1 Object Oriented Analysis (OOA)
Object Oriented Analysis (OOA) is the first technical activity performed as part of object oriented
software engineering. OOA introduces new concepts to investigate a problem. It is based in a set of
basic principles, which are as follows-
The information domain is modeled.
Behavior is represented.
Function is described.
Data, functional, and behavioral models are divided to uncover greater detail.
Early models represent the essence of the problem, while later ones provide implementation
details.
2 Object oriented design
After the analysis phase, the conceptual model is developed further into an object-oriented model
using object-oriented design (OOD). In OOD, the technology-independent concepts in the analysis
model are mapped onto implementing classes, constraints are identified, and interfaces are designed,
resulting in a model for the solution domain. In a nutshell, a detailed description is constructed
specifying how the system is to be built on concrete technologies
The stages for object–oriented design can be identified as −
Definition of the context of the system
Designing system architecture
Identification of the objects in the system
Construction of design models
Specification of object interfaces
2.1 System Design
Object-oriented system design involves defining the context of a system followed by designing the
architecture of the system.
Context − The context of a system has a static and a dynamic part. The static context of the
system is designed using a simple block diagram of the whole system which is expanded into
a hierarchy of subsystems. The subsystem model is represented by UML packages. The
dynamic context describes how the system interacts with its environment. It is modelled
using use case diagrams.
System Architecture − The system architecture is designed on the basis of the context of the
system in accordance with the principles of architectural design as well as domain
knowledge. Typically, a system is partitioned into layers and each layer is decomposed to
form the subsystems.
2.2 Object-Oriented Decomposition
Decomposition means dividing a large complex system into a hierarchy of smaller components with
lesser complexities, on the principles of divide–and–conquer. Each major component of the system is
called a subsystem. Object-oriented decomposition identifies individual autonomous objects in a
system and the communication among these objects.
The advantages of decomposition are −
The individual components are of lesser complexity, and so more understandable and
manageable.
, It enables division of workforce having specialized skills.
It allows subsystems to be replaced or modified without affecting other subsystems.
2.3 Identifying Concurrency
Concurrency allows more than one objects to receive events at the same time and more than one
activity to be executed simultaneously. Concurrency is identified and represented in the dynamic
model.
To enable concurrency, each concurrent element is assigned a separate thread of control. If the
concurrency is at object level, then two concurrent objects are assigned two different threads of
control. If two operations of a single object are concurrent in nature, then that object is split among
different threads.
Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a clear
strategy needs to be made whenever concurrency is required. Besides, concurrency requires to be
identified at the design stage itself, and cannot be left for implementation stage.
2.4 Identifying Patterns
While designing applications, some commonly accepted solutions are adopted for some categories of
problems. These are the patterns of design. A pattern can be defined as a documented set of building
blocks that can be used in certain types of application development problems.
Some commonly used design patterns are −
Façade pattern
Model view separation pattern
Observer pattern
Model view controller pattern
Publish subscribe pattern
Proxy pattern
2.5 Controlling Events
During system design, the events that may occur in the objects of the system need to be identified
and appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time and space.
There are four types of events that can be modelled, namely −
Signal Event − A named object thrown by one object and caught by another object.
Call Event − A synchronous event representing dispatch of an operation.
Time Event − An event representing passage of time.
Change Event − An event representing change in state.
2.6 Handling Boundary Conditions
The system design phase needs to address the initialization and the termination of the system as a
whole as well as each subsystem. The different aspects that are documented are as follows −
The start–up of the system, i.e., the transition of the system from non-initialized state to
steady state.
, The termination of the system, i.e., the closing of all running threads, cleaning up of
resources, and the messages to be sent.
The initial configuration of the system and the reconfiguration of the system when needed.
Foreseeing failures or undesired termination of the system.
Boundary conditions are modelled using boundary use cases.
3 Object Design
After the hierarchy of subsystems has been developed, the objects in the system are identified and
their details are designed. Here, the designer details out the strategy chosen during the system design.
The emphasis shifts from application domain concepts toward computer concepts. The objects
identified during analysis are etched out for implementation with an aim to minimize execution time,
memory consumption, and overall cost.
Object design includes the following phases −
Object identification
Object representation, i.e., construction of design models
Classification of operations
Algorithm design
Design of relationships
Implementation of control for external interactions
Package classes and associations into modules
3.1 Object Identification
The first step of object design is object identification. The objects identified in the object–oriented
analysis phases are grouped into classes and refined so that they are suitable for actual
implementation.
The functions of this stage are −
Identifying and refining the classes in each subsystem or package
Defining the links and associations between the classes
Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
Designing aggregations
3.2 Object Representation
Once the classes are identified, they need to be represented using object modelling techniques. This
stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
Static Models − To describe the static structure of a system using class diagrams and object
diagrams.
Dynamic Models − To describe the dynamic structure of a system and show the interaction
between classes using interaction diagrams and state–chart diagrams.
3.3 Classification of Operations
In this step, the operation to be performed on objects are defined by combining the three models
developed in the OOA phase, namely, object model, dynamic model, and functional model. An
operation specifies what is to be done and not how it should be done.
The following tasks are performed regarding operations −
