Download - OOAD Final
-
8/8/2019 OOAD Final
1/124
CA 5202 Object Oriented Analysis and Design
Chapter - 1
Object-Oriented (OO) Software Development Process (SDP)
Introduction
Software engineering is a systematic and disciplined methodology for producing reliable
and workable software using a suite of sound engineering principles. For any system to be
engineered and sustained, we need an array of trend-setting technologies, proven
processes, scalable infrastructures and adaptive resources including humans. Software
engineering also like other core engineering disciplines needs a host of standardized,
industrial-strength and well-defined development processes.
There are a bewildering array of software applications and types. Primarily software is
classified into two: system and application software. A typical system software mainly
interacts with the computer, its components and peripherals such as printer, webcam,
scanner, mouse, USB drive etc besides with all the network infrastructure solutions such
as routers, switches, bridges, hubs, gateways, etc. The application software generally
interacts with the system software. The details are as follows.
1.1 Software Types
System Software is a collection of programs written to service other programs. Some
system software such as program language compilers, interpreters and file systems process
complex, but determinate, information structures. Other system software, such as device
drivers, operating systems, protocols, etc, are destined to process largely indeterminate
data. Thus the primary characteristics of system software are as given below. It
Needs to interact with computer hardware and other peripherals,
Might be used by multiple applications and users
Involves concurrent operation that requires scheduling, slicing, time & resource
sharing, and sophisticated process management
Includes complex data structures and multiple external interfaces
Middleware is an emerging software type that sits in between application and system
software facilitating smooth interaction, collaboration, communication, integration,connectivity, and adaptation purposes.
AVCCE, Dept. of MCA III Semester 1
-
8/8/2019 OOAD Final
2/124
CA 5202 Object Oriented Analysis and Design
Real-time Software represents programs that monitor / analyze / control real world events
as they occur. Elements of real-time software include a data gathering component that
collects and formats information from an external environment, an analysis component
that transforms information as required by the application, a control / output componentthat responds to the external environment, and a monitoring component that coordinates
all other components so that real-time response can be maintained. Thus a real-time
system must respond within strict time constraints.
Engineering and scientific software has been all along characterized primarily by
number crunching algorithms. Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular biology
to automated manufacturing. These are processing-intensive applications.
Embedded software is becoming hugely popular these days. They are found in consumer
electronics, avionics, handhelds, wearables, portables, mobiles, automobiles, smart homes,
and manufacturing industries. Embedded software resides in real-only memory and is used
to control products and systems for the consumer and industrial markets. Embedded
software can perform very limited and esoteric functions such as key pad control for a
microwave oven or provide significant function and control capabilities (e.g., digital
functions in an automobile such as fuel control, dashboard displays, braking systems etc.).
Communication software facilitates seamless mobility of mobile users and devices
besides ensuring reliable communication among devices.
Artificial Intelligence (AI) software makes use of non-numerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis. An
active area is expert systems, also called knowledge-based systems. Other areas of AI are
machine learning, natural language processing, speech recognition, pattern recognition,
theorem proving, game playing, etc. Incorporating intelligence inside the software are the
critical objective of AI
There are many application software applications such as web-based, wireless, desktop,
financial, enterprise, logistics, retail, energy, governmental, healthcare and other business
software applications. Business software represents the discrete systems such as
enterprise resource planning (ERP), supply chain management (SCM), customer
relationship management (CRM), inventory, knowledge, and content management. Most
of the business software are data intensive and data-processing applications.
AVCCE, Dept. of MCA III Semester 2
-
8/8/2019 OOAD Final
3/124
CA 5202 Object Oriented Analysis and Design
Similarly there are promising methods, technologies, strategies, tools, infrastructures, and
resources. Thus an appropriate software development process model has to be strictly
chosen based on the nature of the final software system to be built. In this chapter, we are
to see the well-known development process models.
2. Development Process Models
2.1 The Linear Sequential Developmental Model for software engineering is called the
classic life cycle or the waterfall model. This model suggests a systematic, sequential
approach to software development that begins at the system level and progresses through
analysis, design, coding, testing and maintenance. Modeled after the conventional
engineering cycle, the linear sequential model encompasses the following activities:
System / Information engineering and modeling Because software is always
part of a larger system, work begins by establishing requirements for all system
elements and then allocating some subset of these requirements to software. This
system view is essential when software must interface with other elements such as
hardware, people, and databases. System engineering and analysis encompasses
requirements gathering at the system level with a small amount of top-level
analysis and design. Information engineering encompasses requirements gathering
at the strategic business level and at the business area level.
Software requirement analysis The requirements gathering process is
intensified and focused specifically on software. To understand the nature of the
programs to be built, the software engineer (analyst) must understand the
information domain for the software as well as required function, behavior,
performance, and interfacing. Requirements for both the system and the software
are documented and reviewed with the customer.
Design The design process translates software requirements into a representation
of the software that can be assessed for quality before code generation begins. Like
requirements, the design is documented and becomes part of the software
configuration.
Code generation The design must be translated into a machine readable form.
Testing Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, assuring that all statements
AVCCE, Dept. of MCA III Semester 3
-
8/8/2019 OOAD Final
4/124
CA 5202 Object Oriented Analysis and Design
have been tested and on the functional externals that is, conducting tests to
uncover errors and ensure that defined input will produce actual results that agree
with required results.
Maintenance Software will undoubtedly undergo change after it is delivered to
the customer.
The Prototyping Model The prototyping paradigm begins with requirements gathering.
Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
A quick design then occurs. The quick design focuses on a representation of those aspects
of the software that will be visible to the customer / user. The quick design leads to the
construction of a prototype. The prototype is evaluated by the customer / user and is used
to refine requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, at the same time enabling the developer to
better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a
working prototype is built, the developer attempts to make use of existing program
fragments or applies that enable working programs to be generated quickly. Prototyping is
an effective paradigm for software engineering.
Rapid Application Development (RAD) model is a linear sequential software
development process model that emphasizes an extremely short development cycle. The
RAD model is a high-speed adaptation of the linear sequential model in which rapid
development is achieved by using a component-based construction approach. If
requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a fully functional system within very short time
periods. The RAD approach encompasses the following phases:
Business modeling The information flow among business functions is modeled
in a way that answers the following questions: what information drives the
business process? What information is generated? Who generates its? Where does
the information go? Who processes it?
Data modeling the information flow defined as part of the business modeling
phase is refined into a set of data objects that are needed to support the business.
AVCCE, Dept. of MCA III Semester 4
-
8/8/2019 OOAD Final
5/124
CA 5202 Object Oriented Analysis and Design
The characteristics (attributes) of each object are identified and the relationships
between these objects are defined.
Process modeling the data objects defined in the data modeling phase are
transformed to achieve the information flow necessary to implement a business
function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object
Application generation RAD uses the fourth generation techniques to create
software.
Testing and turnover Since the RAD process emphasizes reuse, many of the
program components have already been testing.
2.2 Evolutionary Software Process Models There is growing recognition that software,
like all complex systems, evolves over a period of time. Thus a few interesting
evolutionary models have emerged. Below a brief of each is supplied.
The Incremental model combines elements of the linear sequential model with the
iterative philosophy of prototyping. Each linear sequence produces a deliverable increment
of the software. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production
functions in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. Thus when an
incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features remain undelivered. The
core product might be used by the customer or be subjected for detailed review. As a result
of use and / or evaluation, a plan is being developed for the next increment. The planaddresses the modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality. This process gets repeated following
the delivery of each increment, until the complete product is produced. The iterative
process, like prototyping and other evolutionary approaches, is iterative in nature.
The Spiral Model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential
model. In this spiral model, software is developed in a series of incremental releases.
AVCCE, Dept. of MCA III Semester 5
-
8/8/2019 OOAD Final
6/124
CA 5202 Object Oriented Analysis and Design
During early iterations, increasingly more complete versions of the engineered system are
produced. The spiral model is divided into a number of task regions.
1. customer communication tasks required to establish effective communication
between developer and customer
2. planning tasks required to define resources, timelines, and other project related
information
3. risk analysis tasks required to assess both technical and management risks
4. engineering tasks required to build one or more representations of the application
5. construction & release tasks required to construct, test, install and provide user
support
6. customer evaluation tasks required to obtain customer feedback based on
evaluation of the software representations created during the engineering stage and
implemented during the installation stage
Each of the six regions is populated by a series of subtasks that are adapted according to
the characteristics of the project to be undertaken. The spiral model is a realistic approach
to the development of large scale systems and software.
Thus far, we have seen both old and new process models for generic software engineering.
Sometimes the process is being termed as software development life cycle (SDLC). There
are several techniques for simplifying each phase of this development process. Traditional
approaches such as functional / procedure oriented and structured methods (Structured
analysis, design and implementation) C is the primary structured programming language.
In the recent past, OO paradigm (OO analysis, design, programming, and testing) have
emerged in the software market. Due to its soaring popularity and acceptance among the
professionals as well as the customers, it has become the dominant paradigm as far as the
task of engineering software for various personal, business as well as system domains.
Equally OO paradigm is being strengthened and supported by the grand arrival of a host of
OO programming languages such as C++, Java, C#, VB.NET etc.
3. Object-Oriented Systems Development
We live in a world of objects. These objects exist in nature, in man-made entities, in
business and in the products we use everyday. They can be differentiated, categorized,
described, organized, combined, manipulated and created. Thus while forming software
AVCCE, Dept. of MCA III Semester 6
-
8/8/2019 OOAD Final
7/124
CA 5202 Object Oriented Analysis and Design
abstractions for the real-world problems, it is logical, prudent and natural to think of
software solutions as an interacting, collaborating, and coexisting software objects. This
concept induced many to come out with an increasing array of OO technologies, methods,
models, and approaches. The interesting aspect of OO method includes realizing ofreusability. This reuse of program components leads to faster software development of
bug-free, quality-conscious, reusable, scalable, secure and flexible software applications.
Also OO software is easy to conceptualize, develop, deploy, manage, handle, use, and
maintain for analysts, architects, developers, administrators, and end users.
Building High-Quality Software - The software process transforms the users needs via
the application domain to a formidable software service / solution / product that satisfies
that sincerely satisfies those needs. Once the software is build, it is mandatory to check
whether the built software is free of errors, bugs, risks, dangers, defects and infirmities
besides it accomplishes all the core requirements, intentions and expectations of the users.
Thus customer satisfaction and delight is the main and focused target for software services
and solutions providers. There are two basic approaches for testing software systems. That
is, we can test a system according to how it has been built or what it should do. There are
four quality measures for evaluating a system: correspondence, correctness, verification,
and validation. Correspondence measures how well the delivered system matches theneeds of the operational environment, as described in the original requirements statement.
Validation is the task of predicting correspondence. True correspondence cannot be
determined until the system is fully built. Correctness measures the consistency of the
product requirements with respect to the design specification. Verification is the exercise
of determining correctness.
Correctness always is objective. That is, given a specification and a product, it should be
possible to determine if the product precisely satisfies the requirements of thespecification. Validation is always subjective. That is, it checks the appropriateness of the
specification itself. In hindsight, verification checks whether we build the product right
whereas the validation evaluates whether we build the right product. Validation begins as
soon as the project starts, but verification can begin only after a specification has been
accepted. Thus realizing high-quality software is ensured through these checks. OO
system development technologies, methodologies, strategies, tools, infrastructures and
resources are guaranteeing high-quality software. In the following, we are to discuss in
detail all about the OO software development.
AVCCE, Dept. of MCA III Semester 7
-
8/8/2019 OOAD Final
8/124
-
8/8/2019 OOAD Final
9/124
CA 5202 Object Oriented Analysis and Design
estimating risks, identifying the relevant classes, and establishing the plausible
relationships between the objects of those classes are some of the important activities of
the OO analysis phase.
3.2 The goal ofObject-Oriented Design (OOD)phase is to design the classes identified
during the earlier phase and the user interface. Identifying and defining additional objects
and classes that support implementation of the requirements are the other important tasks
in this very crucial and critical phase. If the design is right, the product or the system to be
built would be right. During interface design, there will be a need for thinking about
incorporating additional objects. The activities of the design phase are summarized as
follows
Design and refine classes
Design and refine attributes
Design and refine methods
Design and refine structures
Design and refine associations
Thus designing and refining the class and object structures, components and theircollaborations are the leading activities of the design phase.
In the picture drawn using IBM Rational tool, there are two classes (Shape and Controller)
and two subclasses (Rectangle and Circle) of Shape class. Each class has its own attributes
and methods as indicated in the class diagram.
AVCCE, Dept. of MCA III Semester 9
-
8/8/2019 OOAD Final
10/124
CA 5202 Object Oriented Analysis and Design
3.3 Prototyping It is gaining momentum to construct a prototype of the some of the key
system components before embarking on full-fledged system development. As often told
that a picture is worth a thousand words, a prototype is worth a thousand pictures. A
prototype is a version of a software product developed in the early stages of the products
life cycle for specific, experimental purposes. A prototype enables to fully understand how
easy or difficult to implement certain aspects in the final commercial version. Also we can
understand what novel features need to be added or what sorts of risks are involved in
system development. A prototype is to tell an overall view of the system under
development. A prototype would clearly tell what sort of changes the developer has to
make, what sort of software toolkits, languages, and technologies need to be used etc.
Thus the benefits accrued out of prototyping are manifold including rescuing the project
from going down. The navigability, usability, and usefulness of user interfaces can be
enhanced with this prototyping. There are many commonly accepted prototypes as
follows.
1. A horizontal prototype is a simulation of the interface. In other words, it has the
entire user interface ready but contains no functionality.
2. A vertical prototype is a subset of the system features with complete functionality.
The advantage with this is that it is possible to thoroughly check the few
implemented functionality
3. An analysis prototype is an aid for exploring the problem domain. This class of
prototypes is used to inform the user and demonstrate the proof of a concept.
AVCCE, Dept. of MCA III Semester 10
-
8/8/2019 OOAD Final
11/124
CA 5202 Object Oriented Analysis and Design
4. A domain prototype is an aid for the incremental development of the ultimate
software solution. It is often is used as an effective tool for the staged delivery of
subsystems to the users or other members of the development team. It
demonstrates the feasibility of the implementation and eventually will evolve intoa deliverable product.
Thus prototyping is turning out to be a useful exercise at almost any stage of the
development.
3.4 Component-based Development (CBD) Manufacturers are adept in reusing and
assembling various prefabricated components for custom development. In the similar way,
software systems are being custom built easily, and quickly using a set of already
developed, tested, verified, validated, and deployed software components. There are
computer-aided software engineering (CASE) tools that helps to develop information
systems rapidly and seamlessly. The main goal of CASE technology is the automation of
the entire information systems development life cycle process using a set of integrated
software tools, such as requirements gathering, storing, analyzing, modeling, designing,
debugging and automatic code generation. There are integrated development environments
(IDEs), compilers, editors, toolkits and other simplifying solutions that facilitate the
software development team immensely in satisfying the modern requirements of
accomplishing more with less (time, resources, investment, etc.).
Legacy applications coded using old technologies such as COBOL are made interoperable
with the modern applications using concepts such as wrapper, helper software suite etc.
Thus off-the-shelf components, wrappers, classes and other software modules are
encouraging the component-based development. The software components are the
functional units of a program and building blocks for offering a collection of core,
customized, and personalized services. Thus CBD is emerging as the hot cake for the
developers to develop next-generation software applications using the time-tested, quality-
conscious, refined, and highly reusable software components.
3.5 Rapid Application Development (RAD) is a set of software tools such as Delphi,
Visual Basic, VisualAge, or PowerBuilder and viable techniques that can be used to build
an application faster than typically possible with traditional methods. RAD is often
associated with development of software in quick time. The main objective of RAD is to
build a version of an application quickly to see whether the architects have understood the
AVCCE, Dept. of MCA III Semester 11
-
8/8/2019 OOAD Final
12/124
CA 5202 Object Oriented Analysis and Design
system requirements correctly and the developers are moving in the right direction.
Further it determines whether the system does what it is expected to do. Thus RAD is an
interesting move in order to visualize what is to come and if there is any deviation, it can
be corrected in time.
3.6 Incremental testing In the olden days, after fully completing the system or product
only, the testing team will come into picture. This will waste a lot of time and dollars and
hence in order to reduce the project completion time, testing is introduced at the earlier
stage. That is, when a small building block (a testable class or software module), it is sent
to testing department for thorough and comprehensive testing.
In summary, in the initial sections, we have discussed generic software development
process models, and subsequently we have concentrated on OO software development life
cycle (OO SDLC) as it is an accepted fact that OO paradigm is doing wonders for not only
producing object-oriented software but also for components and services that can be
accessed over the net (Intranet, the Internet and extranet).
AVCCE, Dept. of MCA III Semester 12
-
8/8/2019 OOAD Final
13/124
CA 5202 Object Oriented Analysis and Design
UNIT - II
4. Object-Oriented Methodologies (OOM)
There are too many OO methodologies proposed by many and the top three are from
Booch, Rumbaugh, and Jacobson. In this chapter, we are to study each of these leading
OOM and at the end; we derive the unified approach by composing the best methods,
concepts, diagrams, and initiatives. The key concepts in Object-Oriented Programming are
these:
Classes - A class is the definition of the behavior and properties of one or more objects
within a system. A class binds the data (attributes) of an object to the behavior
(operations) that it can perform.
Attributes - An attribute is a data value or state that describes an object and helps to tell
one object from another of the same class. In some OO languages, these data values are
called properties or member variables or member data; but in UML, the proper term is
attributes.
Operations - An operation is a behavior or function that an object can perform.
Depending on the OO language, these might be called methods or member functions or
even messages. All objects communicated by sending messages to each other.
Objects - An object is an instance or specific example of a class. If Dog is the class, then
Betsy, Ladi, Patches, Jake, Radar, and Frosty are specific instances of the class found in a
house. The attributes of the class have specific values within an object of that class; and
the operations of a class operate on the attributes of individual objects.
Inheritance - This concept indicates that one class (the superclass) provides some
common or general behavior inherited by one or more specific classes (the subclasses).
The subclasses then provide more or different behavior beyond that defined in the
superclass. For example, besides the Dogs, I have Cat objects and Horse objects. Each
class has unique behaviors: Dogs must be walked, Cats use the litter box, and Horses drop
manure that must be scooped up and thrown in the manure pile. Yet all classes have some
AVCCE, Dept. of MCA III Semester 13
-
8/8/2019 OOAD Final
14/124
CA 5202 Object Oriented Analysis and Design
common behavior: they must be fed, and they must have vet visits. So I can define a
superclass, Pet, and have my subclasses, Dog, Cat, and Horse, derive their shared behavior
from the Pet class. In UML, this concept is known under the slightly different term of
generalization, in which a superclass provides the generalized behavior of the subclasses.
Components - A component is a collection of related classes that together provide a larger
set of services. Components in our system might include applications, libraries, ActiveX
controls, JavaBeans, daemons, and services. In the .NET environment, most of the projects
will require component development.
Interfaces - An interface is a definition of a set of services provided by a component or by
a class. This allows further encapsulation: the author of a component can publish just the
interfaces to the component, completely hiding any implementation details.
Object-Oriented Methodology (OOM) is a set of proven methods, models, and rules for
developing systems. Modeling is the process of describing an existing or proposed system.
A model is an abstraction of a phenomenon for the purpose of understanding it. Since a
model excludes unnecessary details, it is easier to manipulate than the real object.
Modeling provides a means for communicating ideas in an easy to understand and
unambiguous form while also accommodating a system complexity.
To get a feel for object-oriented methodologies, in this section, we are to see look at some
of the methods
1. The Booch Method
2. Sally Shlaer and Steve Mellor have created the concept of the recursive design
approach
3. Beck and Cunningham produced class-responsibility-collaboration (CRC) cards
4. Wirfs-Brock, Wilkerson, and Wiener came up with responsibility-driven design
5. Jim Rumbaugh led a team at the research labs of General Electric to develop the
object modeling technique (OMT)
6. Peter Coad and Ed Yourdon developed the Coad lightweight and prototype-
oriented approach to methods
AVCCE, Dept. of MCA III Semester 14
-
8/8/2019 OOAD Final
15/124
CA 5202 Object Oriented Analysis and Design
7. Ivar Jacobson introduced the concept of the use case and object-oriented software
engineering
Many methodologies are available for system development. Each methodology is based on
modeling the business problem and implementing the application in an object-oriented
fashion. These methodologies and many other forms of notational language have provided
system designers and architects many choices but created a very confusing environment.
Most of the methods were very similar but contained a number of often annoying minor
differences. The differences lie primarily in the documentation of information and
modeling notations and language.
1. Rumbaugh et al.s object modeling technique (OMT)
The OMT describes a method for the analysis, design, and implementation of a system
using an object-oriented technique. MT is a fast, intuitive approach for identifying and
modeling all the objects making up a system. OMT separates modeling into three different
parts as described below.
Object model describes the structure of objects in a system: their identity,
relationships to other objects, attributes, and operations. The object model is
graphically represented with an object diagram that contains classes interconnected
by association lines. Each class represents a set of individual objects. The
association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to the objects of another
class.
Dynamic model OMT provides a detailed and comprehensive dynamic model,
in addition to letting to depict states, transitions, events and actions. The OMT
state transition diagram is a network of states and events. Each state receives oneor more events, at which time it makes the transition to the next state. The next
state depends on the current state as well as the events
Functional model The OMT data flow diagram (DFD) shows the flow of data
between different processes in a business. An OMT DFD provides a simple and
intuitive method for describing business processes without focusing on the details
of computer systems. Data flow diagrams use four primary symbols:
AVCCE, Dept. of MCA III Semester 15
-
8/8/2019 OOAD Final
16/124
CA 5202 Object Oriented Analysis and Design
1. The process is any function being performed; for example, verify Password
or PIN in the ATM system
2. The data flow shows the direction of data element movement; for example,
PIN code
3. The data store is a location where data are stored; for example, account is a
data store in the ATM example
4. An external entity is a source or destination of a data element; for example,
the ATM card reader.
OMT consists of four phases, which can be performed iteratively:
1. Analysis The results are object, dynamic, and functional models
2. System Design The results are a structure of the basic architecture of the system
along with high-level strategy decisions
3. Object Design This phase produces a design document, consisting of detailed
objects static, dynamic and functional models
4. Implementation This activity produces reusable, workable and robust source
code
2. The Booch Methodology
Booch define methodology consists of a lot symbols to document almost every design
decision. The Booch method consists of the following diagrams
1. Class Diagrams
2. Object Diagrams
3. State Transition Diagrams
4. Module Diagrams
5. Process Diagrams
6. Interaction Diagrams
This methodology prescribes a macro development process and a micro development
process.
AVCCE, Dept. of MCA III Semester 16
-
8/8/2019 OOAD Final
17/124
CA 5202 Object Oriented Analysis and Design
The macro process serves as a controlling framework for the micro process. The primary
concern of the macro process is technical management of the system. Such management is
interested less in the actual OO design and instead focus on how well the project
corresponds to the requirements set for it and whether it is produced on time.
The macro development process consists of the following steps:
1. Conceptualization During this step, we establish the core requirements of the
system. Also we need to establish a set of goals and develop a prototype to prove
the concept.
2. Analysis and development of the model We can use the class diagram to describethe roles and responsibilities objects are to carry out in performing the desired
behavior of the system. We can use object diagram or the interaction diagrams to
describe the behavior of the system.
3. Design or create the system architecture In this phase, we can use the class
diagram to decide what classes exist and how they relate to each other. Next, we
can use the object diagram to decide what mechanisms are used to regulate how
objects collaborate. Then we can use the module diagram to map out where eachclass and object should be declared. Finally, we can use the process diagram to
determine to which processor to allocate a process. Also this step determines the
schedules for multiple processes on each relevant processor.
4. Evolution or Implementation Successively refine the system through many
iterations. Produce a stream of software implementations, each of which is a
refinement of the prior one.
5. Maintenance Make a localized changes to the system to add new requirements
and eliminate bugs
The Micro Development process Each macro development process has its own micro
development process, which has the following steps.
1. Identify classes and objects
2. Identify class and object semantics
3. Identify class and object relationship
AVCCE, Dept. of MCA III Semester 17
-
8/8/2019 OOAD Final
18/124
CA 5202 Object Oriented Analysis and Design
4. Identify class and object interfaces and implementation
3. Jacobson Methodology
The Jacobson et al. Methodologies (object-oriented business engineering (OOBE),
object-oriented software engineering (OOSE), referred to as Objectory) cover the entire
lifecycle and stress traceability between the different phases, both forward and backward.
This traceability enables reuse of analysis and design work in the reduction of
development time. At the heart of this OOM is the use case concept.
Use cases are scenarios for understanding system requirements. A use case is an
interaction between users and a system. The use case model captures the goal of the user
and the responsibility of the system to its users. The use cases are described as text, easy to
read with a clear flow of events to follow. The use case description must contain
How and when the use case begins and ends
The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged
How and when the use case will need data stored in the system or will store data in
the system
Exceptions to the flow of events
How and when concepts of the problem domain are handled
Every single use case should describe one main flow of events. An exceptional or
additional flow of events could be added. The exceptional use case extends another use
case to include the additional one. The use case model employs extends and uses
relationships. The extends relationship is used when we have one use case that is similar
to another use case but does a bit more. That is, it extends the functionality of the original
use case like a subclass. The uses relationship reuses common behavior in different use
cases.
Use cases could be viewed as concrete or abstract. An abstract use case is not complete
and has no actors that initiate it but is used by another use case. Abstract use cases also are
the ones that have uses or extends relationships.
OOSE, also called Objectory is a method of OO development with the specific aim to fit
the development of large, real-time systems. The development process, called use-case
AVCCE, Dept. of MCA III Semester 18
-
8/8/2019 OOAD Final
19/124
CA 5202 Object Oriented Analysis and Design
driven development, stresses that use cases are involved in several phases of the
development including analysis, design, validation and testing. The use case scenario
begins with a user of the system initiating a sequence of interrelated events. The highlight
of this methodology is that by organizing the analysis and design models aroundsequences that are both more usable and more robust, adapting more easily to changing
usage.
Objectory is built around several different models:
The use-case model defines the outside (actors) and inside (use case) of the system
behavior
Domain object model The objects of the real-world are mapped into the domain
object model
The analysis object model presents how the source code (implementation) should
be carried out and written
The Implementation model represents the implementation of the system
The test model constitutes the test plans, specifications and reports
Object-oriented Business engineering (OOBE) is object modeling at the enterpriselevel. Use cases are again the central vehicle for modeling.
The analysis phase defines the system to be built in terms of the problem-domain object
model, the requirements model, and the analysis model. The analysis phase should not
take into account the actual implementation environment parameters. This sort of analysis
helps to reduce complexity and promotes maintainability over the life of the system since
the description of the system will be independent of hardware and software requirements.
That is, this model should be developed just enough to form a base of understanding for
the requirements model. The analysis process is iterative but requirements and analysis
models should be stable before moving on to subsequent models
Design and Implementation Phases The implementation environment must be
identified for the design model. This includes factors such as DBMS, distribution of
process, and constraints due to programming language, available component libraries, and
incorporation of GUI tools etc. The analysis objects are translated into design objects that
fit the current implementation environment
AVCCE, Dept. of MCA III Semester 19
-
8/8/2019 OOAD Final
20/124
CA 5202 Object Oriented Analysis and Design
Testing phase There are many testing types unit testing, integration testing, system
testing etc.
4. Design Patterns An Overview
Patterns for Software Development - An emerging idea in systems development is that
the process can be improved significantly if a system can be analyzed, designed, and built
from prefabricated and predefined system components. There are commonly encountered
and difficult problems that are recurring and repetitive and hence a need arises for a
standard vocabulary for communicating insight and experience about these problems and
their solutions. This enforces the view of having a body of literature consisting of both the
identified problems and solutions to help software analysts, architects, and developers.
Thus the focus here is on inculcating the culture of document creation in order to support
sound engineering architecture, design, best practices, guidelines etc. as the documentation
immensely helps to categorize and communicate about solutions to recurring problems.
The pattern has a name to facilitate discussion, and the information it represents. The
documentation of a pattern, in essence, provides the contexts under which it is suitable and
the constraints and forces that may affect a solution or its consequences.
Communication about patterns is enabled by a vocabulary that describes the pattern and its
related components such as name, context, motivation, and solution. By classifying these
components and their nature such as the structural or behavioral nature of the solution, we
can categorize patterns. The concept of patterns and their documentation is becoming
popular among the software professionals. They are being extensively used for shortening
the development time and to enhance the quality of software solutions. The OO thinkers
have come out with the roles of design patterns. They could identify the key aspects of a
common design structure that make it useful for creating a reusable OO design. Further
more, design patterns identify the participating classes and instances, their roles, and
collaborations and the distribution of responsibilities. Patterns also describe whet they can
be applied, whether they can be applied in view of other design constraints, and the
consequences and trade-offs of their use.
Patterns and pattern languages should be able to generate whole, living structures. Part of
the desire to create architectures emulating life lies in the unique ability of living things to
evolve and adapt to their ever-changing environments. Similarly, a good software
architecture is about being adaptable and resilient to change. The successive application of
AVCCE, Dept. of MCA III Semester 20
-
8/8/2019 OOAD Final
21/124
CA 5202 Object Oriented Analysis and Design
several patterns, each encapsulating its own problem and forces, unfolds a larger solution,
which emerges indirectly as a result of the smaller solutions.
Pattern Types - A pattern in waiting, which is not yet known to recur, is called a proto-
pattern. Generative patterns are patterns that not only describe a recurring problem, they
can tell us how to generate something and can be observed in the recurring system
architectures they helped shape. Non-generative patterns are static and passive. They
describe recurring phenomena without necessarily saying how to reproduce them. We
have to document generative patterns due to their significant contributions for efficient
software development.
Pattern Application Domains - Patterns are being largely used for software architecture
and design and more recently, for all aspects of software engineering, including
development organization, the software development process, project planning,
requirements engineering, and software configuration management. A good pattern will
do the following:
It solves a problem. Patterns capture solutions, not just abstract principles or
strategies
It is a proven concept. Patterns capture solutions with a track record, not theoriesor speculation
The solution is not obvious. The best patterns generate a solution to a problem
indirectly
It describes a relationship. Patterns do not just describe modules, but describe
deeper system structures and mechanisms
The pattern has a significant human component. All software serves human
comfort or quality of life; the best patterns explicitly appeal to aesthetics and
utility.
A good pattern description should fully encapsulate all the forces that have an
impact on it
AVCCE, Dept. of MCA III Semester 21
-
8/8/2019 OOAD Final
22/124
CA 5202 Object Oriented Analysis and Design
Pattern Templates - Each pattern must be expressed in the form of a rule (template),
which establishes a relationship between a context, a system of forces which arises
in that context, and a configuration, which allows these forces to resolve themselves
in that context. A pattern should contain certain essential components:
1. Name Every pattern should contain a meaningful name, which may be a single
word or short phrase to refer to the pattern and the knowledge and structure it
describes.
2. Problem A statement of the problem that describes its intent: the goals and
objectives it wants to reach within the given context and forces.
3. Context The preconditions under which the problem and its solution seem to
recur and for which the solution is desirable. It can be thought of as the initial
configuration of the system before the pattern is applied to it.
4. Forces A description of the relevant forces and constraints and how they interact
or conflict with one another and with the goals we wish to achieve. Forces reveal
the intricacies of a problem and define the kinds of trade-offs that must be
considered in the presence of the tension or dissonance they create.
5. Solution Static relationships and dynamic rules describe how to realize thedesired outcome. This often is equivalent to giving instructions that describe how
to construct the necessary products. The description may encompass pictures,
diagrams, and prose that identify the patterns structure, its participants, and their
collaborations, to show how the problem is solved. The solution should describe
not only the static structure but also the dynamic behavior. The static structure tells
us the form and organization of the pattern but the behavioral dynamics is what
makes the pattern come alive.
6. Examples One or more sample applications of the pattern that illustrate a specific
initial context; how the pattern is applied to and transforms that context and the
resulting context left in its wake. Examples help the reader to understand the
patterns use and applicability. Visual examples and analogies often can be very
useful.
7. Resulting Context The state or configuration of the system after the pattern is
applied, including the consequences (both bad and good) of applying the pattern,
AVCCE, Dept. of MCA III Semester 22
-
8/8/2019 OOAD Final
23/124
CA 5202 Object Oriented Analysis and Design
and other problems and patterns that may arise from the new context. It describes
the post conditions and side effects of the pattern. This is sometimes called a
resolution of forces because it describes which forces have been resolved, which
ones remain unsolved, and which patterns may now be applicable. Documentingthe resulting context produced by one pattern helps to correlate it with the initial
context of other patters.
8. Rationale A justifying explanation of steps or rules in the pattern and also of the
pattern as a whole in terms of how and why it resolves its forces in a particular
way to be in alignment with desired goals, principles and philosophies. It explains
how the forces and constraints are orchestrated in concert to achieve a resonant
harmony. That is, how the pattern actually works, why it works, and why it is good
9. Related patterns share the common forces. They also have an initial or resulting
context that is compatible with the resulting or initial context of another pattern.
Such patterns might be predecessor patterns whose application leads to this pattern,
successor patterns whose application follows from this pattern, alternative patterns
that describe a different solution to the same problem but under different forces
and constraints, and codependent patterns that may be applied simultaneously with
this pattern.
10. Known Uses The known occurrences and its applications within existing systems
need to be documented. This helps validate a pattern by verifying that it indeed is a
proven solution to a recurring problem.
Antipatterns A pattern represents a best practice whereas an antipattern represents
worst practice or a lesson learned. Antipatterns come in two varieties:
Those describing a bad solution to a problem that resulted in a badsituation
Those describing how to get out of a bad situation and how to proceed
from there to a good solution
Antipatterns are valuable as it helps to understand good solutions by seeing and
understanding bad solutions.
Capturing Patterns A pattern should help its users to comprehend existing systems,
customize systems to fit user needs, and construct new systems. The process of looking for
AVCCE, Dept. of MCA III Semester 23
-
8/8/2019 OOAD Final
24/124
CA 5202 Object Oriented Analysis and Design
patterns to document is called pattern mining. The following guidelines give what exactly
is a pattern.
Focus on practicality Patterns should describe proven solutions to recurring
problems
Aggressive disregard of originality Pattern writers do not need to be the original
inventor or discoverer of the solutions that they document
Nonanonymous review Pattern submissions are shepherded rather than reviewed.
The shepherd contacts the pattern authors and discusses with him or her how the
patterns might be clarified or improved on
Writers workshops instead of presentations Rather than being presented by the
individual authors, the patterns are discussed in writers workshops, open forums,
and mini conferences
Careful editing The pattern authors should have the opportunity to incorporate all
the comments and insights during the shepherding and writers workshops before
presenting the patterns in their finished form.
5. Frameworks
A framework is a set of cooperating classes that make up a reusable design for a specific
class of software. A framework provides architectural guidance by partitioning the design
into abstract classes and defining their responsibilities and collaborations. A developer
customizes a framework to a particular application by subclassing the composing instances
of framework classes. The framework captures the design decisions that are common to its
application domain. Frameworks thus emphasize design reuse over code reuse, though a
framework will usually include concrete subclasses we can put to work immediately. Thus
a framework is a way of presenting a generic solution to a problem that can be applied to
all levels in a development. Design and software frameworks are currently popular.
Why Frameworks? - Frameworks are a way of delivering application development
patterns to support best practice sharing during application development. The motivations
for frameworks are as follows. An experienced programmer almost never codes a new
program from scratch. He will use macros, copy libraries, and template-like code
fragments from earlier programs to make a short on a new one. Work on the new program
begins by filling in new domain-specific code inside the older structures
AVCCE, Dept. of MCA III Semester 24
-
8/8/2019 OOAD Final
25/124
CA 5202 Object Oriented Analysis and Design
A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new data model from scratch. Instead, he will make
use of model fragments that have been developed over time to help new modeling projects
hit the ground running.
Design Patterns Vs Frameworks - A single framework typically encompasses several
design patterns. In fact, a framework can be viewed as the implementation of a
system of design patterns. A framework is executable software, where design
patterns represent knowledge and experience about software. Frameworks are in a
way of a physical nature, while patterns are of a logical nature: Frameworks are the
physical realization of one or more software pattern solutions; patterns are the
instructions for how to implement those solutions
Design patterns are more abstract than frameworks Frameworks can be
embodied in code, but only examples of patterns can be embodied in code.
Frameworks are written using a programming language and reused directly. In
contrast, design patterns have to be implemented each time they are used. Design
patterns also explain the intent, trade-offs, and consequences of the design
Design patterns are smaller architectural elements than frameworks A typical
framework contains several design patterns but the reverse is never true
Design patterns are less specialized than frameworks Frameworks always have a
particular application domain. In contrast, design patterns can be used in nearly
any kind of application.
6. Unified Approach (UA)
This approach is based on the best practices that have proven successful in system
development and more specifically the work done by the stalwarts of OO paradigm. The
UA establishes a unifying and unitary framework around their works by utilizing the UML
to describe, model, and document the software development process. The main idea
behind this UA is to combine the best practices, processes, methodologies, and guidelines
along with UML notations and diagrams for better understanding OO concepts and
systems development. The UA revolves around the following processes
Use case driven development
Object-oriented analysis
AVCCE, Dept. of MCA III Semester 25
-
8/8/2019 OOAD Final
26/124
CA 5202 Object Oriented Analysis and Design
Object-oriented design
Incremental development and prototyping
Continuous testing
The methods and technology employed include
UML used for modeling
Layered approach for software development
Repository for OO system development containing best practices, patterns and
frameworks
Component-based development
The UA allows iterative development by allowing to go back and forth between the design
and modeling or analysis phases.
OOA Analysis is the process of extracting the needs of a system and what the system
must do to satisfy the user requirements. The goal is to understand the domain of the
problem and the systems responsibilities by understanding how the users or will use the
system. This is accomplishing by constructing several models of the system. The models
concentrate on describing what the system does rather than how it does it. Separating the
behavior of a system from the way it is implemented requires viewing the system from the
users perspective rather than that of the machine. OOA process consists of the following
steps:
1. Identify the Actors
2. Develop a simple business process model using UML Activity diagram
3. Develop the Use Case
4. Develop interaction diagrams
5. Identify classes
OOD The UA utilizes Jacobsons analysis and interaction diagrams, Boochs object
diagrams and Rumbaughs domain model. Further more, by following Jacobsons life
cycle model, we can produce designs that are traceable across requirements, analysis,
design, coding, and testing. OOD process consists of:
AVCCE, Dept. of MCA III Semester 26
-
8/8/2019 OOAD Final
27/124
CA 5202 Object Oriented Analysis and Design
1. Designing classes, their attributes, methods, associations, structures, and protocols,
apply design axioms
2. Design the access layer
3. Design and prototype user interface
4. User satisfaction and usability tests based on the usage / use cases
5. Iterate and refine the design
Iterative Development and Continuous Testing We must iterate and reiterate till we
are satisfied with the system. Since testing often uncovers design weaknesses, we need to
repeat the entire process, taking what we have learned and reworking our design or
moving on to reprototyping and retesting. During this iterative process, our prototypes will
be incrementally transformed into the actual application. The UA encourages the
integration of testing plans from day 1 of the project. Usage scenarios can be test scenarios
and use cases will drive the usability testing.
Unified Modeling Language (UML) The UML merges the best of the notations used
by the three most popular analysis and design methodologies. UML is becoming the
universal for modeling OO systems. It is to express models of many different kinds and
purposes just as a programming language is used in different ways. The UA uses the UML
to describe and model the analysis and design phases of systems development.
7. The Layered Approach to Software Development
Most systems being developed today are two-layered architecture: interface and data. The
three-layered approach consists of a view or user interface, a business layer and an access
layer. The business layer contains all the objects that represent the business (both data and
behavior). This is where, the real objects such as Order, customer, inventory and invoice
exist. The responsibilities of business layer are: model the objects of the business and how
they interact to accomplish the business processes. These objects should not be responsible
for the following:
1. Displaying details Business objects should have no special knowledge of how
they are being displayed and by whom. They are designed to be independent of
any particular interface so the details of how to display an object should exist in
the interface (view) layer of the object displaying it
AVCCE, Dept. of MCA III Semester 27
-
8/8/2019 OOAD Final
28/124
CA 5202 Object Oriented Analysis and Design
2. Data access details Business objects also should have no special knowledge of
data and its origin. It does not matter to the business model whether the data are
stored and retrieved via SQL or file I/O. The business objects need to know only to
whom to talk about being stored or retrieved.
A business model captures the static and dynamic relationships among a collection of
business objects. Static relationships include object associations and aggregations. For
example, a customer could have more than one account or an order could be aggregated
from one or more line items. Dynamic relationships show how the business objects
interact to perform tasks. For example, an order interacts with inventory to determine
product availability. An individual business object can appear in different business
models. Business models also incorporate control objects that direct their processes.
The user interface (View) layer The UI layer consists of objects with which the user
interacts as well as the objects needed to manage or control the interface.
1. Responding to user interaction The UI layer objects must be designed to
translate actions by the user, such as clicking on a button or selecting from a menu,
into an appropriate response. That response may be to open or close another
interface to send a message down into the business layer to start some business
process.
2. Displaying business objects - This layer must paint the best possible picture of the
business objects for the user. In one interface, this may mean entry fields and list
boxes to display an order and its items. In another, it may be a graph of the total
price of a customers orders.
The Access layer contains objects that know how to communicate with the place where
the data actually reside, whether it is a relational database, OODBMS. Regardless ofwhere the data actually reside, the objectives
1. Translate request this layer must be able to translate any data-related requests
from the business layer into the appropriate protocol for data access. For example,
if customer number 55552 needs to retrieved, the access layer must be able to
create the correct SQL statement and execute it
AVCCE, Dept. of MCA III Semester 28
-
8/8/2019 OOAD Final
29/124
CA 5202 Object Oriented Analysis and Design
2. Translate results This layer also must be able to translate the data retrieved back
into the appropriate business objects and pass those objects back up into the
business layer.
8. The UA Repository
In modern businesses, best practice sharing is a way to ensure that solutions to process and
organization problems in one part of the business are communicated to other parts where
similar problem occur. Best practice sharing eliminates duplication of problem solving.
For many companies, best practice sharing is institutionalized as part of their constant goal
of quality improvement. Best practice sharing must be applied to application development
if quality and productivity are to be added to component reuse benefits.
The idea promoted here is to create a repository that allows the maximum reuse of
previous experiences, knowledge gathered and previously defined specifications, objects,
principles, practices, processes, procedures, software modules, classes, components,
services, and applications in an easily accessible manner with a completely available and
easily utilized format. Everything from the original user request to maintenance of the
project as it goes to production should be kept in the repository. The advantages of
repositories are many. If we store software objects from our projects implementations for
our clients in the repository, they can be reused for forthcoming projects. Any thing such
as the definition of data element, diagrams symbols, definitions, etc can be stored in the
repository. Thus software development becomes easier, and quicker. If new requirements
emerge, new objects will be design and stored in the main repository for future use. The
repository will be made available and accessible for many. Also there are UML diagrams,
design patterns, frameworks, CASE tools, IDEs etc that also facilitate quicker software
development.
Unified Modeling Language (UML)
What is model? - A model is an abstract representation of a system, constructed to
understand the system prior to building or modifying it. A model is a simplified
representation of reality, which is too complex or large and much of the complexity
actually is irrelevant to the problem we are trying to describe or solve. A model provides a
means for conceptualization and communication of ideas in a precise and unambiguous
form. Thus modeling is to cope up with the increasing complexity of systems. Models
make it easier to express complex ideas. Model reduces the complexity and enhances and
AVCCE, Dept. of MCA III Semester 29
-
8/8/2019 OOAD Final
30/124
CA 5202 Object Oriented Analysis and Design
reinforces learning and training. Manipulation of the model is much easier than
manipulation of a real system.
Static & dynamic models
Why Models? - Models can represent static or dynamic models. A static model can be
viewed as a snapshot of a systems parameters at rest or at a specific point in time. Static
models are needed to represent the structural or static aspect of a system. For example, a
customer could have more than one account or an order could be aggregated from one or
more line items. Static models assume stability and an absence of change of data over
time. The class diagram is an example of a static model
A dynamic model can be viewed as a collection of procedures or behaviors that, taken
together, reflect the behavior of a system over time. Dynamic relationships show how the
business objects interact to perform tasks. For example, an order interacts with inventory
to determine product availability. Dynamic modeling is useful during design and
implementation phases of the system development. The interaction and activity diagrams
are dynamic models.
A modeling language must include
Model elements fundamental modeling concepts and semantics
Notation visual rendering of model elements
Guidelines expression of usage within the state
Due to the rise in complexity of present day systems, virtualization and modeling becomes
essential, as we cannot comprehend the total system. Visual notations bring us several
benefits relating to
Clarity We are much better at picking out errors, and omissions from a graphical or
visual representation than from listings of code or tables of numbers
Familiarity The representation form for the model may turn out to be similar to the way
in which the information actually is represented and used by the employees currently
working in the problem domain.
Maintenance Visual notation can improve the maintainability of a system. The visual
identification of locations to be changed and the visual confirmation of those changes will
reduce errors.
AVCCE, Dept. of MCA III Semester 30
-
8/8/2019 OOAD Final
31/124
CA 5202 Object Oriented Analysis and Design
Simplification Use of higher-level representation generally results in the use of fewer
but more general constructs contributing to simplicity and conceptual understanding
UML is a language for specifying, constructing, visualizing, and documenting the
software system and its components. The UML is a graphical language with sets of rules
and semantics. The rules and semantics are expressed in English in a form known as
object constrain language (OCL), which is a specification language that uses simple logic
for specifying the properties of a system. The primary goals in the design of the UML
were
1. Provide users a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models
2. Provide extensibility and specialization mechanisms to extend the core concepts
3. Be independent of particular programming language and development process
4. Provide a formal basis for understanding the modeling language
5. Encourage the growth of the OO tools market
6. Support high-level development concepts
7. Integrate best practices and methodologies
UML Diagrams
1. Class diagram
2. Use-case diagram
3. Behavior diagram
3.1 Interaction diagram
3.1.1 Sequence diagram
3.1.2 Collaboration diagram
3.2 State chart diagram
3.3 Activity diagram
4. Implementation diagram
4.1 Component diagram
AVCCE, Dept. of MCA III Semester 31
-
8/8/2019 OOAD Final
32/124
CA 5202 Object Oriented Analysis and Design
4.2 Deployment diagram
The UML class diagram, also referred to as object modeling, is the main static analysis
diagram. These diagrams show the static structure of the model. A class diagram is a
collection of static modeling elements such as classes and their relationships, connected as
a graph to each other and to their contents. Object modeling is the process by which the
logical objects in the real world (problem space) are represented (mapped) by the actual
objects in the program (logical world). The visual representation of the objects, their
relationships and their structures is for ease of understanding. It is essential to determine
all the objects required for the system. The main task of object modeling is to graphically
show what each object will do in the problem domain, describe the structure such as class
hierarchy and the relationships among objects by visual notation and determine what
behaviors fall within and outside the problem domain.
Use Case Diagram The functionality of a system is described in a number of different
use cases, each of which requires a specific flow of events in the system. A use case
corresponds to a sequence of transactions, in which each transaction is invoked from
outside the system (actors) and engages internal objects to interact with one another and
with the systems surroundings. The description of a use case defines what happens in the
system when the use case is performed. In essence, the use case model defines the outside
(actors) and inside (use cases) of the systems behavior. The use cases are initiated by
actors and describe the flow of events that these actors set off. An actor is anything that
interacts with a use case. An actor could be a human user, external hardware, or another
system. A use case diagram is a graph of actors, a set of use cases enclosed by a system
boundary, communication associations between the users and the use cases and
generalization among the use cases.
Dynamic Modeling
We need to understand both the structure and the function of the objects involved. We
must understand the taxonomic structure of class objects, the inheritance and mechanisms
used the individual behaviors of objects, and the dynamic behavior of the system as a
whole. Events happen dynamically in all systems. Objects are created, and destroyed.
Objects sends messages to one another in an orderly fashion and in some systems, external
events trigger operations on certain objects. Further more, objects have states and static
model fails to capture the state of an object. The state of an object is the result of its
AVCCE, Dept. of MCA III Semester 32
-
8/8/2019 OOAD Final
33/124
CA 5202 Object Oriented Analysis and Design
behavior. Each class may have an associated activity diagram that indicates the behavior
of the classs instance (its object).
UML Interaction diagrams describe how groups of objects collaborate to get the job done.
Interaction diagrams capture the behavior of a single use case, showing the pattern of
interaction among objects.
Sequence Diagram is an easy and intuitive way of describing the behavior of a system by
viewing the interaction between the system and its environment. A sequence diagram
shows an interaction arrange in a time sequence. It shows the objects participating in the
interaction by their lifelines and the messages they exchange, arranged in a time sequence.
A sequence diagram has two dimensions: the vertical dimension represents time, the
horizontal dimension represents the different objects. The vertical line is called the
objects lifeline that represents the objects existence during the interaction. Each message
is represented by an arrow between the lifelines of two objects. The order in which these
messages occur is shown top to bottom on the page. Each message is labeled with the
message name. A sequence diagram is an alternative way to understand the overall flow of
the control of a program.
UML Collaboration diagram This represents a collaboration, which is a set of objects
related in a particular context, and interaction, which is a set of messages exchanged
among the objects within the collaboration to achieve a desired outcome. In this diagram,
objects are shown as figures and arrows indicate the message sent within the given use
case. The sequence is indicated by numbering the messages. In this diagram, the layout
indicates how objects are statically connected.
The disadvantage of interaction diagrams is they are great only for representing a single
sequential process. They begin to break down when we want to represent conditionallooping behavior. However, there are ways to represent condition behavior in interaction
diagrams. The preferred method is to use separate diagrams for each scenario. Another
way is to use conditions on messages to indicate the behavior. Activity diagram is the best
option for capturing complex behavior. Thus interaction diagrams are for examining the
behavior of objects within a single use case.
UML State-chart diagram A state diagram shows the sequence of states that an object
goes through during its life in response to outside stimuli and messages. The state is theset of values that describes an object at a specific point in time and is represented by state
AVCCE, Dept. of MCA III Semester 33
-
8/8/2019 OOAD Final
34/124
CA 5202 Object Oriented Analysis and Design
symbols and the transitions are represented by arrows connecting the state symbols. A
state diagram may contain subdiagrams. A state diagram represents the state of the method
execution, that is, the state of the object executing the method. The activities in the
diagram represent the activities of the object that performs the method. The purpose of thestate diagram is to understand the algorithm involved in performing a method. The activity
symbol (a solid black dot) appears within a state symbol, it indicates the execution of an
operation.
A message is data passed from one object to another. A message is a name that will trigger
an operation associated with the target object. For example, an Employee object that
contains the name of an employee. If the employee object received a message
(getEmployeeName) asking for the name of the employee, an operation contained in the
Employee class would be invoked. That operation would check the attribute Employee
and then assign the value associated with that attribute back to the object that sent the
message in the first place. In this case, the state of the Employee object would not have
been changed. Now consider a situation where the same Employee object received a
message (updateEmployeeAddress). In this case, the object would invoke an operation
from its class that would modify the value associated with the attribute Employee,
changing it from the old address to the new address and hence the state of the employeeobject has been changed.
A state is represented as a rounded box, which may contain one or more compartments.
The name compartment holds the optional name of the state and the internal transition
compartment holds a list of internal actions or activities performed in response to events
received while the object is in the state, without changing states.
Two special events are entry and exist. The statechart supports nested state machines. The
transition can be simple or complex. A simple transition is a relationship between two
states indicating that an object in the first state will enter the second state and perform
certain actions when a specific event occurs. A complex transition may have multiple
source and target states. It represents a synchronization or a splitting of control into
concurrent threads.
There is no need to prepare a state diagram for each class in the system. State diagrams are
useful if there is a dynamic class. In that situation, it is helpful to prepare a state diagram
to be sure we understand each of the possible states an object of the class could take and
AVCCE, Dept. of MCA III Semester 34
-
8/8/2019 OOAD Final
35/124
CA 5202 Object Oriented Analysis and Design
what event (message) would trigger each transition from one state to another. In effect,
state diagrams emphasize the use of events and states to determine the overall activity of
the system
UML Activity Diagram is a variation or special case of a state machine, in which the
states are activities representing the performance of operations and the transitions are
triggered by the completion of the operation. Unlike state diagrams that focus on the
events occurring to a single object as it responds to messages, an activity diagram can be
used to model an entire business process. The purpose of an activity diagram is to provide
a view of flows and what is going on inside a use case or among several classes. Activity
diagram is also used to represent a classs method implementation.
An activity model is similar to state diagram, where a token (a black dot) represents an
operation. An activity is shown as a round box, containing the name of the operation.
When an operation symbol appears within an activity diagram, it indicates the execution
of the operation. An outgoing solid arrow attached to an activity symbol indicates a
transition triggered by the completion of the activity. Several transitions with different
conditions imply a branching off of control.
An activity diagram is mostly used to show the internal state of an object. Activity and
state diagrams express a decision when conditions are used to indicate possible transitions
that depend on Boolean conditions of container object.
Implementation Diagram shows the implementation phase of systems development, such
as the source code structure and the run-time implementation structure. There are two
types of implementation diagrams: Component diagrams show the structure of the code
itself and deployment diagrams show the structure of the runtime system.
Component diagrams model the physical components (such as source code, executablediagram, user interface) in a design. A package is a collection of classes, which are smaller
scale components. A package is being used to group logical components of the application
such as classes and not necessarily physical components. A component diagram is a graph
of the designs components connected by dependency relationships.
Deployment diagrams show the configuration of run-time processing elements and the
software components, processes, and objects that live in them. Software component
instances represent run-time manifestations of code units. In most cases, componentdiagrams are used in conjunction with deployment diagrams to show how physical
AVCCE, Dept. of MCA III Semester 35
-
8/8/2019 OOAD Final
36/124
CA 5202 Object Oriented Analysis and Design
modules of code distributed on various hardware platforms. A deployment diagram is a
graph of nodes connected by communication association. Nodes may contain component
instances, which mean that the component lives or runs at that node. Components may
contain objects; this indicates that the object is part of the component. Components areconnected to other components by dashed-arrow dependencies, usually through interfaces,
which indicate one component uses the services of another. Each node or processing
element in the system is represented by a three-dimensional box. Connections between the
nodes themselves are shown by solid lines.
Packages A package is a grouping of model elements. Packages themselves contain
other packages. The entire system can be thought of as a single high-level package with
everything else in it. All UML model elements and diagrams can be organized into
packages. A package is represented as a folder shown as a large rectangle with a tab
attached to its upper left corner. Hierarchical structure is there for packages with one
package is dependent on other packages. Packages can used to designate not only logical
and physical groupings but also use case groups. A use-case group is a package of use
cases.
UML Extensions
A note is a graphic symbol containing textual information and it also could contain
embedded images. A note is shown as a rectangle with a bent corner in the upper right
corner.
Stereotype represents a built-in extensibility mechanism of the UML. User-defined
extensions of the UML are enabled through the use of stereotypes and constraints. A
stereotype is a new class of modeling element introduced during modeling. It represents a
subclass of an existing modeling element with the same form but a different intent. UML
stereotypes extend and tailor the UML for a specific domain or process. The general
presentation of a stereotype is to use a figure for the base element but place a keyword
string above the name of the element. The stereotype allows extension of UML notation as
well as a graphic figure, texture, and color.
UML meta-model
The UML defines notations as well as a meta-model. UML graphic notations can be used
not only to describe the systems components but also to describe a model itself. This isknown as meta-model. That is, a meta-model is a model of modeling elements. The
AVCCE, Dept. of MCA III Semester 36
-
8/8/2019 OOAD Final
37/124
CA 5202 Object Oriented Analysis and Design
purpose of the UML meta-model is to provide a single common and definitive statement
of the syntax and semantics of the elements of the UML
The meta-model provides us a means to connect different UML diagrams. The connection
between the different diagrams is very important and the UML attempts to make these
couplings more explicit through defining the underlying model while imposing no
methodology.
UNIT - IV
Object-Oriented Design (OOD)
The main focus of the analysis phase of software development is on what needs to be
done. The objects discovered during analysis can serve as the framework for design. The
classs attributes, methods and associations identified during analysis must be designed for
implementation as a data type in the implementation language. New classes must be
introduced to store intermediate results during program execution. Emphasizes shifts from
the application domain to implementation and computer concepts such as user interfaces
and access layer.
During the analysis, we look at the physical entities or business objects in the system.
These objects represent tangible elements of the business. These objects could be
individuals, organizations, machines, or something that makes sense in the context of the
real-world system. During the design phase, we must elevate the model into actual objects
that can perform the required task
The OO Design Process consist of the following activities
1. Apply design axioms to design classes, their attributes, methods, associations,
structures, and protocols.
Refine and complete the static UML class diagram by adding details to
the UML class diagram. This step consists of the following
1. Refine attributes
2. Design methods and protocols by utilizing a UML activity
diagram to represent the methods algorithm
3. Refine associations between classes
AVCCE, Dept. of MCA III Semester 37
-
8/8/2019 OOAD Final
38/124
CA 5202 Object Oriented Analysis and Design
4. Refine class hierarchy and design with inheritance
2. Design the access layer
Create mirror classes For every business class identified and created,
create one access class.
Identify access layer class relationships
Simplify classes and their relationships
3. Design the view layer classes
Design the macro level user interface, identifying view layer objects
Design the micro level user interface, which includes these
activities
1. Design the view layer objects by applying the design axioms
and corollaries
2. Build a prototype of the view layer interface
4. Iterate and refine the whole design
Utilizing an incremental approach such as the UA, all stages of software development can
be accomplished incrementally. From the UML class diagram, we can begin to
extrapolate which classes we will have to build and which existing classes we can reuse.
OO Design Axioms
By definition, an axiom is a fundamental truth that always is observed to be valid
and for which there is no counterexample or exception. Axioms may be
hypothesized from a large number of observations by noting the common
phenomena shared by all cases. A theorem is a proposition that may not be self-
evident, but can be proven from accepted axioms. A corollary is a proposition that
follows from an axiom or another proposition that has been proven. Suhs OO
design axioms
1. The independence axiom
2. The information axiom
AVCCE, Dept. of MCA III Semester 38
-
8/8/2019 OOAD Final
39/124
CA 5202 Object Oriented Analysis and Design
Axiom 1 states that during the design process, as we go from requirement and use case to
a system component, each component must satisfy that requirement without affecting
other requirements. Axiom 2 is concerned with simplicity. That is, software components
should be with a minimum amount of complexity and maximum simplicity andstraightforwardness.
Corollaries From the above two design ax