Too Many Methodologies

• 1986: Booch came up with the object-oriented

design concept, the Booch method.

• 1987: Sally Shlaer and Steve Mellor came up with

the concept of the recursive design approach.
 Too Many Methodologies (Con’t)

• 1989: Beck and Cunningham came up with class-

responsibility-collaboration (CRC) cards.

• 1990: Wirfs-Brock, Wilkerson, and Wiener came up

with responsibility-driven design.

• 1991: Peter Coad and Ed Yourdon developed the

Coad lightweight and prototype-oriented
approach.
 Too Many Methodologies (Con’t)

• 1991: Jim Rumbaugh led a team at the research

labs of General Electric to develop the object
modeling technique (OMT).

• 1994: Ivar Jacobson introduced the concept of the

use case.
 Implication
• Split, Competetive & Confusing

• Same basic concepts in different notations

Survey of Some of the Object-Oriented
Methodologies
• Many methodologies are available to choose from
for system development.

• Here, we look at the methodologies developed by

Yourdan, Rumbaugh et al., Booch, and Jacobson
which are the origins of the Unified Modeling
Language (UML)
Coad-Yourdon
Two-phase introduction:

Object-Oriented Analysis (OOA) in 1989, and

Object-Oriented Design (OOD) in 1991
 Coad-Yourdon: OOA
The analysis (OOA) phase of the methodology consists of five principal
activities:

1. Finding “Classes” (abstract classes) and “Class-&-Objects“ (concrete classes)

2. Identifying “Structures” (generalization-specialization and whole-part

relationships between classes)

3. Identifying “Subjects” (partitions/subsystems)

4. Defining attributes, and “Instance-Connections” (association relationships

between classes)

5. Defining “Services” (class operations) and “Message-Connections”

(invocations of operations)
 Coad-Yourdon: Main Model
OOA/OOD Results are reflected in a special Class-&-Object Diagram
(later complemented by behavioural models); the diagram consists of five
layers:

Subject layer: showing the overall partitions of the system

Class-&-Object layer: showing the abstract and concrete classes of

the system

Structure layer: showing the generalization-specification and whole-

part relationships between the classes

Attribute layer: showing the attributes of the classes and the

association relationships between classes.

Service layer: showing the operations of the classes and the

potential message-passing between the objects
 Coad-Yourdon: OOD
During the design phase of the methodology (OOD) the system
is designed in four components:

Problem Domain Component (PDC):

Initially contains the results of the analysis phase.
It includes the ``problem domain'' classes that were identified during
object-oriented analysis.
During OOD, it is improved and enriched with implementation
detail.

Human Interaction Component (HIC):

handles sending and receiving messages to and from the user.
 Coad-Yourdon: OOD Continued
3. Task Management Component (TMC): for systems needing to
implement multiple threads of control; defines the multi-task processing
classes, coordinates the tasks (processes) and provides means for
intertask communication.

4. Data Management Component (DMC): provides the infrastructure to

store and retrieve objects; may be a simple file system, a relational
database management system, or even an object-oriented database
management system
 THE SHLAER-MELLOR METHOD
The Shlaer-Mellor Method comprises the following steps, grouped into two separate
activities:

1. Object-Oriented Analysis (OOA) and

2. Recursive Design (RD).

I. Object-Oriented Analysis

a. Partition the system into domains.

b. Perform a detailed Object-Oriented Analysis (OOA) on each domain that must
be built.
• OOA consists of developing three models :
i. an Object Information Model (OIM),
ii. State Model (SM) and
iii. Process Model (PM)
c. Verify the analysis of each domain.
 THE SHLAER-MELLOR METHOD

II. Recursive Design

a. Determine an architecture and specify the rules for translation of the OOA models into
implementation.

b. Build the translation components.

c. Translate the OOA models into implementation.

 THE SHLAER-MELLOR METHOD
The fundamental difference between the Shlaer-Mellor Method and other methods:

• Shlaer and Mellor view analysis and design as two separate subject matters
(domains)

• while

• the other methods view analysis and design as a difference in the level of detail
described
 The shlaer-mellor method
This approach leads to three main characteristics of the method.

1. Domains

2. Purpose of Analysis

3. Implementation through Translation

 1. Domains
Domains: A key component in the method is early separation of the problem into various
subject matters or domains.

A domain is defined as: A separate real, hypothetical, or abstract world inhabited by

a distinct set of objects that behave according to rules and policies characteristic of the
domain.

A defined world (i.e., the abstract world of User Interface) has a set of objects (Icon,
Window, Dialog Box) that exhibit behavior expected of objects in that domain.

For instance, icons can overlap other icons and dialog boxes cannot be moved outside a
window.
• Almost every system is a mixture of different subject matters.

• This mixture might include (for example) the Application, User Interface,
Peripheral Interfacing, Operating System, Computer Language, and
Reporting (Figure 2 on previous slide).

• Typically, these are all combined together, making it necessary for an

individual working with the project team to be an expert in each domain.
This is called vertical partitioning.

• Treating these as separate domains allows individual specialization in each

problem area, often in parallel. This is called horizontal partitioning.
• Domains exist as separate, reusable frameworks available to project teams that have
similar requirements.

• Through reuse of domains, users of Shlaer-Mellor often achieve 50 to 60 percent

reusability of the OOA objects, as compared to typically 5 to 15 percent reusability of
code classes.

• Domains achieve their independence through the use of bridges which connect the
requirements in the client domains to the functionality provided by the service
domains (see Figure 3).

• In the example shown, a new application domain, requiring the display of icons, can
reuse the objects (in the User Interface domain) that provided this capability.

• In many companies that develop families of products, only the application domain
• changes between projects.
 2. Purpose of Analysis
• In many methods (i.e., Object Modeling Technique/OMT or Rumbaugh method,
analysis is viewed in less detail than shown in the design phase.

• Shlaer and Mellor define analysis as a complete, unambiguous definition of a

problem.

• The analysis is complete when a detailed description of the problem is captured in the
OOA models.

• There is a well defined formalism that instructs analysts how to model in each
domain.

• This amount of rigor is needed to provide a clear definition of the problem and to
allow it to be translated into implementation (code).

• This is similar to a compiler requiring the source file to be in the exact syntax of the
language.

• Informal models cannot be translated. This structure also allows a complete static
check and dynamic simulation of the problem.
3. Implementation through Translation
• This difference allows Shlaer-Mellor analysis models to be translated (compiled)
directly to code.

• With other methods the developers evolve the objects from sketchy analysis drawings
to final code by adding detail at the various steps in the development process.

• The result is that the Shlaer-Mellor analysis models contain far more detail than what
people normally expect in analysis.

• The OOA models contain a level of detail that people often associate with detailed
design or coding. This is because "level of detail" is not used to separate analysis
from design or coding.

• Considerable time will be spent in the analysis phase of a project, but, this time will be
made up in the coding phase.

• In the Shlaer-Mellor courses, Project Technology instructors teach users to expect

that approximately 60 percent of the project's time will be used to develop the OOA
models.
 Rumbaugh’s Object Modeling Technique (OMT)

-A method for analysis, design and implementation by an object oriented

technique.

-fast and intuitive approach for identifying and modeling all objects
making up a system.

-Class attributes, methods, inheritance and association can be expressed

easily.

-Dynamic behavior of objects can be described using the OMT dynamic

model.

-Detailed specification of state transitions and their descriptions within a

system
 OMT (Con’t)
• OMT consists of four phases, which can be
performed iteratively:

1.Analysis. The results are objects and

dynamic and functional models.

2.System design. The result is a structure of

the basic architecture of the system.
 OMT (Con’t)

3. Object design.
This phase produces a design document,
consisting of detailed objects and dynamic
and functional models.

4. Implementation.
This activity produces reusable, extendible,
and robust code.
 OMT Modeling
• OMT separates modeling into three different parts:

1. An object model, presented by the object model and the

data dictionary.

2. A dynamic model, presented by the state diagrams and

event flow diagrams.

3. A functional model, presented by data flow and

constraints.
 Object Model
• Describes structure of objects in system
– Identity
– Relationship to other objects
– Attributes
– Operations

• Represented graphically with object diagram

– Contains classes interconnected by association lines
– Each class represents a set of individual objects
– Association line represents set of links from objects of one class to
objects of another class
OMT Object Model of a Bank System
 OMT Dynamic Model
• OMT state transition diagram is a network of states
& events
– Depict states, transitions, events, actions
– Each state receives one or more events at which time it
makes the transition to the next state
– Next state depends on events + current state
– OMT state transition diagram-network of states and
events
State Transition Diagram for Bank
Application User Interface
 OMT Functional Model
• Describes business process without focusing on computer
systems details

• OMT data flow diagram shows flow of data between

different processes in business
– Processes – function performed
– Data flow – direction of data element movement
– Data store – location where data are stored
– External entity – source/destination of data element
 Data Flow Diagram
• Four primary symbols
Process- any function being performed
Data Flow- Direction of data element movement

Data Store – Location where data is stored

External Entity-Source or Destination of a data element

OMT DFD of ATM System
 Booch
• Introduced, purely as a design method, in 1991.
• Extended version, which also covered analysis, was introduced
in 1994.

• Process designed as a repeating process (referred to as “The

Micro Process”) within a lifecycle-level repeating process
(referred to as “The Macro Process”).

• The macro process serves as a controlling framework for the

micro process.
 Booch Methodology
• Analysis & design method using object oriented
paradigm.
– Start with class & object diagrams in analysis phase
– Diagrams refined in various steps
– Add design symbols when ready to generate code
• Object-oriented code documented
• Criticized for his large set of symbols
 Booch method

• Macro Development Process

• Micro Development Process

Booch: Macro Process
• Many parts of this process are basic software management
practices such as quality assurance, code walkthroughs, and
documentation.

• The focus at this level is more upon the customers and their
desires for things such as quality, completeness, and
scheduling.

• Represents the activities of the development team on the scale

of weeks to months.

• Primary concern-technical management of the system.

 Booch’s Macro Development Process

• Conceptualization
– Establish core requirements
– Establish goal
– Develop prototype to prove concepts

• Analysis model
– Use class diagram to describe roles & responsibilities of objects in system
– Use object diagram or interaction diagram to describe desired behavior of
system in terms of scenarios
 Booch’s Macro Development Process
• Design & create system architecture

– Use class diagram to decide what classes exist, how they relate to one
another
– Use object diagram to decide what mechanisms are used to regulate how
objects collaborate
– Use module diagram to map where each class & object should be
declared
– Use process diagram to determine process allocation to processors
– Determine schedule for multiple processes on processors
 Booch’s Macro Development Process Cont.

• Evolution or Implementation
– Refine system through iterations
– Produce stream of software implementations/executable releases

• Maintenance
– Make localized changes to add new requirements/eliminate bugs
 Booch’s Micro Development Process
• Driven by scenarios and architectural specifications that emerge from
the macro process

• Represents the daily activities of the individual or small group of

developers
• Each macro process has its own micro development process

• Day to day activities for each macro development process can consist
of following steps

– Identify classes & objects

– Identify Class & object semantics
– Identify class & object relationships
– Identify class & object interfaces/implementation
 Diagrams of Booch method
• Class diagrams-
describe roles and responsibilities of objects
• Object diagrams
describe the desired behavior of the system in terms of scenarios
• State transition diagrams
state of a class based on a stimulus
• Module diagrams
to map out where each class & object should be declared
• Process diagrams
to determine to which processor to allocate a process
• Interaction diagrams
describes behavior of the system in terms of scenarios
Eg. of Booch class diagram
Booch state transition diagram for Alarm Class