Object Oriented System Design

Object Oriented Analysis

Unit 3
Object-Oriented Design
• In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities).
• The state is distributed among the objects, and each object handles its state data.
• For example, in a Library Automation Software, each library representative may be a separate
object with its data and functions to operate on these data.
• The tasks defined for one purpose cannot refer or change data of other objects.
• Objects have their internal data which represent their state. Similar objects create a class.
The different terms related to object design are:
Different terms related to object design

1.Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some attributes
associated with it and has some methods to perform on the attributes.
2.Classes: A class is a generalized description of an object. An object is an instance of a class. A
class defines all the attributes, which an object can have and methods, which represents the
functionality of the object.
3.Messages: Objects communicate by message passing. Messages consist of the integrity of the
target object, the name of the requested operation, and any other action needed to perform the
function. Messages are often implemented as procedure or function calls.
4.Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is
the removal of the irrelevant and the amplification of the essentials.
Different terms related to object design

5. Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information
of an object together but also restricts access to the data and methods from the outside
world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions
from their immediate superclasses.This property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific
ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different types.
Depending upon how the service is invoked, the respective portion of the code gets
executed.
Object Design
• 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
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
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.
Classification of Operations

The following tasks are performed regarding operations −

• The state transition diagram of each object in the system is developed.
• Operations are defined for the events received by the objects.
• Cases in which one event triggers other events in same or different objects are identified.
• The sub–operations within the actions are identified.
• The main actions are expanded to data flow diagrams.
Algorithm Design

There may be more than one algorithm corresponding to a given operation. Once the alternative
algorithms are identified, the optimal algorithm is selected for the given problem domain. The
metrics for choosing the optimal algorithm are −
• Computational Complexity − Complexity determines the efficiency of an algorithm in terms
of computation time and memory requirements.
• Flexibility − Flexibility determines whether the chosen algorithm can be implemented
suitably, without loss of appropriateness in various environments.
• Understandability − This determines whether the chosen algorithm is easy to understand and
implement.
Design of Relationships

• The main relationships that are addressed comprise of associations, aggregations, and
inheritances.
• The designer should do the following regarding associations −
• Identify whether an association is unidirectional or bidirectional.
• Analyze the path of associations and update them if necessary.
• Implement the associations as a distinct object, in case of many–to-many relationships; or as a link to other
object in case of one–to-one or one–to-many relationships.
• Regarding inheritances, the designer should do the following −
• Adjust the classes and their associations.
• Identify abstract classes.
• Make provisions so that behaviors are shared when needed.
Implementation of Control

• The approaches for implementation of the dynamic model are −

• Represent State as a Location within a Program − This is the traditional procedure-driven approach
whereby the location of control defines the program state. A finite state machine can be implemented as a
program. A transition forms an input statement, the main control path forms the sequence of instructions,
the branches form the conditions, and the backward paths form the loops or iterations.
• State Machine Engine − This approach directly represents a state machine through a state machine engine
class. This class executes the state machine through a set of transitions and actions provided by the
application.
• Control as Concurrent Tasks − In this approach, an object is implemented as a task in the programming
language or the operating system. Here, an event is implemented as an inter-task call. It preserves inherent
concurrency of real objects.
Packaging Classes

• The different aspects of packaging are −

• Hiding Internal Information from Outside View − It allows a class to be viewed as a “black
box” and permits class implementation to be changed without requiring any clients of the class
to modify code.
• Coherence of Elements − An element, such as a class, an operation, or a module, is coherent
if it is organized on a consistent plan and all its parts are intrinsically related so that they serve
a common goal.
• Construction of Physical Modules − The following guidelines help while constructing
physical modules −
• Classes in a module should represent similar things or components in the same composite object.
• Closely connected classes should be in the same module.
• Unconnected or weakly connected classes should be placed in separate modules.
• Modules should have good cohesion, i.e., high cooperation among its components.
• A module should have low coupling with other modules, i.e., interaction or interdependence
between modules should be minimum.
Object Design
• 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
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
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.
Classification of Operations

The following tasks are performed regarding operations −

• The state transition diagram of each object in the system is developed.
• Operations are defined for the events received by the objects.
• Cases in which one event triggers other events in same or different objects are identified.
• The sub–operations within the actions are identified.
• The main actions are expanded to data flow diagrams.
Algorithm Design

There may be more than one algorithm corresponding to a given operation. Once the alternative
algorithms are identified, the optimal algorithm is selected for the given problem domain. The
metrics for choosing the optimal algorithm are −
• Computational Complexity − Complexity determines the efficiency of an algorithm in terms
of computation time and memory requirements.
• Flexibility − Flexibility determines whether the chosen algorithm can be implemented
suitably, without loss of appropriateness in various environments.
• Understandability − This determines whether the chosen algorithm is easy to understand and
implement.
Design of Relationships

• The main relationships that are addressed comprise of associations, aggregations, and
inheritances.
• The designer should do the following regarding associations −
• Identify whether an association is unidirectional or bidirectional.
• Analyze the path of associations and update them if necessary.
• Implement the associations as a distinct object, in case of many–to-many relationships; or as a link to other
object in case of one–to-one or one–to-many relationships.
• Regarding inheritances, the designer should do the following −
• Adjust the classes and their associations.
• Identify abstract classes.
• Make provisions so that behaviors are shared when needed.
Implementation of Control

• The approaches for implementation of the dynamic model are −

• Represent State as a Location within a Program − This is the traditional procedure-driven approach
whereby the location of control defines the program state. A finite state machine can be implemented as a
program. A transition forms an input statement, the main control path forms the sequence of instructions,
the branches form the conditions, and the backward paths form the loops or iterations.
• State Machine Engine − This approach directly represents a state machine through a state machine engine
class. This class executes the state machine through a set of transitions and actions provided by the
application.
• Control as Concurrent Tasks − In this approach, an object is implemented as a task in the programming
language or the operating system. Here, an event is implemented as an inter-task call. It preserves inherent
concurrency of real objects.
Packaging Classes

• The different aspects of packaging are −

• Hiding Internal Information from Outside View − It allows a class to be viewed as a “black
box” and permits class implementation to be changed without requiring any clients of the class
to modify code.
• Coherence of Elements − An element, such as a class, an operation, or a module, is coherent
if it is organized on a consistent plan and all its parts are intrinsically related so that they serve
a common goal.
• Construction of Physical Modules − The following guidelines help while constructing
physical modules −
• Classes in a module should represent similar things or components in the same composite object.
• Closely connected classes should be in the same module.
• Unconnected or weakly connected classes should be placed in separate modules.
• Modules should have good cohesion, i.e., high cooperation among its components.
• A module should have low coupling with other modules, i.e., interaction or interdependence
between modules should be minimum.
Jackson System Development (JSD)
• Jackson System Development (JSD)
• It is a method of system development that covers the software life cycle either directly or by providing a
framework into which more specialized techniques can fit.
• JSD can start from the stage in a project when there is only a general statement of requirements.
Phases of JSD:
• modelling phase
• Specification Phase
• Implementation Phase
Modelling phase
• In the modelling phase of JSD the designer creates a collection of entity structure diagrams and identifies the
entities in the system, the actions they perform, the attributes of the actions and time ordering of the actions in
the life of the entities.
Specification Phase
• This phase focuses on actually what is to be done? Previous phase provides the basic for this phase. An
sufficient model of a time-ordered world must itself be time-ordered. Major goal is to map progress in the real
world on progress in the system that models it.
Implementation Phase
• In the implementation phase JSD determines how to obtain the required functionality. Implementation way of
the system is based on transformation of specification into efficient set of processes. The processes involved in
it should be designed in such a manner that it would be possible to run them on available software and
hardware.
JSD Steps:
Initially there were six steps when it was originally presented by Jackson, they were as below:
• Entity/action step

• Initial model step

• Interactive function step

• Information function step

• System timing step

• System implementation step

Merits of JSD:
• It is designed to solve real time problem.

• JSD modelling focuses on time.

• It considers simultaneous processing and timing.

• It is a better approach for micro code application.

Demerits of JSD:
• It is a poor methodology for high level analysis and data base design.

• JSD is a complex methodology due to pseudo code representation.

• It is less graphically oriented as compared to SA/SD or OMT.

• It is a bit complex and difficult to understand.

Translating classes into data structures

• Normally you will implement each class as a single contiguous block of attributes-a record structure. Each
attribute has a declared type, which can be a primitive type, such as integer, real or character or can be a
structured value, such as an embedded record structure or a fixed-length array
• A variable that identifies an object must therefore be implemented as a sharable reference and not simply by
copying the values of an object's attributes.
• Translating Classes into C Struct Declarations
• Each class in the design becomes a C struct. Each attribute defined in the class becomes a field of the C
struct.
The structure for the Window class is declared as:

struct Window
{
Length xmin;
Length ymin;
Length xmax;
Length ymax;
};
Some Questions:-
• An object can be allocated statically, automatically (on the stack), or dynamically (on the heap) because C can
compose a pointer to any object, including one embedded within another structure.
Passing Arguments To Methods
• Every method has at least one argument, the implicit self argument.
• In a non-object-oriented language, the argument must be made explicit, of course.
• Methods may also have additional objects as arguments. Some of the arguments may be simple data
values and not objects.
• In passing an object as an argument to a method, a reference to the object must be passed if the
value of the object can be updated within the method.
• If the method is a query that simply extracts information from an object without modifying it, then
a call-by-value mechanism can be used if the language permits.
• Passing all arguments as references is more uniform.
A consistent naming convention for method function
names.

• in C, concatenate the class name, two underscores, and the operation name. (The two underscores
separate the class name from the operation name, each of which may contain single underscores.)
• Passing arguments in C:
• In C, an object should always be passed by pointer.
• Although C permits structures to be passed by value, passing a pointer to an object structure is
usually more efficient and provides a uniform access mechanism for both query and update
operations.
Example and problem

Window__add_to_selections (self, shape)

struct Window * self;
struct Shape * shape;
Implementing inheritance

• There are several ways to implement data structures for inheritance in a non-object-oriented language:

• Avoid it. Many applications do not require inheritance. Many other applications have only a few classes
requiring inheritance. Those classes not needing inheritance can be implemented as simple records.
• Flatten the class hierarchy. Use inheritance during design but expand each concrete class as an independent
data structure during implementation. Each inherited operation must be reimplemented as a separate method
on each concrete class. Flattening the hierarchy introduces duplication, but the use of language constructs
such as C macros can help. One useful technique is to group some inherited attributes into a record type and
embed the record in each concrete class to reduce the number of duplicated lines in each declaration.

• Break out separate objects. Instead of inheriting common attributes from a superclass, a group of attributes
can be pulled out of all the subclasses and implemented as a separate object with a reference to it stored
within each subclass. Grouping attributes under a separate type permits a single method to be written to
manipulate them. The subclasses must delegate operations to the referenced object.
Implementing Inheritance in C:

• To handle single inheritance, embed the declaration for the superclass as the first part of each
subclass declaration.
• The first field of each struct is a pointer to a class descriptor object shared by all direct instances of
a class.
• The class descriptor object is a struct containing the class attributes, including the name of the class
(optional) and the methods for the class.
• The class Shape is an abstract class, with concrete subclasses Box and Circle.
The C declarations for classes Shape, Box,
and Circle are as follows:
struct Shape
{
struct ShapeClass * class;
Length x;
Length y:
};
struct Box
{
struct BoxClass * class;
Length x;
Length y;
Length width;
Length height;
};
struct Circle
{
struct CircleClass * class:
Length x;
Length y;
Length radius;
};
Contd…

• A pointer to a Box or Circle structure can be passed to a C function .

• Expecting a pointer to a Shape structure because the first part of the Box or Circle structure is
identical to the Shape structure.
• (To be strictly correct, you should cast such an argument to be a pointer to Shape. but most
compilers won't notice the difference anyway.)
• Because the prefix of the structure is the same as the superclass structure, the superclass method
simply ignores the extra fields on the end.
For example, a pointer to Box is interpreted as a pointer
to Shape in the following call:

struct Box * box:

struct Window * window;
Window__add_to_selections (window, box)

The first field of each structure is a pointer to the class descriptor for the actual class of each object instance.
This field is needed only if the run-time method resolution is to be done.
Multiple inheritances cannot be implemented using this approach because a subclass which has two
superclasses can align its attributes with both of them.
Implementing Associations

Implementing associations in a non-object-oriented language present the same two possibilities as in

an object-oriented language: mapping them into pointers or implementing them directly as
association container objects.
• Mapping associations to pointers. The traditional approach to implementing binary
associations is to map each role of an association into an object pointer stored as a field of the
source object record.
Each object contains a pointer to an associated object (if the multiplicity is "one" or "zero-one")
or a pointer to a set of associated objects (if the multiplicity is greater than one).
The association may be implemented in one direction or in both directions. If it is traversed in
only a single direction, it may be implemented as a pointer from one object to another.
Implementing Associations
• Implementing association objects. An association can be implemented directly as a data structure.
If an association relates more than two classes then it cannot be mapped into pointers, and a separate object must
be used in any case.
In its basic form (and its mathematical definition), an association is simply a set of records, each containing one
object ID for each associated class.
The simplest approach is to implement an association as an array or list of records or record pointers.
To traverse a binary link, the list is searched to find a link in which one field is equal to the source object, and
the value of the other field is returned as the target object.
Implementing Association in C:

• A binary association is usually implemented as a field in each associated object, containing a

pointer to the related object or to an array of related objects. For example, would be implemented
as:
struct Item
{
struct Itemclass * class;
struct Group * group;
};
struct Group
{
struct GroupClass * class;
int item_count;
struct Item ** Items;
};
• Other data structures, such as a linked list or a hash table, can also be used to store sets of objects.
• In this example, a group is created from a set of selected items.
• The memory for the items pointer can be allocated all at once since the number of items in a group does not
change.
• If it were possible to add a single new item to a group, then both pointers must be updated:

Group__add_item (self, item)

struct Group * self;
struct Item * item;
{
item->group = self;
self->items = (struct Item **) realloc (self->items, ++self->item count sizeof (struct Item *));
self->items [self->item_count-1] = item;
}
Object oriented programming style
• Reusability:
Reusable software reduces design, coding, and testing cost by amortizing effort over several designs.
Reducing the amount of code also simplifies understanding, which increases the likelihood that the
code is correct.
Reuse is possible in conventional languages, but object-oriented languages greatly enhance the
possibility of code reuse.
Extensibility:
• Extensibility is a system design principle where the implementation takes future growth into consideration.
• It is a systemic measure of the ability to extend a system and the level of effort required to implement the
extension.
• Extensions can be through the addition of new functionality or through modification of existing functionality.
• The central theme is to provide for change typically enhancements while minimizing impact to existing
system functions.
Robustness
A method is robust if it does not fail even if it receives improper parameters. Robustness against internal bugs
may be traded off against efficiency. Robustness against user errors should never be sacrificed.
• Protect against errors. The software should protect itself against incorrect user input. Incorrect
• user input should never cause a crash. Any method that accepts user input must validate input that could cause trouble.
• Optimize after the program runs. Avoid optimizing more of the program than you have to, as
optimization compromises extensibility, reusability, and understandability.
• If methods are properly encapsulated, they can be replaced with optimized versions without affecting the rest of the
program.
• Validate arguments. External operations, those available to users of the class, must rigorously check their
arguments to prevent failure.
• But internal methods may assume their arguments are valid for efficiency reasons.
• Public methods must take more care to check the validity of arguments because external users
are more likely to violate restrictions on arguments Internal, or private, methods can often
assume preconditions since the implementor has tighter control and can rely on the public
methods that call them for error checking.
• Avoid predefined limits. When possible use dynamic memory allocation to create data structures that do not
have predefined limits.
Programming in the large

• Programming-in-the-large refers to writing large, complex programs with teams of programmers.

Human communication becomes paramount on such projects and requires proper software
engineering practices.
• The following guidelines should be observed:
1. Do not prematurely begin programming.
2. Keep methods understandable.
3. Make methods readable Meaningful variable names increase readability.
4. Use exactly the same names as in the object model.
5. Choose the names carefully.
6. Use Programming guidelines.
7. Package into modules.
8. Document classes and methods.
9. Publish the specification.