Skip to content
Ahmet Çelik

Chapter 1: OOA/D and the Unified Process

COMP302 14 minute read

Source files used: Lecture 1 - Introduction; textbook (applying-uml-and-patterns.pdf) Chapter 1 as support.

A focused guide to object-oriented analysis and design (OOA/D) and the Unified Process (UP) for the COMP302 Midterm 1. It covers what analysis and design mean, the four-step dice game walkthrough, iterative development, and the UP phases and disciplines. Every later guide reuses these terms, so read this one first.

Roadmap: 1 OOA/D and UP → 2 Inception and Requirements → 3 Use Cases → 4 Domain Models → 5 SSDs and Contracts → 6 Logical Architecture → 7 Interaction Diagrams

Analysis, Design, and OOA/D

What Is Analysis? What Is Design?

Analysis is an investigation of the problem and the requirements, not a solution. Design is a conceptual solution that fulfills the requirements, not its implementation. Both words are best qualified: requirements analysis, object analysis, object design, database design.

Think of it as: analysis asks what the problem is; design decides how to solve it. The textbook’s slogan: do the right thing (analysis), and do the thing right (design).

What Makes It Object-Oriented?

  • OO analysis finds and describes the objects (or concepts) in the problem domain.
  • OO design defines software objects and how they collaborate to fulfill the requirements.

Figure 1.2 in the slides shows the chain for a library: a real book (domain concept) is drawn as a Book box with a title (a visualization of the concept), and that inspires a software class:

public class Book {
    private String title;               // came from the domain concept
    public Chapter getChapter(int n) {...} // behavior only exists in software
}

The Dice Game: OOA/D in Four Steps

Lecture 1 previews the whole course with one tiny example: a player rolls two dice; a total of seven wins, anything else loses. The four steps are the same order the rest of the course follows.

  1. Define use cases. Requirements as stories. Brief version: Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose.
  2. Define a domain model. Real-world concepts, their attributes, and their associations.
  3. Define interaction diagrams. Software objects and the messages between them (a dynamic view).
  4. Define design class diagrams. Software classes with attributes and methods (a static view).

Step 2, the partial domain model (real-world concepts, no methods):

+----------+ 1       Rolls       2 +-----------+
| Player   |-----------------------| Die       |
|----------|                       |-----------|
| name     |                       | faceValue |
+----------+                       +-----------+
     | 1                                 | 2
     | Plays                             |
     | 1                                 |
+----------+ 1       Includes            |
| DiceGame |-----------------------------+
+----------+

Step 3, the interaction diagram (software objects sending messages):

               :DiceGame           die1 : Die          die2 : Die
                   :                   :                   :
  o---play()----->[ ]                  :                   :
                  [ ]  roll()          :                   :
                  [ ]---------------->[ ]                  :
                  [ ]  fv1 := getFaceValue()               :
                  [ ]---------------->[ ]                  :
                  [ ]  roll()                              :
                  [ ]------------------------------------>[ ]
                  [ ]  fv2 := getFaceValue()               :
                  [ ]------------------------------------>[ ]

Step 4, the partial design class diagram (software classes with methods):

+--------------+ 1          2 +----------------------+
| DiceGame     |------------->| Die                  |
|--------------|              |----------------------|
| die1 : Die   |              | faceValue : int      |
| die2 : Die   |              |----------------------|
|--------------|              | getFaceValue() : int |
| play()       |              | roll()               |
+--------------+              +----------------------+

Key Insight: In the real world the player rolls the dice. In the software design, the DiceGame object “rolls” them. Software designs take inspiration from the real-world domain, but they are not direct models or simulations of it.

Exam Trap #1: Mixing up the domain model and the design class diagram.

WRONG   (domain model):  Die: faceValue, roll(), getFaceValue()
CORRECT (domain model):  Die: faceValue        <- concepts and attributes only
CORRECT (design class):  Die: faceValue : int, getFaceValue() : int, roll()

The domain model is a visualization of real-world concepts; the design class diagram shows software classes. Guide 4 covers the full rules.

UML in One Paragraph

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The OMG (Object Management Group) adopted it as a standard in 1997. The textbook stresses that the UML is not OOA/D or a method; it is simply notation. Knowing how to design good objects is the harder and more valuable skill, and a process such as the UP gives that work its structure.

Iterative Development and the UP

What Is the Unified Process?

A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process (UP) is a popular iterative process for building object-oriented systems. The Rational Unified Process (RUP) is a detailed refinement of the UP.

The course uses the UP for two reasons: it is iterative, and its practices give a structure for learning OOA/D. The single most important UP idea is iterative development.

What Is an Iteration?

Development is organized into a series of short, fixed-length mini-projects called iterations (for example, four weeks).

  • Each iteration includes its own requirements analysis, design, implementation, and testing.
  • The outcome of each iteration is a tested, integrated, and executable system.
  • That system is incomplete and not ready for production; it may take 10 or 15 iterations before it is.
  • The output is a production-grade subset of the final system, not a throw-away prototype.
  • An iteration may revisit existing software to improve it (for example, performance) instead of adding features.

Exam Trap #2: “Iterative development is prototyping.” It is not. Each iteration produces production-quality code that stays in the system and is extended later.

Feedback and Adaptation

Each iteration picks a small subset of the requirements and quickly designs, implements, and tests it. Early choices may not be exactly what is wanted, but taking a small step before everything is finalized produces rapid feedback from users, developers, and tests.

Work therefore proceeds through structured build-feedback-adapt cycles. Early iterations deviate more from the “true path” of the system; over time the requirements and design become stable and the system converges.

Benefits of Iterative Development

  • early rather than late mitigation of high risks (technical, requirements, objectives, usability),
  • early visible progress,
  • early feedback, user engagement, and adaptation, so the system meets the real needs of stakeholders,
  • managed complexity, with no “analysis paralysis”,
  • learning within an iteration improves the process itself, iteration by iteration.

Iteration Length and Timeboxing

The UP recommends iterations of two to six weeks. Long iterations subvert the core motivation of iterative development and increase project risk.

Iterations are timeboxed (fixed in length). If an iteration is four weeks, the partial system must be integrated, tested, and stabilized by that date.

Exam Trap #3: Slipping the date when an iteration runs late.

WRONG:   "We are behind, so iteration 3 ends two weeks later."
CORRECT: "We are behind, so we move some tasks or requirements to iteration 4."

UP Best Practices

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

What About the Waterfall Lifecycle?

The waterfall lifecycle is sequential: define all or most requirements in detail before programming, and often create a thorough design before programming too. Research shows it is poor practice for most software projects. The lecture’s chart shows why: the share of requirements that change grows with project size, so up-front requirements go stale.

Guideline: Don’t let waterfall thinking invade an iterative or UP project. “Let’s write all the use cases before starting to program” and “let’s do many detailed OO models in UML before starting to program” are both unhealthy waterfall thinking.

UP Phases and Disciplines

The Four Phases

PhaseWhat happens
Inceptionapproximate vision, business case, scope, vague estimates
Elaborationrefined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates
Constructioniterative implementation of the remaining lower-risk and easier elements, preparation for deployment
Transitionbeta tests, deployment
  • Inception is not a requirements phase. It is a feasibility phase: just enough investigation to support a decision to continue or stop.
  • Elaboration is not the requirements or design phase. It is where the core architecture is iteratively implemented and high-risk issues are mitigated.

Exam Trap #4: Mapping the phases onto waterfall stages.

WRONG:   inception = requirements, elaboration = design,
         construction = implementation
CORRECT: each phase is made of iterations, and each iteration includes work in
         most disciplines (requirements, design, implementation, test)

Schedule Terms

TermMeaning
development cyclethe full run from inception to transition, ending in the final production release
phaseinception, elaboration, construction, or transition; each is made of iterations
iterationone timeboxed mini-project
milestonean iteration end point where some significant decision or evaluation occurs
releasea stable executable subset of the final product; the end of each iteration is a minor release
incrementthe difference (delta) between the releases of two subsequent iterations
final production releasethe point where the system is released for production use

Disciplines and Artifacts

A discipline is a set of activities (and related artifacts) in one subject area, such as the activities within requirements analysis. An artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models.

The UP disciplines from the lecture figure:

  • Business Modeling (for one application, this is domain object modeling),
  • Requirements (for example, writing use cases and identifying non-functional requirements),
  • Design (architecture, objects, databases, networking),
  • Implementation,
  • Test,
  • Deployment,
  • Configuration & Change Management,
  • Project Management,
  • Environment.

The textbook focuses on the first three. Two definitions the slides stress:

  • Implementation means programming and building the system, not deployment.
  • Environment means establishing the tools and customizing the process for the project.

Disciplines Across the Phases

An iteration includes work in most disciplines, but the relative effort and emphasis shift over time. Business modeling and requirements effort is highest early; implementation and deployment effort grows in later iterations. The slides note that this picture is suggestive, not literal.

Exam Trap #5: Confusing phases with disciplines. Phases are time segments (inception, elaboration, construction, transition). Disciplines are activity areas (requirements, design, test, …) that run across all phases.

Agile Methods and the UP

Agile in a Nutshell

Agile development methods apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and encourage rapid and flexible response to change.

  • Scrum: a common project workroom and self-organizing teams that coordinate through a daily stand-up meeting with special questions each member answers.
  • Extreme Programming (XP): programming in pairs and test-driven development.

The Agile Manifesto:

Valueover
individuals and interactionsprocesses and tools
working softwarecomprehensive documentation
customer collaborationcontract negotiation
responding to changefollowing a plan

Signs You Did Not Understand the UP

The lecture lists these warning signs (shortened):

  • you think inception = requirements, elaboration = design, construction = implementation,
  • you think elaboration is for fully defining models that are then translated into code,
  • you try to define most of the requirements, or most of the design, before implementation,
  • a “long time” is spent on requirements or design before programming starts,
  • you think a suitable iteration is four months long rather than four weeks,
  • you think UML diagramming means defining designs in great detail, with programming as mechanical translation,
  • you think adopting the UP means doing many activities and creating many documents,
  • you try to plan the whole project in detail, or want believable plans and estimates before elaboration is finished.

Exam-Style Practice Problems

Problem 1: Short Lists

Question: The Fall 2024 Midterm 1 study sheet asks for short answers: (a) What are the different UP phases? (b) What are the different UP disciplines?

Answer:

(a) Inception, Elaboration, Construction, Transition
(b) Business Modeling, Requirements, Design, Implementation, Test, Deployment,
    Configuration & Change Management, Project Management, Environment

Problem 2: Define the Terms

Question: Explain “inception phase” and “iteration” (both are on the study sheet’s term list).

Answer:

  • Inception phase: the short first UP phase that sets an approximate vision, business case, scope, and vague estimates, so the team can decide whether to continue. It is a feasibility phase, not the requirements phase.
  • Iteration: a short, timeboxed mini-project (two to six weeks) that includes requirements, design, implementation, and testing, and ends in a tested, integrated, executable but incomplete system.

Problem 3: Spot the Waterfall Thinking

Question: A team’s plan: “Months 1-2: write every use case in fully dressed format. Months 3-4: draw all class and sequence diagrams. Months 5-8: code. Month 9: test.” Name two problems.

Answer:

  • It is waterfall thinking: all requirements and all design are finished before any programming, so there is no feedback until late.
  • There are no timeboxed iterations that end in tested, executable systems, so high risks surface late and requirement changes pile up.

Common Exam Traps

1. Inception Is Not the Requirements Phase

WRONG:   "In inception we write all the requirements."
CORRECT: "In inception we explore feasibility and set a common vision."

Why: Inception only supports a decision to continue or stop (Guide 2 gives the details).

2. Phases Are Not Waterfall Stages

WRONG:   elaboration = the design phase
CORRECT: elaboration = iteratively build the core architecture and retire high risks

Why: Iterations in every phase mix requirements, design, implementation, and test work.

3. Iterations Are Not Prototypes

WRONG:   "Iteration 1 builds a throw-away prototype."
CORRECT: "Iteration 1 builds a production-grade, tested subset of the system."

Why: Iteration output is kept and extended, not discarded.

4. Timeboxes Do Not Slip

WRONG:   extend the end date of the iteration
CORRECT: keep the date; move requirements to a later iteration

Why: Fixed lengths keep feedback fast and risk low.

5. Iterations Last Weeks, Not Months

WRONG:   four-month iterations
CORRECT: two to six weeks

Why: Long iterations defeat the purpose of small steps and rapid feedback.

6. Implementation Is Not Deployment

WRONG:   Implementation discipline = installing the system for users
CORRECT: Implementation = programming and building;
         Deployment is a separate discipline

Why: The slides define Implementation explicitly as programming and building.

7. Domain Model Is Not a Design Class Diagram

WRONG:   real-world Die concept drawn with roll() and getFaceValue()
CORRECT: domain model: Die with faceValue; design class diagram: Die with methods

Why: Methods are a software concept; the domain model shows real-world concepts.

8. Software Is Not a Simulation of the Real World

WRONG:   "The Player object must roll the dice, because players roll dice."
CORRECT: "DiceGame rolls the dice; the design is only inspired by the domain."

Why: Software objects get responsibilities that make the design work, not ones that copy reality.

Final Tips for the Midterm

  • Know the four phases in order: Inception, Elaboration, Construction, Transition, with one line each.
  • Know the nine disciplines: plus the two definitions the slides stress (Implementation and Environment).
  • Use the precise words for an iteration: short, timeboxed, tested, integrated, executable, production-grade subset.
  • Explain analysis vs design as what vs how: then add the OO version (domain concepts vs collaborating software objects).
  • Remember the dice game order: use cases, domain model, interaction diagrams, design class diagrams. Guides 3 to 7 follow it.
  • Hunt for waterfall thinking: any plan that finishes all requirements or all design before coding is wrong for the UP.

Good luck on the midterm! You’ve got this.