Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Object-Oriented Analysis and Design: Fundamentals and Best Practices, Lecture notes of Object Oriented Analysis and Design

What does it mean to have a good object design? This book is a tool to help devel- opers and students learn core skills in object-oriented analysis and ...

Typology: Lecture notes

2021/2022

Uploaded on 09/27/2022

kaden
kaden 🇬🇧

5

(3)

221 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Chapter 1
O
BJECT
-
O
RIENTED
A
NALYSIS
AND
D
ESIGN
The shift of focus (to patterns) will have a profound and
enduring effect on the way we write programs.
Ward Cunningham and Ralph Johnson
Objectives
Compare and contrast analysis and design.
Define object-oriented analysis and design (OOA/D).
Illustrate a brief example.
1.1 Applying UML and Patterns in OOA/D
This is an
introduction
What does it mean to have a good object design? This book is a tool to help devel-
opers and students learn core skills in object-oriented analysis and design
(OOA/D). These skills are essential for the creation of well-designed, robust, and
maintainable software using object technologies and languages such as Java,
C++, Smalltalk, and C#.
The proverb "owning a hammer doesn't make one an architect" is especially true
with respect to object technology. Knowing an object-oriented language (such as
Java) is a necessary but insufficient first step to create object systems. Knowing
how to "think in objects" is also critical.
This is an introduction to OOA/D while applying the Unified Modeling Lan-
guage (UML), patterns, and the Unified Process. It is not meant as an advanced
text; it emphasizes mastery of the fundamentals, such as how to assign respon-
sibilities to objects, frequently used UML notation, and common design pat-
From Craig Larman, Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design, and the Unified Process. 2nd Edition.
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Object-Oriented Analysis and Design: Fundamentals and Best Practices and more Lecture notes Object Oriented Analysis and Design in PDF only on Docsity!

Chapter 1

OBJECT-ORIENTED ANALYSIS AND

DESIGN

The shift of focus (to patterns) will have a profound and

enduring effect on the way we write programs.

— Ward Cunningham and Ralph Johnson

Objectives

  • Compare and contrast analysis and design.
  • Define object-oriented analysis and design (OOA/D).
  • Illustrate a brief example.

1.1 Applying UML and Patterns in OOA/D

This is an

introduction

What does it mean to have a good object design? This book is a tool to help devel-

opers and students learn core skills in object-oriented analysis and design

(OOA/D). These skills are essential for the creation of well-designed, robust, and

maintainable software using object technologies and languages such as Java,

C++, Smalltalk, and C#.

The proverb "owning a hammer doesn't make one an architect" is especially true

with respect to object technology. Knowing an object-oriented language (such as

Java) is a necessary but insufficient first step to create object systems. Knowing

how to "think in objects" is also critical.

This is an introduction to OOA/D while applying the Unified Modeling Lan-

guage (UML), patterns, and the Unified Process. It is not meant as an advanced

text; it emphasizes mastery of the fundamentals, such as how to assign respon-

sibilities to objects, frequently used UML notation, and common design pat-

1 - OBJECT-ORIENTED ANALYSIS AND DESIGN

Applying UML

Applying patterns

and assigning

responsibilities

One case study

Use cases and

requirements

analysis

An example

iterative process —

the Unified Process

terns. At the same time, primarily in later chapters, the material progresses to a few intermediate-level topics, such as framework design.

The book is not just about the UML. The UML is a standard diagramming nota- tion. As useful as it is to learn notation, there are more critical object-oriented things to learn; specifically, how to think in objects—how to design object-ori- ented systems. The UML is not OOA/D or a method, it is simply notation. It is not so helpful to learn syntactically correct UML diagramming and perhaps a UML CASE tool, but then not be able to create an excellent design, or evaluate and improve an existing one. This is the harder and more valuable skill. Conse- quently, this book is an introduction to object design. Yet, one needs a language for OOA/D and "software blueprints," both as a tool of thought and as a form of communication with others. Therefore, this book explores how to apply the UML in the service of doing OOA/D, and covers fre- quently used UML notation. But the emphasis is on helping people learn the art and science of building object systems, rather than notation.

How should responsibilities be allocated to classes of objects? How should objects interact? What classes should do what? These are critical questions in the design of a system. Certain tried-and-true solutions to design problems can be (and have been) expressed as best-practice principles, heuristics, or pat- terns —named problem-solution formulas that codify exemplary design princi- ples. This book, by teaching how to apply patterns, supports quicker learning and skillful use of these fundamental object design idioms.

This introduction to OOA/D is illustrated in a single case study that is fol- lowed throughout the book, going deep enough into the analysis and design so that some of the gory details of what must be considered and solved in a realistic problem are considered, and solved.

OOA/D (and all software design) is strongly related to the prerequisite activity of requirements analysis, which includes writing use cases. Therefore, the case study begins with an introduction to these topics, even though they are not specifically object-oriented.

Given many possible activities from requirements through to implementation, how should a developer or team proceed? Requirements analysis and OOA/D needs to be presented in the context of some development process. In this case, the well-known Unified Process is used as the sample iterative develop- ment process within which these topics are introduced. However, the analysis and design topics that are covered are common to many approaches, and learn- ing them in the context of the Unified Process does not invalidate their applica- bility to other methods.

1 - OBJECT- ORIENTED ANALYSIS AND DESICN

1.2 Assigning Responsibilities

There are many possible activities and artifacts in introductory OOA/D, and a

wealth of principles and guidelines. Suppose we must choose a single practical

skill from all the topics discussed here—a "desert island" skill. What would it

be?

A critical, fundamental ability in OOA/D is to skillfully assign responsibilities

to software components.

Why? Because it is one activity that must be performed—either while drawing a

UML diagram or programming—and it strongly influences the robustness,

maintainability, and reusability of software components.

Of course, there are other necessary skills in OOA/D, but responsibility assign-

ment is emphasized in this introduction because it tends to be a challenging

skill to master, and yet vitally important. On a real project, a developer might

not have the opportunity to perform any other analysis or design activities—the

"rush to code" development process. Yet even in this situation, assigning respon-

sibilities is inevitable.

Consequently, the design steps in this book emphasize principles of responsibil-

ity assignment.

Nine fundamental principles in object design and responsibility assignment

are presented and applied. They are organized in a learning aid called the

GRASP patterns.

1.3 What Is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather

than a solution. For example, if a new computerized library information system

is desired, how will it be used?

"Analysis" is a broad term, best qualified, as in requirements analysis (an inves-

tigation of the requirements) or object analysis (an investigation of the domain

objects).

Design emphasizes a conceptual solution that fulfills the requirements, rather

than its implementation. For example, a description of a database schema and

software objects. Ultimately, designs can be implemented.

WHAT Is OBJECT-ORIENTED ANALYSIS AND DESIGN?

As with analysis, the term is best qualified, as in object design or database

design.

Analysis and design have been summarized in the phase do the right thing

(analysis), and do the thing right (design).

1.4 What Is Object-Oriented Analysis and Design?

During object-oriented analysis, there is an emphasis on finding and describ-

ing the objects—or concepts—in the problem domain. For example, in the case

of the library information system, some of the concepts include Book, Library,

and Patron.

During object-oriented design, there is an emphasis on defining software

objects and how they collaborate to fulfill the requirements. For example, in the

library system, a Book software object may have a title attribute and a

getChap-ter method (see Figure 1.2).

Finally, during implementation or object-oriented programming, design objects

are implemented, such as a Book class in Java.

Figure 1.2 Object-orientation emphasizes representation of objects.

1.5 An Example

Before diving into the details of requirements analysis and

OOA/D, this section presents a birds-eye view of a few key

steps and diagrams, using a simple example—a "dice

game" in which a player rolls two die. If the total is seven,

they win; otherwise, they lose.

Book title

public class Book { private String title;

public Chapter getChapter(int) {...} }

domain concept visualization of domain concept

representation in an object-oriented programming language

AN EXAMPLE

This model illustrates the noteworthy concepts Player, Die, and DiceGame, with

their associations and attributes.

Note that a domain model is not a description of software objects; it is a visual-

ization of concepts in the real-world domain.

Define Interaction Diagrams

Object-oriented design is concerned with defining software objects and their col-

laborations. A common notation to illustrate these collaborations is the interac-

tion diagram. It shows the flow of messages between software objects, and

thus the invocation of methods.

For example, assume that a software implementation of the dice game is

desired. The interaction diagram in Figure 1.4 illustrates the essential step of

playing, by sending messages to instances of the DiceGame and Die classes.

Figure 1.4 Interaction diagram illustrating messages between software objects.

Notice that although in the real world a player rolls the dice, in the software

design the DiceGame object "rolls" the dice (that is, sends messages to Die

objects). Software object designs and programs do take some inspiration from

real-world domains, but they are not direct models or simulations of the real

world.

Define domain model

Define interaction diagrams

Define design Define use cases class diagrams

:DiceGame

play()

die1 : Die

fv1 := getFaceValue()

die2 : Die

roll()

roll()

fv2 := getFaceValue()

1 - OBJECT-ORIENTED ANALYSIS AND DESIGN

Define Design Class Diagrams

In addition to a dynamic view of collaborating objects shown in interaction dia- grams, it is useful to create a static view of the class definitions with a design class diagram. This illustrates the attributes and methods of the classes.

For example, in the dice game, an inspection of the interaction diagram leads to the partial design class diagram shown in Figure 1.5. Since a play message is sent to a DiceGame object, the DiceGame class requires a play method, while class Die requires a roll and getFaceValue method. In contrast to the domain model, this diagram does not illustrate real-world con- cepts; rather, it shows software classes.

Figure 1.5 Partial design class diagram.

Summary

The dice game is a simple problem, presented to focus on a few steps and arti- facts in analysis and design. To keep the introduction simple, not all the illus- trated UML notation was explained. Future chapters explore analysis and design and these artifacts in closer detail.

1.6 The UML

To quote: The Unified Modeling Language (UML) is a language for speci- fying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems [OMG01]. The UML has emerged as the de facto and de jure standard diagramming nota- tion for object-oriented modeling. It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to combine the diagramming notations from their two popu-

Define domain model

Define interaction diagrams

Define design Define use cases class diagrams

2

Die faceValue : int getFaceValue() : int roll()

DiceGame die1 : Die die2 : Die play()

1

1 - OBJECT-ORIENTED ANALYSIS AND DESIGN

for those studying object design. However, it is not an introductory text and is

best read after developing comfort with the fundamentals of object design and

programming.

Chapter 2

ITERATIVE DEVELOPMENT AND

THE UNIFIED PROCESS

People are more important than any process.

Good people with a good process will

outperform good people with no process every time.

— Grady Booch

Objectives

  • Provide motivation for the content and order of subsequent chapters.
  • Define an iterative and adaptive process.
  • Define fundamental concepts in the Unified Process.

Introduction

Iterative development is a skillful approach to software development, and lies at

the heart of how OOA/D is presented in this book. The Unified Process is an

example iterative process for projects using OOA/D, and it shapes the book's

presentation. Consequently, it is useful to read this chapter so that these core

concepts and their influence on the book's structure are clear.

This chapter summarizes a few key ideas; please see Chapter 37 for further dis-

cussion of the UP and iterative process practices.

Informally, a software development process describes an approach to build-

ing, deploying, and possibly maintaining software. The Unified Process

[JBR99] has emerged as a popular software development process for building

object-oriented systems. In particular, the Rational Unified Process or RUP

Figure 2.1 Iterative and incremental development.

Example

As an example (not a recipe), in a two-week iteration half-way through a

project, perhaps Monday is spent primarily on distributing and clarifying the

tasks and requirements of the iteration, while one person reverse-engineers

the last iteration's code into UML diagrams (via a CASE tool), and prints

and displays noteworthy diagrams. Tuesday is spent at whiteboards doing

pair design work drawing rough UML diagrams captured on digital cameras,

and writing some pseudocode and design notes. The remaining eight days

are spent on implementation, testing (unit, acceptance, usability, ...), further

design, integration, daily builds, system testing, and stabilization of the par-

tial system. Other activities include demonstrations and evaluations with

stakeholders, and planning for the next iteration.

Notice in this example that there is neither a rush to code, nor a long drawn-out

design step that attempts to perfect all details of the design before program-

ming. A "little" forethought regarding the design with visual modeling using

rough and fast UML drawings is done; perhaps a half or full day by developers

doing design work in pairs.

The result of each iteration is an executable but incomplete system; it is not

ready to deliver into production. The system may not be eligible for production

deployment until after many iterations; for example, 10 or 15 iterations.

THE MOST IMPORTANT UP IDEA: ITERATIVE DEVELOPMENT

Early iterative process ideas were known as spiral development and evolution-

ary development [Boehm.88, Gilb88].

Requirements

Design Implementation & Test & Integration & More Design Final Integration & System Test

Requirements Design

4 weeks (for example) The system grows incrementally.

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

Iterations are fixed in length, or timeboxed.

Time Implementation & Test & Integration & More Design Final Integration & System Test

2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS

The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system. Although, in general, each iteration tackles new requirements and incremen- tally extends the system, an iteration may occasionally revisit existing software and improve it; for example, one iteration may focus on improving the perfor- mance of a subsystem, rather than extending it with new features.

Embracing Change: Feedback and Adaptation

The subtitle of one book that discusses iterative development is Embrace Change [BeckOO]. This phrase is evocative of a key attitude of iterative develop- ment: Rather than fighting the inevitable change that occurs in software devel- opment by trying (usually unsuccessfully) to fully and correctly specify, freeze, and "sign off" on a frozen requirement set and design before implementation, iterative development is based on an attitude of embracing change and adapta- tion as unavoidable and indeed essential drivers. This is not to say that iterative development and the UP encourages an uncon- trolled and reactive "feature creep"-driven process. Subsequent chapters explore how the UP balances the need—on the one hand—to agree upon and stabilize a set of requirements, with—on the other hand—the reality of changing require- ments, as stakeholders clarify their vision or the marketplace changes. Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing. In early iterations the choice of require- ments and design may not be exactly what is ultimately desired. But the act of swiftly taking a small step, before all requirements are finalized, or the entire design is speculatively defined, leads to rapid feedback—feedback from the users, developers, and tests (such as load and usability tests). This early feedback is worth its weight in gold; rather than speculating on the correct requirements or design, the feedback from realistic building and testing something provides crucial practical insight and an opportunity to modify or adapt understanding of the requirements or design. End-users have a chance to quickly see a partial system and say, "Yes, that's what I asked for, but now that I try it, what I really want is something slightly different." 1 This "yes...but" pro- cess is not a sign of failure; rather, early and frequent structured cycles of "yes...buts" are a skillful way to make progress and discover what is of real value to the stakeholders. Yet, as mentioned, this is not an endorsement of chaotic and reactive development in which developers continually change direction—a mid- dle way is possible. In addition to requirements clarification, activities such as load testing will prove if the partial design and implementation are on the right path, or if in the

1. Or more likely, "You didn't understand what I wanted!"

2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS

Iteration Length and Timeboxing

The UP (and experienced iterative developers) recommends an iteration length between two and six weeks. Small steps, rapid feedback, and adaptation are central ideas in iterative development; long iterations subvert the core motiva- tion for iterative development and increase project risk. Much less than two weeks, and it is difficult to complete sufficient work to get meaningful through- put and feedback; much more than six or eight weeks, and the complexity becomes rather overwhelming, and feedback is delayed. A very long iteration misses the point of iterative development. Short is good. A key idea is that iterations are timeboxed, or fixed in length. For example, if the next iteration is chosen to be four weeks long, then the partial system should be integrated, tested, and stabilized by the scheduled date—date slippage is dis- couraged. If it seems that it will be difficult to meet the deadline, the recom- mended response is to remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date. Chapter 37 summarizes reasons for timeboxing. Massive teams (for example, several hundred developers) may require longer than six-week iterations to compensate for the overhead of coordination and communication; but no more than three to six months is recommended. For example, the successful replacement in the 1990s of the Canadian air traffic control system was developed with an iterative lifecycle and other UP practices. It involved 150 programmers and was organized into six-month iterations.^2 But note that even in the case of an overall six-month project iteration, a subsystem team of 10 or 20 developers can break down their work into a series of six one-month iterations. A six-month iteration is the exception for massive teams, not the rule. To reiter- ate, the UP recommends that normally an iteration should be between two and six weeks in duration.

2.2 Additional UP Best Practices and Concepts

The central idea to appreciate and practice in the UP is short timeboxed itera-

tive, adaptive development.

Another implicit, but core, UP idea is the use of object technologies, including

OOA/D and object-oriented programming.

2. Philippe Kruchten, who also led the development of the RUP, served as chief architect

for the project.

THE UP PHASES AND SCHEDULE-ORIENTED TERMS

Some additional best practices and key concepts in the UP include:

  • tackle high-risk and high-value issues in early iterations
  • continuously engage users for evaluation, feedback, and requirements
  • build a cohesive, core architecture in early iterations
  • continuously verify quality; test early, often, and realistically
  • apply use cases
  • model software visually (with the UML)
  • carefully manage requirements
  • practice change request and configuration management

See Chapter 37 for a more detailed description of these practices.

2.3 The UP Phases and Schedule-Oriented Terms

A UP project organizes the work and iterations across four major phases:

1. Inception — approximate vision, business case, scope, vague estimates.

2. Elaboration —refined vision, iterative implementation of the core architec

ture, resolution of high risks, identification of most requirements and scope,

more realistic estimates.

3. Construction —iterative implementation of the remaining lower risk and

easier elements, and preparation for deployment.

4. Transition —beta tests, deployment.

These phases are more fully defined in subsequent chapters.

This is not the old "waterfall" or sequential lifecycle of first defining all the

requirements, and then doing all or most of the design.

Inception is not a requirements phase; rather, it is a kind of feasibility phase,

where just enough investigation is done to support a decision to continue or

stop.

Similarly, elaboration is not the requirements or design phase; rather, it is a

phase where the core architecture is iteratively implemented, and high risk

issues are mitigated.

Figure 2.3 illustrates common schedule-oriented terms in the UP. Notice that

one development cycle (which ends in the release of a system into production) is

composed of many iterations.

Figure 2.4 UP disciplines.^4

In the UP, Implementation means programming and building the system, not

deployment. The Environment discipline refers to establishing the tools and

customizing the process for the project—that is, setting up the tool and process

environment.

Disciplines and Phases

As illustrated in Figure 2.4, during one iteration work goes on in most or all dis-

ciplines. However, the relative effort across these disciplines changes over time.

Early iterations naturally tend to apply greater relative emphasis to require-

ments and design, and later ones less so, as the requirements and core design

stabilize through a process of feedback and adaptation.

Relating this to the UP phases (inception, elaboration, ...), Figure 2.5 illustrates

the changing relative effort with respect to the phases; please note these are

suggestive, not literal. In elaboration, for example, the iterations tend to have a

4. Diagram adapted from the RUP product.

THE UP DISCIPLINES (WAS WORKFLOWS)

A longer list of UP disciplines is shown in Figure 2.4.

Iterations

Sample UP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & Change Management

Project Management

Environment

Focus of this book

Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.

This example is suggestive, not literal.

A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.

2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS

relatively high level of requirements and design work, although definitely some

implementation as well. During construction, the emphasis is heavier on imple-

mentation and lighter on requirements analysis.

Book Structure and UP Phases and Disciplines

With respect to the phases and disciplines, what is the focus of the case study?

Answer:

The case study emphasizes the inception and elaboration phase. It focuses

on some artifacts in the Business Modeling, Requirements, and Design disci-

plines, as this is where requirements analysis, OOA/D, patterns, and the

UML are primarily applied.

The earlier chapters introduce activities in inception; later chapters explore sev-

eral iterations in elaboration. The following list and Figure 2.6 describe the

organization with respect to the UP phases.

1. The inception phase chapters introduce the basics of requirements analysis.

2. Iteration 1 introduces fundamental OOA/D and how to assign responsibili

ties to objects.

3. Iteration 2 focuses on object design, especially on introducing some high-use

"design patterns."

4. Iteration 3 introduces a variety of subjects, such as architectural analysis

and framework design.

Figure 2.5 Disciplines and phases

Sample UP Disciplines

Business Modeling

Requirements

Design

Implementation

...

The relative effort in disciplines shifts across the phases.

This example is suggestive, not literal.

incep- tion elaboration^ construction^

transi- tion

...