Object-Oriented Analysis and Design with Applications

UNIT III

CHAPTER 5: NOTATION

 USE CASE DIAGRAMS

Use case diagrams are used to depict the context of the system to be built and the
functionality provided by that system. They depict who (or what) interacts with the
system. They show what the outside world wants the system to do.
Essentials: Actors
Actors are entities that interface with the system. They can be people or other
systems. Actors, which are external to the system they are using, are depicted as stylized
stick figures. Figure 5–20 shows two actors for the Hydroponics Gardening System.
Figure : Actors

Essentials: Use Cases

Use cases represent what the actors want your system to do for them. cases are not
just any capability that your system may provide. A use case must be a complete flow of
activity, from the actor’s point of view, that provides value to the actor.
Essentials: The Use Case Diagram
To show which actors use which use cases, you can create a use case diagram by
connecting them via basic associations, shown by lines.
Figure: Cases

1
Object-Oriented Analysis and Design with Applications
Figure : Use Case Diagram

Advanced Concepts: «include» and «extend» Relationships

Two relationships used primarily for organizing use case models are both powerful and
commonly misused: the «include» and «extend» relationships. These relationships are used
between use cases.
«include» Relationships

2
Object-Oriented Analysis and Design with Applications
«extend» Relationships

Advanced Concepts: Generalization

Generalization relationships can also be used to relate use cases. As with classes, use cases
can have common behaviors that other use cases (i.e., child use cases) can modify by adding steps or
refining others.

Figure 5–26 A Use Case Generalization

 ACTIVITY DIAGRAMS
Activity diagrams provide visual depictions of the flow of activities, whether in a
system, business, workflow, or other process. These diagrams focus on the activities that are
performed and who (or what) is responsible for the performance of those activities.

3
Object-Oriented Analysis and Design with Applications

The elements of an activity diagram are action nodes, control nodes, and object nodes.
There are three types of control nodes: initial and final (final nodes have two varieties,
activity final and flow final), decision and merge, and fork and join.
Essentials: Actions
Actions are the elemental unit of behaviour in an activity diagram. Activities can contain
many actions which are what activity diagrams depict.
Figure: The Notation for an Action

Essentials: Starting and Stopping

Since an activity diagram shows a process flow, that flow must start and stop
somewhere. The starting point (the initial node) for an activity flow is shown as a solid dot,
and the stopping point (the activity final node).

Essentials: Decision and Merge Nodes

Decision and merge nodes control the flow in an activity diagram. Each node is
represented by a diamond shape with incoming and outgoing arrows. A decision node has
one incoming flow and multiple outgoing flows.
Figure : A Decision Node

4
Object-Oriented Analysis and Design with Applications

Figure: A Merge Node with a Flow Final Node

Essentials: Partitions
The elements in an activity diagram can be grouped by using partitions. The purpose
of a partition is to indicate where the responsibility lies for performing specific activities.

Advanced Concepts: Forks, Joins, and Concurrency

Fork and join nodes are analogous to decision and merge nodes, respectively. The
critical difference is concurrency. Forks have one flow in and multiple flows out, as do
decision nodes. The difference is, where a decision node selects a single outbound flow, a
single flow into a fork results in multiple outbound flows.
A join has multiple incoming flows and a single outbound flow, similar to merge nodes.
However, with a join, all the incoming flows must be completed before the outbound flow
commences.
 CLASS DIAGRAM
A class diagram is used to show the existence of classes and their relationships in the
logical view of a system. A single class diagram represents a view of the class structureof a
system.to indicate the common roles and responsibilities of the entities that provide the
system's behaviour. During design, we use class diagrams to capture the structure of the
classes that form the system's architecture. The two essential elements of a class diagram are
classes and their basic relationships.
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics.

5
Object-Oriented Analysis and Design with Applications

Contents:
Class diagrams commonly contain the following things:
 Classes
 Interfaces
 Collaborations
 Dependency, generalization, and association relationships.

Essentials: Class Relationships

Classes rarely stand alone; instead, they collaborate with other classes in a variety of
ways. The essential connections among classes include association, generalization,
aggregation, and composition.

The association icon connects two classes and denotes a semantic connection.
The generalization icon denotes a generalization/specialization relationship (the ―is a‖
relationship, and appears as an association with a closed arrow head. The arrowhead points to
the super class, and the opposite end of the association designates the subclass.
The aggregation icon denotes a whole/part hierarchy and also implies the ability to
navigate from the aggregate to its parts.
The composition icon denoting a containment relationship appears as an association with
a filled diamond at the end denoting the aggregate.

6
Object-Oriented Analysis and Design with Applications

Figure: Class Relationship Icons

Multiplicity:

■ 1 Exactly one
■ * Unlimited number (zero or more)
■ 0..* Zero or more
■ 1..* One or more
■ 0..1 Zero or one
■ 3..7 Specified range (from three through seven, inclusive)
 SEQUENCE DIAGRAMS
A sequence diagram is used to trace the execution of a scenario in the same context as a
communication diagram.
Essentials: Objects and Interactions
The advantage of using a sequence diagram is that it is easier to read the passing of messages
in relative order.

7
Object-Oriented Analysis and Design with Applications

Figure: A Sequence Diagram

Essentials: Lifelines and Messages

In sequence diagrams, the entities of interest (which are the same as for object diagrams)
are written horizontally across the top of the diagram. A dashed vertical line, called the
lifeline, is drawn below each object. These indicate the existence of the object. Messages
(which may denote events or the invocation of operations) are shown horizontally.
Interaction Overview Diagrams
Interaction overview diagrams are a combination of activity diagrams and interaction
diagrams that are intended to provide an overview of the flow of control between interaction
diagram elements. Though any type of interaction diagram (sequence, communication, or
timing) may be used, the sequence diagram will likely be the most prevalent. The essential
elements of the interaction overview diagram are the frames, the flow of control elements,
and the interaction diagram elements.
Essentials: Frames
The interaction overview diagram is typically surrounded by a frame; however, the frame is
optional when the context is clear.
Essentials: Flow of Control Elements
The flow of control within an interaction overview diagram is provided by a combination
of activity diagram elements to provide for both alternate and parallel paths. The alternate
path control is provided by combinations of a decision node, where the appropriate path is
chosen, and a corresponding merge node (as appropriate) to bring the alternate paths together.

8
Object-Oriented Analysis and Design with Applications

Essentials: Interaction Diagram Elements

The interaction overview diagram contains two types of elements to provide the interaction
diagram information, either an interaction or an interaction use. The interaction is any type of
interaction diagram that provides the nested details of the interaction; these are typically
sequence diagrams.
Figure: The Interaction Overview Diagram for MaintainTemperature

 Composite Structure Diagrams

Composite structure diagrams provide a way to depict a structured classifier with the
definition of its internal structure. This internal structure is comprised of parts and their
interconnections, all within the namespace of the composite structure.

The essential elements of a composite structure are its parts, ports, interfaces, and
connectors.

9
Object-Oriented Analysis and Design with Applications

Essentials: Composite Structure Parts

Essentials: Composite Structure Ports and Interfaces

The composite structure and its parts interface with their external environment through
ports, denoted by a small square on the boundary of the part or composite structure.
Essentials: Composite Structure Connectors
Connectors within composite structure diagrams provide the communication links between
the composite and its environment, as well as the means for its parts to communicate
internally.
 State Machine Diagrams
State machines are well known in industries that use real-time processing. State
machine diagrams are used to design and understand time-critical systems, in which the
consequences of improper timing are severe.
Essentials: Initial, Final, and Simple States
The state of an object represents the cumulative results of its behaviour. For example,
inter process communication, transaction management and security, and so on).
Figure: Notations for Simple States

Essentials: Transitions and Events

The movements between states are called transitions. On a state machine diagram, transitions
are shown by directed arrows between states.

10
Object-Oriented Analysis and Design with Applications

Figure: Transitions for the Duration Timer

 Timing Diagrams
Timing diagrams are a type of interaction diagram. Their purpose is to show how the
states of an element or elements change over time and how events change those states.
Essentials: Layout
Timing diagrams take the UML elements and present them to the user in a different
organization. The general layout of a timing diagram is reminiscent of a sequence diagram
laid on its side.
Essentials: Events
Events (or other stimuli such as messages) that cause state changes are shown in the
lifeline near the timeline of the object

Essentials: Constraints
Constraints can be used to specify conditions or limits that restrict the change of state
shown on a timing diagram.
 OBJECT DIAGRAMS
An object diagram is used to show the existence of objects and their relationships in the
logical design of a system. In this sense, a single object diagram represents a view of the
object structure of a system.
The two essential elements of object diagrams are objects and their relationships.
Contents
Essentials: Objects
Figure shows the icon we use to represent an object in an object diagram. Similar to class
diagrams, a horizontal line partitions the text inside the icon into two regions, one denoting
the object’s name and the other providing an optional view of the object’s attributes and
their values.

11
Object-Oriented Analysis and Design with Applications

Figure 5–75 A Generic Object Icon

Essentials: Object Relationships

Objects interact through their links to other objects.

Figure 5–76 Object Relationships

Object diagrams commonly contain

 Objects
 Links
 COMMUNICATION DIAGRAMS
A communication diagram is a type of interaction diagram that focuses on how objects
are linked and what messages they pass as they participate in a specific interaction.

12
Object-Oriented Analysis and Design with Applications

Essentials: Objects, Links, and Messages

A link may exist between two objects if and only if there is an association between their
corresponding classes. The existence of an association between two classes denotes a path of
communication (i.e., a link) between instances of the classes, whereby one object may send
messages to another.
Figure 5–77 A Communication Diagram for the Hydroponics Gardening System

Essentials: Sequence Expressions

sequence expression indicates the relative ordering of messages. Messages with lower
sequence numbers are dispatched before messages with higher sequence numbers.
CHAPTER 6: THE PROCCESS
 FIRST PRINCIPLES
The process of object-oriented analysis and design cannot be described in a cookbook, yet
it is sufficiently well defined as to offer a predictable and repeatable process for the mature
software development organization.
Traits of Successful Projects
A successful software project is one whose deliverables -satisfy and possibly exceed the
customer's expectations, was developed in a timely and economical fashion, and is resilient to
change and adaptation.

13
Object-Oriented Analysis and Design with Applications

Successful projects are usually characterized by a strong architectural vision and a well-
managed iterative and incremental development life cyc1e.
Strong Architectural Vision
A strong architectural vision is something that is common to virtually all of the
successful object-oriented systems we have encountered. architecture as the ―fundamental
organization of a system embodied in its components, their relationships to each other, and to
the environment, and the principles guiding its design and evolution‖.ss
Good software architectures tend to have several attributes in common:
 They are constructed in well-defined layers of abstraction, each layer representing
acoherent abstraction, provided through a well-defined and controlled interface, and
builtupon equally well-defined and controlled facilities at lower levels of abstraction.
 There is a clear separation of concerns between the interface and implementation of
eachlayer, making it possible to change the implementation of a layer without
violating theassumptions made by its clients.
 The architecture is simple: common behaviour is achieved through common
abstractionsand common mechanisms.
 THE MICRO PROCESS: SDLC
The macro process is the overall software development lifecycle that serves as the
controlling framework for the micro process (which we’ll describe later in this chapter). It
represents the activities of the entire development team.
The macro software development process can be described in terms of two dimensions,
content and time. The content dimension includes roles, tasks, and work products and can
be described in terms of disciplines, or areas of concern, which logically group the content.
The time dimension shows the lifecycle aspects of the process and can be described in terms
of milestones, phases, and iterations.

The Macro Process Content Dimension - Disciplines

1. Requirements: Establish and maintain agreement with the customers and other
stakeholders on what the system should do.
2. Analysis and design: Transform the requirements into a design of the system, which
serves as a specification of the implementation in the selected implementation
environment.
3. Implementation: Implement, unit test, and integrate the design, resulting in an
executable system.

14
Object-Oriented Analysis and Design with Applications

4. Test: Test the implementation to make sure that it fulfills the requirements (i.e., the
requirements have been implemented appropriately.
5. Deployment: Ensure that the software product (including the tested implementation)
is available for its end users.

Figure 6–1 The Macro Development Process Disciplines

The following disciplines are executed throughout the lifecycle.

■ Project management: Manage the software development project, including
planning, staffing, and monitoring the project, as well as managing the risks.
■ Configuration and change management: Identify the configuration items, control
changes to those items, and manage configurations of those items.
■ Environment: Provide the software development environment, including both
processes and tools that support the development team.
The Macro Process Time Dimension— Milestones and Phases
In an iterative and incremental macro process, the disciplines are repeated.
Inception
This subsection covers the purpose, activities, work products, and milestone of the
Inception phase. Purpose of the Inception phase is to ensure that the project is both
valuable and feasible (scope and business value).
The Macro Process Time Dimension— Iterations
In an iterative macro process, the milestones are achieved by executing one or
more iterations.
 The Micro Process: The Analysis and Design Process
The analysis and design process is performed in the context of an overall software
development process. The macro process drives the scope of the micro process,
provides inputs to the micro process, and consumes the outputs of the micro process.
Specifically, the micro process takes the requirements provided by the macro process
(and any analysis and design specifications produced by previous iterations of the

15
Object-Oriented Analysis and Design with Applications

micro process) and produces design specifications (most notably, the architecture)
that are implemented, tested, and deployed in the macro process.
Just as we described the macro process in terms of two dimensions, time and content,
we will describe the micro process in terms of its two key dimensions— levels of
abstraction and content (activities and work products).

Figure 6–4 The Micro Process within the Macro Process

Levels of Abstraction
Analysis takes the system requirements and produces an initial solution, and design
takes the results of analysis and produces a specification that can be efficiently
implemented.

Figure 6–5 The Varying Focus of Analysis and Design, Depending on Perspective

16
Object-Oriented Analysis and Design with Applications

The micro process consists of the following set of activities, which are performed for a
specific scope and at a specific level of abstraction.
■ Identify the elements: Discover (or invent) the elements to work with. Define the object-
oriented decomposition.
■ Define the collaborations between the elements: Describe how the identified elements
collaborate to provide the system’s behavioral requirements.
■ Define the relationships between the elements: Define the relationships between the
elements that support the element collaborations.
■ Define the semantics of the elements: Establish the behavior and attributes of the
identified elements. Prepare the elements for the next level of abstraction.

Figure 6–6 The Micro Process Activities

The primary products of the micro process reflect the different analysis and design concerns.
 The architecture description describes the system’s architecture, including
descriptions of common mechanisms. The description includes the architecturally
significant aspects of the analysis/design model.
 The analysis/design model includes the analysis and design elements of the software
solution and their organization.
Steps of Macro Process
 The first step in the macro process is conceptualization
 The second step in the macro process is analysis.
 The third step in the macro process is design
 The fourth step in the macro process is evolution
 The fifth step in the macro process is maintenance

17
Object-Oriented Analysis and Design with Applications

CHAPTER 7: PRAGMATICS
 MANAGEMENT AND PLANNING
In the presence of an iterative and incremental life cycle, it is of paramount importance to
have strong project leadership that actively manages and directs a project's activities. Too
Many projects go astray because of a lack of focus, and the presence of a strong management
Team mitigates this problem.
Risk Management
Ultimately, the responsibility of the software development manager is to manage technical
as well as nontechnical risk. Technical risks in object-oriented systems include problems such
as the selection of an inheritance lattice that offers the best compromise between usability and
Flexibility.
Task Planning
In any modest- to large-sized project, it is reasonable to have weekly team meetings to
discuss work completed and activities for the coming week. Some minimal frequency of
meetings is necessary to foster communication among team members; too many meetings
destroy productivity, and in fact are a sign that the project has lost its way. Object-oriented
software development requires that individual developers have unscheduled critical masses of
time in which they can think, innovate, and develop, and meet informally with other team
members as necessary to discuss detailed technical issues. The management team must plan
for this unstructured time.
 STAFFING
Staffing for object-oriented development is similar to that for traditional software
development. The differences tend to be associated with the timing of these resources within
the development cycle. For example, architects and designers play a critical role early in the
process due to its iterative and incremental nature.
Resource Allocation
the first object-oriented project undertaken by an organization will require slightly more
resources than for non-object-oriented methods, primarily because of the learning curve
inherent in adopting any new technology. The essential resource benefits of the object model
will not show themselves until the second or third project, at which time the development
team is more adept at class design and harvesting common abstractions and mechanisms, and
the management team is more comfortable with driving the iterative and incremental
development process.

18
Object-Oriented Analysis and Design with Applications

Development Team Roles

It is important to remember that software development is ultimately a human end eavor.
Developers are not interchangeable parts, and the successful deployment of any complex
system requires the unique and varied skills of a focused team of people.
Three roles to be central to an object-oriented project:
1. Project architect
2. Subsystem lead
3. Application engineer
 Release Management
Release management concerns for object-oriented development are like those for
traditional software development; they provide a foundation to support the development
process.

Configuration Management and Version Control

Consider the plight of an individual developer, who might be responsible for
implementing a particular component. He or she must have a working version of that
component, that is, a version under development.
Integration
Industrial-strength projects require the development of families of programs. the nature of
the iterative and incremental process of object-oriented development means that there should
not be a single ―big bang‖ integration event.
Testing
The principle of continuous integration applies as well to testing, which should also be a
continuous activity during the development process. In the context of object-oriented
architectures, testing must encompass at least three dimensions:
1. Unit testing :Involves testing individual classes and mechanisms; is the
responsibility of the application engineer who implemented the structure
2. Subsystem testing Involves testing a complete category or subsystem; is the
responsibility of the subsystem lead; subsystem tests can be used as regression
tests for each newly released version of the subsystem
3. System testing Involves testing the system as a whole; is the responsibility of the
quality-assurance team; system tests are also typically used as regression tests by
the integration team when assembling new release.

19
Object-Oriented Analysis and Design with Applications

 REUSE
One of the most acclaimed benefits of object-oriented development is reuse.

Elements of Reuse
Any artifact of software development can be reused, including code, designs, scenarios,
and documentation.in object-oriented programming languages, classes serve as the primary
linguistic vehicle for reuse: classes may be subclassed to specialize or extend the base class.
we can reuse patterns of classes, objects, and designs form of idioms, mechanisms, and
frameworks.
Reuse must be institutionalized to be successful.
Institutionalizing Reuse
Reuse within a project or even an entire organization doesn't just happen, it must be
institutionalized. An effective reuse program is best achieved by making specific individuals
responsible for leading the reuse activity, while making everyone responsible for
participating.
 QUALITY ASSURANCE AND METRICS
Software Quality
Software quality involves ―the fitness for use of the total software product. Software
quality doesn't just happen: it must be engineering into the system .
Software quality assurance involves "the systematic activities providing evidence of the
fitness for use of the total software product" . Quality assurance seeks to give us
quantifiable measures of goodness for the quality of a software system.
Software Quality

Development reviews and other kinds of inspections are important practices even in object-
oriented systems and provide insights into the software’s quality.
Object-Oriented Metrics
Metrics to assist us in this endeavor fall into one of two categories, process metrics or product
metrics. Process metrics, sometimes called project metrics.
We can also look at metrics more specific to object-oriented development, such as those
recommended by Lorenz and Kidd [16]:
■ Application size
– Number of scenario scripts (NSS)
– Number of key classes (NKC)
– Number of support classes (NSC)

20
Object-Oriented Analysis and Design with Applications

– Number of subsystems (NOS)

■ Staffing size
– Person-days per class (PDC)
– Classes per developer (CPD)
■ Scheduling
– Number of major iterations (NMI)
– Number of contracts completed (NCC)
Chidamber and Kemerersuggestnumber of metrics that are directly applicable to object
oriented systems.
1. Weighted methods per class
2. Depth of inheritance tree
3. Number of children
4. Coupling between objects
5. Response for a class
6. Lack of cohesion in methods
 DOCUMENTATION
In addition to code, there are development artifacts that are critical to the complete
lifecycle of a software system. These artifacts, such as requirements and design, must be
documented to support the development process and the operation and maintenance of the
system.
Development Legacy
The development of a software system involves much more than writing its raw source
code. The products of object-oriented analysis and design are visual models in which we
create numerous views in the form of diagrams. These views include sets of use case
diagrams, activity diagrams, class diagrams, state machine diagrams, sequence diagrams, and
component diagrams.
Documentation Contents
The documentation of a system’s architecture and implementation is important, but the
production of such documents should never drive the development process: Documentation is
an essential, albeit secondary, product of the development process. Together with the design
and generated code, delivered documents serve as the basis of most formal and informal
reviews.

21
Object-Oriented Analysis and Design with Applications

In general, the essential documentation of a system's architecture and implementation

should include the following:
 Documentation of the high-level system architecture
 Documentation of the key abstractions and mechanisms in the architecture
 Documentation of scenarios that illustrate the as-built behaviour of key aspects of the
system
 TOOLS
We need tools that can focus on richer semantics. In addition, the rapid development of
releases defined by the macro process of object-oriented development requires tools that offer
rapid turnaround for the analysis and design cycle.
Kinds of Tool
We have identified three primary tools applicable to object-oriented analysis and design.
The first is a visual modelling tool supporting the UML notation.
Next, especially for larger projects, one must have software configuration management and
version control tools. Such tools support the development team as they collaborate and share
assets throughout the entire software development lifecycle.
The third tool we have found important with object-oriented analysis and design is a class
library tool. Many languages have predefined class libraries or commercially available class
libraries. As a project matures, the library grows as domain specific reusable software classes
and components are added over time. It does not take long for such a library to grow to
enormous proportions, which makes it difficult for a developer to find a class or component
that meets his or her needs.
 Special Topics
There are several topics of special concern to people practicing object-oriented analysis and
design.
 Domain-Specific Issues
 Adopting Object-Oriented Technology

 BENEFITS AND RISKS OF OBJECT-ORIENTED DEVELOPMENT.

The Benefits of Object-Oriented Development
First, they seek a competitive advantage, such as reduced time to market, greater product
flexibility, or schedule predictability.
Second, they may have problems that are so complex that don't seem to have any other
solution.

22
Object-Oriented Analysis and Design with Applications

Benefits that flow from the following characteristics of the object model
 Exploits the expressive power of all object-oriented programming languages
 Encourages the reuse of software components
 Leads to systems that are more resilient to change
 Reduces development risk
 Appeals to the working of human cognition
The Risks of Object-Oriented Development
 A unique way to define architecture and data structure instances
 Information hiding through abstraction and encapsulation
 Inheritance to organize related elements
 Polymorphism to perform operations that can automatically adapt to the type of
structure they operate on
 Specialized analysis and design methods
 Environments that facilitate the creation of object-oriented systems
 Design by contract, a powerful technique to circumvent module boundary and
interface problems
 Memory management that can automatically reclaim unused memory
 Distributed objects to facilitate the creation of powerful distributed systems
 Object databases to move beyond the data-type limitations of relational database
management systems
Other Risk
 Personnel shortfalls
 Unrealistic schedules, budgets, or processes
 Shortfalls in commercial off-the-shelf products, external components, or legacy
software
 Mismatches in requirements or user interface
 Shortfalls in architecture, performance, or quality

On the darker side of object-oriented design, we find that two areas of risk must be
considered: performance and start-up costs.
A related performance risk derives from the encumbrance of classes: a class deep in an
inheritance lattice may have many superclasses, whose code must be included when linking
in the most specific class.
The start-up costs associated with object-oriented development may prove to be a very
real barrier to adopting the technology.
Written by: Abdijabar Awais Osman

23
Object-Oriented Analysis and Design with Applications

END

24