Page 116 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes All participants in the process need to be familiar with their context: where do their inputs come
from and who uses their outputs. A business analyst operates in the requirements domain, but
they must understand both the customer’s needs and the task faced by the technical analyst who
translates their requirements into the problem domain. Similarly, technical analysts must
understand both requirements and the technical difficulties faced by developers who must work
in the solution domain.
The requirement document will be the main document for developers, testers and database
administrators. In other words, this is the main document that will be referred by everyone.
After the requirement documents, other detailed documents many be needed.

Example: The architectural design which is a blueprint for the design with the necessary
specifications for the hardware, software, people and data resources.

!
Caution Developers need to understand the problem domain model, and they have to
understand the target technology.

The object-oriented methodology developed based on the lack of synergy between process-
centered and data-centered approaches in SDLC (software development life cycle). Decomposition
of system into a set of process (process centric) or data (data centric) cannot be easily obtained,
as both aspects are closely related one another.

It is difficult to develop system by primarily focusing only to one aspect. As result, the system
produced tends to be extendable only in one world. A process centric developed system cannot
be easily extended when there are changes in type of data in the system. This kind of problems
also exists in the data centric developed system.
OO methodology decomposes problems into objects. Objects are considered part of the system
that contains both process and data, an object may do some activities/processes (mapped as
object methods), an object may also have states (mapped as object attributes). This way, developers
will focus on the entity in the system that actually does processes and carries data, rather than
focus primarily only to one aspect.

Notes OO-based system development extensively uses a tool called UML (Unified
Modeling Language), which is a set of standard in diagramming and modeling techniques
invented by three OO champions, Grady Booch, Ivar Jacobson, and James Rumbaugh,
when they worked together in Rational Software. In 1997 UML proposed to and accepted
by the Object Management Group (OMG) as a standard diagramming notation in object-
oriented system development.

An OO approaches in system development must be:
Use case Drive: This means that use case is the primary modeling tool to define system
behavior. Use cases describe how the users of the system interact with the system to
perform activity. And as a use case focuses only to one activity at a time, it is inherently
simple.
Architecture Centric: The term architecture centric gives a high level view of the system
being developed. The software architecture chosen for the system should drive the
specification, construction, and documentation of the system itself. The system architecture
must support three views of the system:

110 LOVELY PROFESSIONAL UNIVERSITY