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
...
