Object oriented analysis and design unit

1. Page | 1
Object Oriented Analysis and Design
M.Sc. Computer Science
III Semester
MS. Arati Singh
Department of Computer Science
Shri Shankaracharya Mahavidyalaya Junwani Bhilai

2. Unit-5
Design Refinement
Refinement is a term for cultural and social sophistication that might be defined as subtle good
taste. It is a human characteristic that is often used to describe people who strongly exemplify a
culture, art, society or philosophy. In the past, it was associated with class, status and privilege.
Refinement in Design
Refinement is a result of mastery of design and isn't something that is easily simulated. A refined
design might be described as a design that triggers deep admiration, particularly amongst enthusiasts
of a particular design culture or philosophy.
Designing for Extensibility
Extensibility is a software engineering and systems design principle where the implementation takes
future growth into consideration.
The term extensibility can also be seen as 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.
An extensible system is one whose internal structure and dataflow are minimally or not affected by
new or modified functionality, for example recompiling or changing the original source code might
be unnecessary when changing a system’s behavior, either by the creator or other programmers.
Because software systems are long lived and will be modified for new features and added
functionalities demanded by users, extensibility enables developers to expand or add to the
software’s capabilities and facilitates systematic reuse.
Some of its approaches include facilities for allowing users’ own program routines to be inserted and
the abilities to define new data types as well as to define new formatting markup tags.
Extensible design in software engineering is to accept that not everything can be designed in advance.
A light software framework which allows for changes is provided instead.
Small commands are made to prevent from losing the element of extensibility, following the
principle of separating work elements into comprehensible units, in

3. order to avoid traditional software development issues including low cohesion and high coupling and
allow for continued development.
Embracing change is essential to the extensible design, in which additions will be continual. Each
chunk of the system will be workable with any changes, and the idea of change through addition is
the center of the whole system design.
Extensible design supports frequent re-prioritization and allows functionality to be implemented in
small steps upon request, which are the principles advocated by the agile methodologies and iterative
development.
Extensibility imposes fewer and cleaner dependencies during development, as well as reduced
coupling and more cohesive abstractions, plus well defined interfaces.
There are three different forms of software extensibility: white-box extensibility, gray-box
extensibility, and black-box extensibility, which are based on what artifacts and the way they are
changed.
White-Box
Under this form of extensibility, a software system can be extended by modifying the source code,
and it is the most flexible and the least restrictive form. There are two sub-forms of extensibility,
open-box extensibility and glass-box extensibility, depending on how changes are applied.
Open-Box
Changes are performed invasively in open-box extensible systems; i.e. original source code is
directly being hacked into. It requires available source code and the modification permitted source
code license. Open-box extensibility is most relevant to bug fixing, internal code refactoring, or
production of next version of a software product.
Glass-Box
Glass-box extensibility (also called architecture driven frameworks) allows a software system to be
extended with available source code, but may not allow the code to be modified. Extensions have to
be separated from the original system in a way that the original system is not affected. One example
of this form of extensibility is object-oriented application frameworks which achieve extensibility
typically by using inheritance and dynamic binding.
Black-Box
In black-box extensibility (also called data-driven frameworks) no details about a system’s
implementation are used for implementing deployments or extensions; only interface specifications
are provided. This type of approach is more limited than the various white-box approaches. Black-
box extensions are typically achieved through system configuration applications or the use of
application- specific scripting languages by defining components interfaces.

4. Gray-Box
Gray-box extensibility is a compromise between a pure white-box and a pure black-box approach,
which does not rely fully on the exposure of source code. Programmers could be given the system’s
specialization interface which lists all available abstractions for refinement and specifications on
how extensions should be developed.
Design for reusability
In information technology, design reuse is the inclusion of previously designed components (blocks
of logic or data) in software and hardware. The term is more frequently used in hardware
development.
Design reuse makes it faster and cheaper to design and build a new product, since the reused
components will not only be already designed but also tested for reliability. Developers can reuse a
component in both similar and completely different applications: for example, a component used as
part of a central processing unit ( CPU ) for a PC could be reused in a handheld device or a set-top
box. In hardware development, components in design reuse are called IP cores (intellectual property
cores).
Design reuse is a somewhat controversial issue within the electronic design automation ( EDA )
industry for a number of reasons, including the desire of many engineers to design the complete
product, and - according to some - the conservative nature of engineers as a group.
A number of organizations, such as the Free-IP Project and Open Cores, have formed to promote
design reuse.
Design reuse is the process of building new software applications and tools by reusing previously
developed designs. New features and functionalities may be added by incorporating minor changes.
Design reuse involves the use of designed modules, such as logic and data, to build a new and
improved product. The reusable components, including code segments, structures, plans and reports,
minimize implementation time and are less expensive. This avoids reinventing existing software by
using techniques already developed and to create and test the software.
Design reuse is used in a variety of fields, from software and hardware to manufacturing and
aeronautics.

5. Design reuse involves many activities utilizing existing technologies to cater to new design needs.
The ultimate goal of design reuse is to help the developers create better products maximizing it's
value with minimal resources, cost and effort.
Today, it is almost impossible to develop an entire product from scratch. Reuse of design becomes
necessary to maintain continuity and connectivity. In the software field, the reuse of the modules and
data helps save implementation time and increases the possibility of eliminating errors due to prior
testing and use.
Design reuse requires that a set of designed products already exist and the design information
pertaining to the product is accessible. Large software companies usually have a range of designed
products. Hence the reuse of design facilitates making new and better software products.
Many software companies have incorporated design reuse and have seen considerable success.
The effectiveness of design reuse is measured in terms of production, time, cost and quality of the
product. These key factors determine whether a company has been successful in making design reuse
a solution to its new software needs and demands. With proper use of existing technology and
resources, a company can benefit in terms of cost, time, performance and product quality.
A proper process requires an intensive design reuse process model. There are two interrelated process
methodologies involved in the systematic design reuse process model.
The data reuse process is as follows:
1. Gathering Information: This involves the collection of information, processing
and modeling to fetch related data.
2. Information Reuse: This involves the effective use of data. The
design reuse process has four major issues:
1. Retrieve
2. Reuse
3. Repair
4. Recover

6. Checking Completeness and Correctness
A safe system is free from accidents or unacceptable losses. Safety analysis should identify hazards
based on the (formal) model of the system. Accidents related to computers are usually resulted from
flaws in the specification (model). In formal criteria were defined that should be satisfied to avoid
incorrect specifications.
These criteria cover general aspects of the specification of a control system, including also peculiar
ones like environmental capacity and data age. The most important desirable properties of a
specification are completeness and consistency.
Completeness with respect to an embedded control system means that a response is specified for
every possible input sequence, including also timing variations (early, lately, delayed etc. signals).
Consistency of the specification implies that there are no conflicting requirements and no
(unintentional) non-determinism.
Tool support for checking completeness and consistency is required, since manual checking is error-
prone and time-consuming.
From the point of view of the automated methods and techniques, different approaches can be
distinguished:
- Pure reachability analysis of the state space of the system can detect ambiguous
situations resulting e.g. from unreachable states, undesired global states (in
concurrent models) or unwanted sequence ofactions.
The examination of the global state space requires the generation of the
reachability graph, which often results in state space explosion.
-Model checking examines properties expressed in temporal logics. Modern model
checkers try to handle the state space explosion by applying sophisticated methods in
representing and analyzing the global state space (e.g. symbolic techniques, partial
ordering).
- Theorem proving systems require to describe both the specification and the
criteria in a formal logic, and prove that the criteria and the specification are suitably
related.
- Static analysis is performed directly on the model and checks those criteria that
are not related with the global state space

7. Completeness and consistency can be given as criteria to be satisfied by the hypothetical state
machine (automaton) implementing the state chart specification. The global states of this automaton
are called statuses; its transitions are called step transitions.
Statuses are composed of active states of the state chart by considering that if a composite state
(concurrent composite state) is active then one of its substrates has to be active (in each of its regions,
respectively).
Step transitions are composed of (concurrent) transitions of the state chart. Completeness means that
in all possible statuses of the automaton, for all possible events, there must be a step transition (in a
special case an internal transition) defined which is triggered by the event.
Consistency means that in each status, each event should trigger only a single step transition. Static
checking requires re-formulating these criteria in syntactic terms of the state chart, taking into
account the UML semantics covering hierarchy, concurrency, and priority scheme. In the following
we examine states, transitions, guards and compound transitions of the state chart and formulate the
criteria in these terms.
Persistent Object and Database Issues
The data manipulated by an object-oriented database can be either transient or persistent.
Transient data is only valid inside a program or transaction; it is lost once the program or transaction
terminates.
Persistent data is stored outside of a transaction context, and so survives transaction updates. Usually
the term persistent data is used to indicate the databases that are shared, accessed and updated across
transactions.
The two main strategies used to create and identify persistent objects are:
• Persistence extensions
• Persistence through reachability
Several object-oriented databases incorporate the notion of a class extension to make the instances
of a class persistent. With class extensions, the class also serves as a set of objects.
Persistence and class extensions are orthogonal in the sense that one can have an object-oriented
system that has class extensions, but uses different mechanism for persistence.

8. However, the object-oriented database languages that support class extensions usually make the
extensions persistent.
The persistent object space has a root called database and every object reachable from this database
root is persistent. The authors define the persistent object space as follows:
1. Database is a persistent tuple object: database = [S1: {…} , S2: {…} , … , Sn: {…}]
2. If pT is a persistent tuple object, then pT.a (the attribute a of pT) is a persistent object.
3. If pS is a persistent set of object then every element e of pS is persistent
Object Oriented Database Management System
An object-oriented database management system (OODBMS) is a database management system that
supports the creation and modeling of data as objects. OODBMS also includes support for classes of
objects and the inheritance of class properties, and incorporates methods, subclasses and their
objects.
Most of the object databases also offer some kind of query language, permitting objects to be found
through a declarative programming approach.
An object-oriented database management system represents information in the form of objects as
used in object-oriented programming. OODBMS allows object- oriented programmers to develop
products, store them as objects and replicate or modify existing objects to produce new ones within
OODBMS.
OODBMS allows programmers to enjoy the consistency that comes with one programming
environment because the database is integrated with the programming language and uses the same
representation model. Certain object- oriented databases are designed to work with object-oriented
programming languages such as Delphi, Python, Java, Perl, Objective C and Visual Basic.NET.
An object-oriented database management system (OODBMS), sometimes shortened to ODBMS for
object database management system), is a database management system (DBMS) that supports the
modelling and creation of data as objects.
This includes some kind of support for classes of objects and the inheritance of class properties and
methods by subclasses and their objects. There is currently no widely agreed-upon standard for what
constitutes an OODBMS, and OODBMS products are considered to be still in their infancy.

9. In the meantime, the object-relational database management system (ORDBMS), the idea that
object-oriented database concepts can be superimposed on relational databases, is more commonly
encountered in available products. An object- oriented database interface standard is being developed
by an industry group, the Object Data Management Group (ODMG).
The Object Management Group (OMG) has already standardized an object- oriented data brokering
interface between systems in a network.
Introduction to Object based databases
• Object oriented database systems are alternative to relational database and other database systems.
• In object oriented database, information is represented in the form of objects.
• Object oriented databases are exactly same as object oriented programming languages. If we can
combine the features of relational model (transaction, concurrency, recovery) to object oriented
databases, the resultant model is called as object oriented database model.
Features of OODBMS
In OODBMS, every entity is considered as object and represented in a table. Similar objects are
classified to classes and subclasses and relationship between two object is maintained using concept
of inverse reference.
Some of the features of OODBMS are as follows:

10. 1. Complexity
OODBMS has the ability to represent the complex internal structure (of object) with multilevel
complexity.
2. Inheritance
Creating a new object from an existing object in such a way that new object inherits all
characteristics of an existing object.
3. Encapsulation
It is an data hiding concept in OOPL which binds the data and functions together which can
manipulate data and not visible to outside world.
4. Persistency
OODBMS allows to create persistent object (Object remains in memory even after execution). This
feature can automatically solve the problem of recovery and concurrency.
Challenges in ORDBMS implementation
During the implementation of ORDBMS, various challenges arise which need to be resolved.
They are:
1. Storage and accessibility of data
It is possible to define new types with new access to structures with the help of OODBMS. Hence,
it is important that the system must store ADT and structured objects efficiently along with the
provision of indexed access.
Challenge : Storage of large ADTs and structured objects.
Solution: As large ADTs need special storage, it is possible to store them on different locations on
the disk from the tuples that contain them. For e.g. BLOBs (Binary Large Object like images,
audio or any multimedia object.) Use of flexible disk layout mechanisms can solve the storage
problem of structured objects.

11. 2. Query Processing
Challenge: Efficient flow of Query Processing and optimization is a difficult task. Solution: By
registering the user defined aggregation function, query processing becomes easier. It requires three
implementation steps - initialize, iterate and terminate.
3. Query Optimization
Challenge: New indexes and query processing techniques increase the options for query
optimization. But, the challenge is that the optimizer must know to handle and use the query
processing functionality properly. Solution: While constructing a query plan, an optimizer
must be familiar to the newly added index structures.
Object Oriented verses Relational Database
A relational database relies on the relational model, on the other hand a object database relies on
the OOP. In an object oriented database each element resembles a object from the object oriented
paradigm.
The difference between relational database and object oriented database is that the relational data
base stores data in the form of tables which contains rows and columns. Every column in the table
has its specific name and every row of the table has its own primary key.
While in the object oriented database the data is stored in the form of objects. In the object oriented
data the data is stored along with its actions that processes or reads the existing data.
Criteria RDBMS
ODBMS
Defining standard SQL2 (ANSI X3H2) ODMG-V2.0
Support for object-
oriented programming
Poor; programmers spend 25% of
coding time mapping the program
object to the database
Direct and extensive

12. Simplicity of use Table structures easy
to understand; many
end-user tools available
OK for programmers;
some SQL access for end
users
Simplicity of
development
Provides independence of data
from application, good for
simple relationships
Objects are a natural way
to model; can
accommodate a wide
variety of types and
relationships
Extensibility and
content
None Can handle arbitrary
complexity; users
can write methods and on
any structure
Complex data
relationships
Difficult to model Can handle arbitrary
complexity; users can
write methods and on any
structure
Performance versus
interoperability
Level of safety varies with
vendor, must be traded off;
achieving both requires
extensive testing
Level of safety varies with
vendor; most ODBMSs
allow programmers to
extend DBMS functionality
by defining new classes
Distribution,
replication, and
federated databases
Extensive Varies with vendor; a few
provide extensive support
Product maturity Very mature Relatively mature
Legacy people and the
universality of SQL
Extensive supply of tools and
trained developers
SQL accommodated, but
intended for object-
oriented programmers
Software ecosystems Provided by major RDBMS
companies
ODBMS vendors
beginning to emulate

13. RDBMS vendors, but
none offers large markets
to other ISVs
Mapping Objects to Relational Databases
Visual Paradigm supports Object Relational Mapping (ORM) which maps object models to entity
relational models and vice versa. Visual Paradigm helps mapping between Java objects to relational
database. It not only preserves the data, but also the state, foreign/primary key mapping, difference
in data type and business logic. Thus, you are not required to handle those tedious tasks during
software development.
Mapping classes to entities
Generally speaking, the mapping between class and entity is a one-to-one mapping, meaning that
one class in object model maps with one entity in data model. Classes that map with entities are
represented by the stereotype <<ORM Persistable>>.
Mapping class
In the above example, the Customer class is the object equivalent of the Customer entity.
This means that in application development or in runtime, an instance of Customer (class) stores the
information of a customer retrieved from the Customer table of database.
Mapping attributes to columns
Since the persistent classes map to the entities, persistent attributes map to columns accordingly.
Visual Paradigm ignores all non-persistent attributes such as derived values.

14. Mapping attributes
Mapping data type
Persistent attribute types are automatically mapped to appropriate column data types of the database
you desired. The following table lists out the typical mapping between object model and data model.
Note that the actual data type to map to depends on the default database you selected in database
configuration.
Object Model Data Model
Boolean Bit (1)
Byte Tinyint (3)
Byte[] Binary (1000)
Blob Blob
Char Char (1)
Character Char (1)
String varchar (255)
Int Integer (10)
Integer Integer (10)
Double Double (10)

15. Decimal Integer
Bigdecimal Decimal (19)
Float Float (10)
Long Bigint (19)
Short Smallint (5)
Date Date
Time Time (7)
Timestamp Timestamp (7)
Mapping of data types between object and data model
Mapping primary key
You can map an attribute to a primary key column. When you synchronize the ORM-Persist able
Class to the ERD, you will be prompted by a window to select primary key.

16. Selecting the way to map primary key
You can select an existing attribute as primary key, let us generate one for you

17. Mapping primary key
The above diagram shows if you assign ProductID as primary key, the ProductID of the
generated entity, Product will become bold; whereas if you select Auto Generate for the primary
key, Visual Paradigm generates an additional attribute ID as the primary key of the Product entity.
Mapping association
Association represents a binary relationship among classes. Each class of an association has a role.
A role name is attached at the end of an association line. Visual Paradigm maps the role name
to a phrase of relationship in the data model.
Mapping aggregation
Aggregation is a stronger form of association. It represents the "has-a" or "part-of" relationship.
Mapping aggregation
In the above example, it shows that a company consists of one or more department while a
department is a part of the company.
Mapping composition
Composition implies exclusive ownership of the "part-of" classes by the "whole" class. It means that
parts may be created after a composite is created, meanwhile such parts will be explicitly removed
before the destruction of the composite.

18. Mapping composition
In the above example, Visual Paradigm performs the Primary/Foreign Key Column Mapping
automatically. ID of the Student entity is added to the entity, EmergencyContact as
primary and foreign key column.
Mapping multiplicity
Multiplicity refers to the number of objects associated with a given object. There are six types of
multiplicity commonly found in the association. The following table shows the syntax to express
Multiplicity.
Type of Multiplicity Description
0 Zero instance
0..1 Zero or one instance
0..* Zero or more instances
1 Exactly one instance
1..* One of more instances
* Unlimited number of instances
Description of multiplicities

19. Mapping multiplicity
In the above example, it shows that a parent directory (role: parent) contains zero or more
subdirectories (role: children).
Mapping many-to-many association
For a many-to-many association between two classes, Visual Paradigm will generate a Link Entity
to form two one-to-many relationships in-between two generated entities. The primary keys of the
two entities will migrate to the link entity as the primary/foreign keys.
Mapping many-to-many association
In the above example, Visual Paradigm generates the link entity, Student_Course
between entities of Student and Course when transforming the many-to-many association.
Mapping inheritance/generalization
Generalization distributes the commonalities from the superclass among a group of similar
subclasses. The subclass inherits all the superclass's attributes and it may contain specific attributes.
We provide multiple strategies for transforming the generalization hierarchy to relational model.
Click here to learn more about the various inhertance strategies.

20. Mapping collection of objects to Array Table
For a persistent class acting as persistent data storage, it may consist of a persistent data containing
a collection of objects. Visual Paradigm promotes the use of Array Table to allow users retrieve
objects in the form of primitive array.
When Visual Paradigm transforms a class with an attribute of array type modifier, this attribute will
be converted to an Array Table automatically. The generated entity and the array table form a one-
to-many relationship.
Mapping collection of objects to Array Table
In the above example, each contact person may have more than one phone numbers. In order to ease
the retrieval of a collection of phone objects, Visual Paradigm converts the phone attribute into a
ContactEntry_Phone array table.
Typical mapping between object model and data model
Object Model Data Model

21. Typical mapping between object model and data model
OOAD - Testing & Quality Assurance
Once a program code is written, it must be tested to detect and subsequently handle all errors in it.
A number of schemes are used for testing purposes.
Another important aspect is the fitness of purpose of a program that ascertains whether the program
serves the purpose which it aims for. The fitness defines the software quality.
Testing Object-Oriented Systems
Testing is a continuous activity during software development. In object-oriented systems, testing
encompasses three levels, namely, unit testing, subsystem testing, and system testing.
Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free. Unit testing
is the responsibility of the application engineer who implements the structure.
Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of the subsystem
lead. It involves testing the associations within the subsystem as well as the interaction of the
subsystem with the outside. Subsystem tests can be used as regression tests for each newly released
version of the subsystem.
System Testing
System testing involves testing the system as a whole and is the responsibility of the quality-
assurance team. The team often uses system tests as regression tests when assembling new releases.
Object-Oriented Testing Techniques Grey
Box Testing
The different types of test cases that can be designed for testing object-oriented programs are called
grey box test cases. Some of the important types of grey box testing are −
• State model based testing − This encompasses state coverage, state transition coverage,
and state transition path coverage.
• Use case based testing − Each scenario in each use case is tested.

22. • Class diagram based testing − Each class, derived class, associations, and aggregations are
tested.
• Sequence diagram based testing − The methods in the messages in the sequence diagrams
are tested.
Techniques for Subsystem Testing
The two main approaches of subsystem testing are −
• Thread based testing − All classes that are needed to realize a single use case in a
subsystem are integrated and tested.
• Use based testing − The interfaces and services of the modules at each level of hierarchy
are tested. Testing starts from the individual classes to the small modules comprising of
classes, gradually to larger modules, and finally all the major subsystems.
Categories of System Testing
• Alpha testing − This is carried out by the testing team within the organization that develops
software.
• Beta testing − This is carried out by select group of co-operating customers.
• Acceptance testing − This is carried out by the customer before accepting the deliverables.
Software Quality Assurance
Software Quality
Schulmeyer and McManus have defined software quality as “the fitness for use of the total software
product”. A good quality software does exactly what it is supposed to do and is interpreted in terms
of satisfaction of the requirement specification laid down by the user.
Quality Assurance
Software quality assurance is a methodology that determines the extent to which a software product
is fit for use. The activities that are included for determining software quality are −
• Auditing
• Development of standards and guidelines
• Production of reports
• Review of quality system

23. Quality Factors
• Correctness − Correctness determines whether the software requirements are appropriately
met.
• Usability − Usability determines whether the software can be used by different categories
of users (beginners, non-technical, and experts).
• Portability − Portability determines whether the software can operate in different platforms
with different hardware devices.
• Maintainability − Maintainability determines the ease at which errors can be corrected and
modules can be updated.
• Reusability − Reusability determines whether the modules and classes can be reused for
developing other software products.
Object-Oriented Metrics
Metrics can be broadly classified into three categories: project metrics, product metrics, and process
metrics.
Project Metrics
Project Metrics enable a software project manager to assess the status and performance of an
ongoing project. The following metrics are appropriate for object-oriented software projects −
• Number of scenario scripts
• Number of key classes
• Number of support classes
• Number of subsystems
Product Metrics
Product metrics measure the characteristics of the software product that has been
developed. The product metrics suitable for object-oriented systems are −
• Methods per Class − It determines the complexity of a class. If all the methods of a class
are assumed to be equally complex, then a class with more methods is more complex and
thus more susceptible to errors.
• Inheritance Structure − Systems with several small inheritance lattices are more well–
structured than systems with a single large inheritance lattice. As a thumb rule, an
inheritance tree should not have more than 7 (± 2) number of levels and the tree should be
balanced.

24. Page | 24
• Coupling and Cohesion − Modules having low coupling and high cohesion are
considered to be better designed, as they permit greater reusability and maintainability.
• Response for a Class − It measures the efficiency of the methods that are called by the
instances of the class.
Process Metrics
Process metrics help in measuring how a process is performing. They are collected over all
projects over long periods of time. They are used as indicators for long-term software process
improvements. Some process metrics are −
• Number of KLOC (Kilo Lines of Code)
• Defect removal efficiency
• Average number of failures detected during testing
• Number of latent defects per KLOC
References
https://searchcio.techtarget.com/definition/OODA-loop
https://www.tutorialspoint.com/object_oriented_analysis_design/index.htm
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
https://www.techopedia.com/definition/12027/object-oriented-database-management-system-oodbms