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


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.


8/8/2019 OOAD Final

3/124


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


8/8/2019 OOAD Final

4/124


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.


8/8/2019 OOAD Final

5/124


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.


8/8/2019 OOAD Final

6/124


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


8/8/2019 OOAD Final

7/124


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.


8/8/2019 OOAD Final

8/124

8/8/2019 OOAD Final

9/124


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.


8/8/2019 OOAD Final

10/124


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.


8/8/2019 OOAD Final

11/124


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


8/8/2019 OOAD Final

12/124


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).


8/8/2019 OOAD Final

13/124


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


8/8/2019 OOAD Final

14/124


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


8/8/2019 OOAD Final

15/124


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:


8/8/2019 OOAD Final

16/124


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.


8/8/2019 OOAD Final

17/124


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


8/8/2019 OOAD Final

18/124


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


8/8/2019 OOAD Final

19/124


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


8/8/2019 OOAD Final

20/124


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


8/8/2019 OOAD Final

21/124


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


8/8/2019 OOAD Final

22/124


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,


8/8/2019 OOAD Final

23/124


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


8/8/2019 OOAD Final

24/124


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


8/8/2019 OOAD Final

25/124


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


8/8/2019 OOAD Final

26/124


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:


8/8/2019 OOAD Final

27/124


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


8/8/2019 OOAD Final

28/124


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


8/8/2019 OOAD Final

29/124


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


8/8/2019 OOAD Final

30/124


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.


8/8/2019 OOAD Final

31/124


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


8/8/2019 OOAD Final

32/124


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


8/8/2019 OOAD Final

33/124


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


8/8/2019 OOAD Final

34/124


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


8/8/2019 OOAD Final

35/124


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


8/8/2019 OOAD Final

36/124


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


8/8/2019 OOAD Final

37/124


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


8/8/2019 OOAD Final

38/124


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


8/8/2019 OOAD Final

39/124


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

ooad final

Documents