booch jacobson uml

8/8/2019 Booch Jacobson Uml

http://slidepdf.com/reader/full/booch-jacobson-uml 1/15

THE BOOCH OOD METHODOLOGY

The Booch methodology is a widely used object-oriented method that helps you design your system

using the object paradigm. It covers the analysis and design phases of an object-oriented system. It

concentrates on static model ; the dynamic model is constructed for a few object. It promotes on

object decomposition showing that at the design level object orientation can be used even if the

implementation language is not object oriented.

Booch sometimes is criticized for his large set of symbols. Only when you are ready to generate code,

you need to add design symbols.

The Booch OOD describes diagrams at two levels:

Design Level:

y Class diagrams ± shows existence of classes and their relationships in the logic design of the

system. It represents the class structure.

y Object diagrams - shows existence of objects and their relationships in the logic design of

the system. It represents the scenario.

y State transition diagrams - represents the state space of an instance of a given class.

y Interaction diagrams ± Used to trace the execution of a scenario in the same context as an object

diagram

Implementation Level:

y Module diagrams ± Shows the allocation of classes and objects to modules in the physical design of the

system. It represents the module architecture.

y Process diagrams - Shows the allocation of classes and processes to processors in the physical design

of the system. It represents the process architecture.

Notations

Important notations inClassdiagramand Objectdiagram

Class Icon AbstractClassIcon Object notation

Association has(aggregation)

Inheritance using (client-supplier relationship)



Fig 1: Object modeling using Booch notation .Arrows represent specialization. For eg:Class Taurus is subclass of theclass Ford.

Important notations in Interactiondiagram

Entity1 Entity2 Entity3

Message1

Message2

Message3

Important notations inState transitiondiagram

event/action

State name

actions



Fig 2: An alarm class state transition diagram with Booch notation. This diagram can capture the

state of a class based on a stimulus. For eg: , a stimulus causes the class to perform some

processing, followed by a transition to another state . In this case, the alarm silenced state can be

changed to alarm sounding state and vice versa.

Important notations inModule diagram

Name Name Name

MainProgram Subsystem

Specification Body

Important notations inProcessdiagram

name



Processor Device

Process1Process2

«««..

The Booch methodology prescribes a macro development process and a micro development process.

I. The Micro Development Process

Each macro development process has its own micro development processes. The stream of scenarios

and architectural products emerged and refined by the macro process largely drives the Micro

Development Process of object oriented development. The micro process is a description of the day-

to-day activities by a single or small group of software developers, which could look blurry to anoutside viewer, since the analysis and design phases are not clearly defined. It offers a framework for

evolving the architecture and exploring alternative designs.

The micro development process consists of the following steps:

1. Identify classes and objects:

Purpose-

y To establish the boundaries of the problem

y To devise an object oriented decomposition of the system under development.

y To discover the abstractions of the system.

Product ±

y Data dictionary, which acts as the central repository for the abstractions of the system and

establishes a common vocabulary throughout the project.

Activities ±

y Apply classical approach to OOA to generate a set of candidate classes and objects.

y Apply the techniques of behavior analysis to identify abstractions that are directly related to

the system function points.

y From the scenarios of macro process , apply techniques of use case analysis.

2. Identify class and object semantics:

Purpose-

y To establish the behavior and attributes of each abstraction identified in the previous phase

y To allocate the responsibilities for different system behaviors.

Products ±

y R efinement of data dictionary to attach responsibilities.



y S pecification for each abstraction to state the named operations that form protocol of each

class

y Object diagrams and Interaction diagram to capture the semantics of the scenarios that

derive from the macroprocess.

Activities ±

y Storyboarding ± R epresents a top ± down identification of semantics and addresses strategicissues

y Isolated class design - R epresents a bottom ± up identification of semantics

y Pattern Scavenging ± R ecognizes the importance of commonality and represents

opportunities for reuse

3. Identify class and object relationships:

Purpose-

y To solidify boundaries of and to recognize the collaborators with each abstraction.

y To specify associations among classes (including aggregation and inheritance)

Products ±

y Class diagram

y Object diagram

y Module diagram

Activities ±

y S pecification of associations

y Identification of various collaborations (dynamic semantics)

y R efinement of associations

4. Identify class and object interfaces and implementation:

Purpose-

y To create representations of abstractions in tangible forms

y Avoids premature implementation decisions

Products ±

y R efined data dictionary to include new classes

y Module diagrams

y Pseudocode

y Class diagrams (static semantics)

y Interaction diagrams (dynamic semantics)

Activities ±

y Selection of Data structures and algorithms that provide semantics of abstraction.



Booch Micro Development Process

II. The Macro Development Process

The macro process serves as a controlling framework for the micro process and can take weeks or even

months. The primary concern of the macro process is technical management of the system. It determines

how well the project corresponds to the requirements set for it and whether it is produced on time. It insists

a number of measurable products and activities that permit the development team to meaningfully assessrisk for making early corrections to the micro process. It focuses upon the two manageable elements ± risk

and architectural vision that have the greatest impact on schedule, quality and completeness. This is an

incremental development process and includes configuration management, code walkthroughs, quality

assurance and documentation.

The macro development process consists of the following steps:

1. C onceptualization:

During conceptualization, establish the core requirements of the system. Establish a set of goals and

develop a prototype to prove the concept. This step is uncontrolled to allow unrestrained innovation.

2. Analysis and development of the model:

This step provides a model of the system behavior. The main activities include domain analysis and

scenario planning. In domain analysis, identify the classes and objects common to a domain. In

scenario planning identify the function points and for each function point identify the scenarios.

(Function point is a unit of measurement to express the amount of business functionality an

information system provides to a user.) In this step, you use the class diagram to describe the roles

and responsibilities objects are to carry out in performing the desired behavior of the system. Then,

you use the object diagram to describe the desired behavior of the system in terms of scenarios or,

alternatively, use the interaction diagram to describe behavior of the system in terms of scenarios.

3 . Design or create the system architecture:

This step establishes common tactical policies. The main activities include architectural planning,

tactical design and release planning. Architectural planning includes devising layers and partitions

for logical decomposition. Tactical design includes making decisions about tactical policies and

release planning activity identifies a controlled series of architectural releases, each growing in its

functionality. In the design phase, you use the class diagram to decide what classes exist and

how they relate to each other. Next, you use the object diagram to decide what mechanisms are

Identify the classes

and objects

Identify theclasses and objects

semantics

Identify theclasses and objects

relationships

S pecify Class andobject interface and

implementation



used to regulate how objects collaborate. Then, you use the module diagram to map out where

each class and object should be declared. Finally, you use the process diagram to determine to

which processor to allocate a process. Also, determine the schedules for multiple processes on

each relevant processor.

4. E volution or implementation:

Successively refine the system through much iteration. The main activities include application of microprocess and change management. Produce a stream of software implementations (or

executable releases), each of which is a refinement of the prior one.

5. Maintenance:

Make localized changes to the system to add new requirements and eliminate bugs. Manage a

punch list to collect bugs and enhancement requirements so that they can be prioritized for future

releases.

Booch Macro Development Process

THE JACOBSON ET AL. METHODOLOGIES

Object-Oriented Software Engineering - OOSE

Object-Oriented Software Engineering (OOSE) is a software design technique that is used in

software design in object-oriented programming.

OOSE is developed by Ivar Jacobson in 1992. OOSE is the first object-oriented design

methodology that employs use cases in software design. OOSE is one of the precursors of theUnified Modeling Language (UML), such as Booch and OMT. It includes a requirements, an

analysis, a design, an implementation and a testing model.

The Jacobson et al. methodologies (e.g., object-oriented Business Engineering (OOBE), object-oriented

Software Engineering (OOSE), and Objectory) cover the entire life cycle and stress traceability between

the different phases, both forward and backward. This traceability enables reuse of analysis and design

work, possibly much bigger factors in the reduction of development time than reuse of code. At the heart

of their methodologies is the use-case concept, which evolved with Objectory (Object Factory for

Software Development).

Establishment of Core

R equirements

CONCEPTUALIZATION

Developing a

model of thedesired behavior

ANALYSIS

Creation of

Architecture

DESIGN

Evolving the

Implementation

EVOLUTION

Managing Post

DeliveryEvolution

MAINTENANCE



Use Cases

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 .In the requirements analysis, the use cases are described as one of the following :

y Nonformal text with no clear flow of events.

y Text, easy to read but with a clear flow of events to follow (this is a recommended style)

y Formal style using pseudo code.

The use case description must contain:

y H ow and when the use case begins and ends.

y The interaction between the use case and its actors, including when the interaction occurs

and what is exchanged.

y H ow and when the use case will need data stored in the system or will store data in the

system.

y Exceptions to the flow of events.y H ow 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:

y The extends relationship is used when you have one use case that is similar to another use

case but does a bit more. In essence, it extends functionality of the original use case (like a

subclass).y The uses relationship reuses common behavior in different use cases.

Use cases could be viewed as concrete or abstract. An ab str act use ca se is not complete and has no

actors that initiate it but is used by another use case. This inheritance could be used in several

levels. Abstract use cases also are the ones that have uses or extends relationships.

Fig:Some uses of a library. As you can see, these are external views of the library system from an

actor such as a member. The simpler the use case, the more effective it will be. It is unwise to capture



all of the details right at the start; you can do that later.

Interaction diagrams are similar to UML's sequence diagrams. State transition diagrams are like

UML statechart diagrams.

Jacobson's Design Model

Jacobson's design model shows how the system behaves. There are two types of diagrams under this model: interaction diagrams and state transition diagrams. Interaction diagrams are similar to

UML's sequence diagrams. State transition diagrams are like UML state chart diagrams, but

Jacobson also employs a number of unique symbols listed below.

Send Message R eceive Message R eturn Message Send Signal

R eceive Signal Perform Task Decision Label

I. Object-Oriented Software Engineering: Objectory

Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented

development with the specific aim to fit the development of large, real-time systems. The development

process, called use-ca se 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 system development method based on OOSE, Objectory, is a disciplined process for the

industrialized development of software, based on a use-case driven design. It is an approach to object-

oriented analysis and design that centers on understanding the ways in which a system actually is used.

By organizing the analysis and design models around sequences of user interaction and actual usage

scenarios, the method produces systems that are both more usable and more robust, adapting more easily

to changing usage. Jacobson et al.'s Objectory has been developed and applied to numerous application

areas and embodied in the CASE tool systems.

Objectory is built around several different models:

y U se ca se-model. The use-case model defines the outside (actors) and inside (use case) of thesystem's behavior.

y Domain object model. The objects of the "real" world are mapped into the domain objectmodel.

y Analysis object model. The analysis object model presents how the source code(implementation) should be carried out and written.

y I mplement ation model. The implementation model represents the implementation of thesystem.

y T est model. The test model constitutes the test plans, specifications, and reports.



Fig: The use ± case model is considered in every model and phase.

The maintenance of each model is specified in its associated process. A process is created when the

first development project starts and is terminated when the developed system is taken out of service.

II. Object-Oriented Business Engineering

Object-oriented business engineering (OOBE) is object modeling at the enterprise level. Use cases

again are the central vehicle for modeling, providing traceability throughout the software

engineering processes.

Analysis phase: 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 process should not

take into account the actual implementation environment. This reduces complexity and promotes

maintainability over the life of the system, since the description of the system will be independent

of hardware and software requirements. Jacobson does not dwell on the development of the

problem-domain object model, this model should be developed just enough to form a base of

understanding for the requirements model. The analysis process is iterative but the requirements

and analysis models should be stable before moving on to subsequent models. Jacobson et al.

suggest that prototyping with a tool might be useful during this phase to help specify user interfaces.

Design and implementation phases: The implementation environment must be identified for the

design model. This includes factors such as Database Management System (DBMS), distribution of

process, constraints due to the programming language, available component libraries, and

incorporation of graphical user interface tools. It may be possible to identify the implementation

environment concurrently with analysis. The analysis objects are translated into design objects that

fit the current implementation environment.

T esting phase: Finally. Jacobson describes several testing levels and techniques. The levels include

unit testing, integration testing, and system- testing.



The Unified Approach

The unified approach (UA) is based on methodologies of Booch, R umbaugh, and Jacobson.

They have mainly adopted four goals from their methodologies:

y R epresent the complete system (Business to Business B2B) using object oriented concepts;

instead of only the software .portion

y Establish explicit coupling between concepts and executable codey Arrive scaling factors for complex and critical systems

y Provide versatile modeling language, which is usable by both human and machine.

It combines their best practices, processes, and guidelines along with the Object Management

Group's (OMG) unified modeling language (UML). The UML is also evolved by the same authors

to introduce consistent object oriented model notation, which has several static and dynamic models

applied to phases of software development. The task of UA is to specify the software development

methodology, which was not specified in the OMG's UML. The UA core concept is based on

Jacobson's Use Case.

The UA processes, methodologies and technology

UA Process UA methodologies and technology

Use Case driven development Unified Modeling Language (UML)

Object oriented analysis (OOA) Layered Architecture

Object oriented Design (OOD)

OO R epository for OO System

development Patterns and Frameworks

Incremental development, prototyping and

continuous testing

Component Based Development (CBD)



The Unified Approach (with its processes and components)

OOA

The goal of OOA is to understand the problem domain and the systems responsibilities by

understanding how the users will use the system. The steps followed in OOA are:

OOA Step 1: Identify the actors: Who is the user of the system?

OOA Step 2: A simple business process model using UML activity diagram has to be developed.

OOA Step 3: Develop the Use Case:

List the works carried out by users in the system

Provide comprehensive documentation of the system under study.

OOA Step 4: Develop interaction Diagrams to identify classes

Determine the sequence of action and Develop sequence and collaboration diagrams

OOA Step 5: Develop static UML classes diagram

(i) Identify classes

(ii) Identify relationships

(iii)Identify attributes

(iv) Identify methods

OOA Step 6: Iterate and refine if needed, repeat the preceding steps



OOD

OOD of UA combines Jacobson's interaction diagrams, Booch's Object Diagrams and

R umbaugh's Domain model. It consists of Designing classes, attributes, methods and

associations, design access and user interface view layer and develop user satisfaction and

usability test.

The elaborated OOD steps are:

OOD Step 1: Design Business Layer classes

(a) Apply design axioms to design classes, their attributes, methods, associations,structures and protocols

(b) R efine and complete the UML Class Diagram by adding details. This stepconsists of R efine attributes, methods, cardinality, visibility, association andclass hierarchy.

(i) R efine attributes(ii) Design methods and protocols by utilizing a UML activity diagram to

represent the method's algorithm(iii) R efine associations between classes (if required)(iv) R efine class hierarchy and design with inheritance (if required)

(c) Iterate and refine again

OOD Step 2: Design Access Layer classes

(a) Create access layer classes for every classes identified and created in Businesslayer (simply mirror the class)

(b) Identify access layer class relationships.

(c) Simplify classes and their relationships by eliminating redundant classes andclasses with a single method.

(i) R edundant classes: Classes that perform similar request and activities arecalled as redundant classes. Selecting one and eliminating other simplify these

classes.(ii) Method Classes: Classes that consist of only one or two methods are called as

method classes. They can be eliminated or combined with existing classes if possible.

(d) Iterate and refine them again.

OOD Step 3: Design View Layer classes

(a) Design the macro level user interfaces, identify view layer objects

(b) Design the micro level user interface, which includes these activities:

(i) Design the view layer objects by applying the design axioms and Corollaries

(ii) Build a prototype of the view layer interface

(c) Do the Tests for usability and user satisfaction

(d) Iterate and refine

OOD Step 4: Iterate and refine the whole design. R e-apply the design axioms and if needed

repeat the preceding steps.

Iterative Development and Continuous Testing

The iteration process is carried out until the users are satisfied with the system. Since testing

often uncovers weaknesses of the design or any other additional information that is used, the

OOAD process is re-prototyped or re-tested.



Modeling based on UML

The Unified Modeling language was developed by the joint efforts of the authors Booch,

Jacobson, R umbaugh and with contribution from many others. It is integrated with several

diagrams from the existing models to provide complete solution Of the system. The UA uses

the UML to describe and model the analysis and design phases of system development. UML is

dealt in detail in the remaining chapters.

UA Repository

R epository allows the maximum reuse of previous experience and previously defined objects,

patterns, frameworks, and user interfaces in an easily accessible manner with a completely

available and easily utilized format. Since the design and development of applications are stored

in common repository, assembling already existing components are made easy. Also, the past

experience will increase the quality of the product and reduce the cost and development time in

future projects. It is relatively easy to search the repository for classes based on their attributes,

methods or other characteristics.

The Layered Architecture

The layered approach of UA is followed in client-server application development environment

that tend to lean towards n-tier architecture. There are three layers (Figure 4.4) in layered

approach: access layer (database storage and retrieval), business layer (business logic and queries)

and View layer (user interface).

(a) Business Layer

The Business Layer includes all the objects that represent the business (both data and

behavior).The business layer acts as an intermediate between Access and View layer

communication. The Business layer objects are identified during the design phase of ObjectOriented Software Development (OOSD). The responsibilities of the business layer are:

( i) Displaying Details: The view layer request is sent to access layer and response is displayed in

view layer through the business objects in- business layer. Business objects do not require special

knowledge of how they are being displayed and by whom. They are designed to be independent

of any particular interface. Hence the details of how to display an object should exist in the

interface layer of the object displaying it.

( ii) Data access Details: The initiated query is sent as business objects to access the required data.

Business objects need not have special knowledge of "where they come from". It does not matter

to the business model whether the data are stored and retrieved via SQL or file I/O. The businessobjects are modeled during the OOA.

(b) View Layer

The View / User Interface layer consists of objects with which the user interacts as well as the

objects required to manage or to control the interface. The view layer objects are also identified

during the design phase of OOSD. This layer typically is responsible for two major aspects of the

application.



( i) Responding to user interaction: The user interface layer objects must be designed to interpret

the actions of the user and translate the actions by the user, such as clicking on a button or

selecting from a menu, into an appropriate response. It requires just the knowledge of which

message to send to which business object. It does not require the business logic.

( ii) Displaying business objects: This layer must paint the best possible picture of the business

objects for the user. This layer must provide the information to the user in the form of list boxes,

text boxes, entry fields and graphs, according to the requirement.

(c) Access Layer

The Access Layer contains objects of that know how to communicate with the place where the

data actually reside (database). There are two major responsibilities for the access layer. They

are:

( i) T ranslate request: The access layer must be able to translate any data related requests from

the business layer into the appropriate protocol for enabling data access.

( ii) T ranslate results: The access layer must also be able to translate the data retrieved back into

the appropriate business objects and pass those objects back into the business layer.

REFERENCES

y ³ Object ± Oriented Analysis and Design W ith A pplications´ , Pearson Education,

Second Edition ±Grady Booch

y ³ Object ± Oriented Software Engineering A U se ca se driven a pproach´ , Pearson

Education ± Ivar Jacobson, Christerson, Jonsson, Overgaard

y ³ Object ± Oriented Analysis and Design Using UML´ , Scitech Publications, Second

Edition ±H.Srimathi, H.Sriram, A.Krishnamoorthyy ³ Object ± Oriented Systems Development using the unified modeling l angua ge´ , Tata

McGrawHill-Ali Bahrami

booch jacobson uml

Documents