Post on 10-Apr-2018
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)
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 2/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 3/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 4/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 5/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 6/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 7/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 8/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 9/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 10/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 11/15
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)
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 12/15
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
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 13/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 14/15
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.
8/8/2019 Booch Jacobson Uml
http://slidepdf.com/reader/full/booch-jacobson-uml 15/15
( 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