Preface

This book, Object-Oriented Software Engineering: A Student’s Guide, is designed to help

undergraduate computer science and information technology students understand the
fundamental principles of software engineering and the object-oriented approach to system
development.

This book is based on:

 Lecture materials prepared by Prof. Moheb Ramzy Girgis.

 Software Engineering A practitioner's Approach, Author: Roger S. Pressman, Publisher:
McGraw Hill
 Applying UML and Patterns An Introduction to Object Oriented Analysis and Design and
the Unified Process, Authors: Craig Larman and Philippe Kruchten, Publisher:
Prentice Hall

They have been adapted into a clear, student-friendly textbook format to support self-study
and classroom use.

The aim of this book is to simplify complex ideas and present them in a way that’s easy to
follow — combining conceptual understanding with practical examples and illustrations.

Every chapter introduces a key aspect of software engineering:

 From understanding software systems and the software crisis,

 To mastering object-oriented principles,
 Learning how to model systems with UML,
 And finally, understanding the Unified Process (UP) and its Inception Phase.

Whether you are studying software engineering for the first time or reviewing for exams, this
book provides the foundation you need to think like a software engineer and design systems
using object-oriented principles.
Introduction

Software has become an essential part of modern life — powering everything from smartphones
and banking systems to transportation and healthcare.
As systems have grown larger and more complex, the need for a disciplined, systematic
approach to software development has become critical. This is where Software Engineering
comes in.

Software engineering combines the creativity of programming with the structure and discipline
of engineering.
It focuses on planning, design, testing, and maintenance, ensuring that software is not only
functional but also reliable, efficient, and maintainable.

Over the years, new methodologies have been developed to improve the way we design and
build software.
Among these, the object-oriented approach has proven to be one of the most powerful and
effective.
By thinking in terms of objects, classes, and relationships, developers can model real-world
systems in a natural and reusable way.

To communicate these designs, engineers use the Unified Modeling Language (UML) — a
universal language for describing systems visually.
Finally, to guide the entire process, the Unified Process (UP) provides a structured framework
for iterative and incremental development.
 Chapter 1: Introduction to Software Engineering

1.1 What is Software Engineering?

Software engineering is the discipline concerned with the systematic development of software
systems.
It involves not only writing code but also designing, building, testing, and maintaining
software in an organized and reliable way.

The goal of software engineering is to bring discipline and structure to software

development—so that complex systems can be built and maintained efficiently and effectively
over time.

1.2 Computer-Based Systems (CBS)

A computer-based system (CBS) is a collection of components that work together to achieve a

specific goal by processing information.
This goal might be:

 Supporting a business process (like payroll or inventory), or

 Producing a product that can be sold to generate revenue.

A CBS typically includes several interconnected elements:

 Software – the programs and data structures that perform logical and control operations.
 Hardware – electronic devices (like CPUs, sensors, or motors) that provide computing
and physical functions.
 People – users, operators, and maintainers who interact with the system.
 Database – organized collections of data accessed through software.
 Documentation – manuals and materials describing how the system works.
 Procedures – the steps or rules that describe how to use or operate the system.
 Figure 1: Elements of a Computer-Based System

CBSs can also be part of larger systems.

For example, a factory automation system may include manufacturing machines, inventory
control software, and robotic systems, all interacting as part of one big CBS.
 Factory Automation System

Manufacturing Inventory Information

System System System

Material Manufacturing
Movement Cells
System

Numerical Robots Data Entry

Control Devices
Machine

Figure 2: Example – Factory Automation System as a CBS

1.3 Software Characteristics

Software can be described as a combination of:

1. Programs – that provide the desired functions when executed,

2. Data structures – that allow efficient manipulation of information, and
3. Documentation – that explains how to operate and maintain the system.

Good software must therefore be functional, well-documented, and maintainable.

1.4 Reusable Software Components

Reusability is one of the most important characteristics of high-quality software.
Reusable components allow engineers to focus on innovation instead of rewriting basic
functionality each time.

For instance, modern systems often include reusable graphical components like buttons, menus,
and forms.
By reusing these building blocks, developers can build complex applications faster and more
reliably.

1.5 The Software Crisis

As computers became more powerful and widely used, a major problem emerged in the software
industry — known as the software crisis.

This crisis refers to the increasing difficulty of developing, maintaining, and managing
software systems effectively.

Main Causes of the Software Crisis

1. Hardware improved much faster than software development methods.

2. The demand for software grew faster than our ability to produce it.
3. Society became highly dependent on reliable software — and failures caused serious
problems.
4. Poor design and maintenance led to fragile and hard-to-update programs.
5. Software often arrived late, over budget, and full of errors.

Underlying Reasons

 Programming techniques could not keep up with growing complexity.

 Many programmers lacked formal training in software design.
 Projects often tried to fix delays by adding more programmers — which usually made
things worse.
Because of these issues, it became clear that new techniques and methodologies were needed
— leading to the birth of Software Engineering.

1.6 The Birth of Software Engineering

In 1968, a conference was held to discuss these challenges.

During this meeting, the term “Software Engineering” was first introduced — to describe the
process of applying engineering principles to software development.

Definition:

“Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.”

Key Attributes of Well-Engineered Software

 Meets user requirements

 Is cost-effective
 Has an easy and appropriate user interface
 Is maintainable
 Is reliable and efficient

1.7 Key Elements of Software Engineering

Software engineering consists of three main elements:

1. Methods – the technical “how-to” approaches for building software (e.g., requirements
analysis, coding, testing).
2. Process – defines the order in which methods are applied, the deliverables produced, and
the milestones used to track progress.
 3. Tools – software aids that support the methods and processes (e.g., IDEs, testing tools,
and CASE systems).

Computer-Aided Software Engineering (CASE)

CASE tools integrate software, hardware, and repositories to automate parts of software
development — much like how CAD/CAE tools are used in mechanical or electrical
engineering.

1.8 Software Engineering Activities

Regardless of project size or complexity, the main software engineering activities can be grouped
into three generic phases:

1. Definition Phase (What to build)

Focuses on understanding what the system should do, including:

 The data to be processed

 The required functions and performance
 Expected system behavior and constraints
 Validation criteria for success

Key tasks:

 System Analysis
 Project Planning
 Requirements Analysis

2. Implementation Phase (How to build it)

Focuses on designing and creating the system, including:

  Structuring data
 Designing architecture and interfaces
 Writing code
 Testing the implementation

Key tasks:

 Software Design
 Code Generation
 Software Testing

3. Maintenance Phase (Change and improvement)

After delivery, software must adapt to new needs or fix problems.

Four main types of maintenance:

1. Correction – fixing errors discovered by users.

2. Adaptation – updating software to match changes in hardware or environment.
3. Enhancement – adding new features.
4. Re-engineering – restructuring code for better maintainability.

1.9 Software Engineering Models

To manage development systematically, engineers use process models — structured strategies

that describe how methods, tools, and phases fit together.
Choosing a model depends on:

 Project type and complexity

 Tools and methods available
 Required controls and deliverables

Common models include:

 1. The Classic Life Cycle (Waterfall) Model
2. The Prototyping Model
3. The Unified Process Model

1.10 The Classic Life Cycle Model (Waterfall Model)

The Waterfall Model is the oldest and most traditional approach.

It proceeds step by step from requirements → design → coding → testing → maintenance,
like a waterfall flowing downward.

Figure 3: The Classic (Waterfall) Model

Key Stages:

1. System Engineering and Analysis – define overall system requirements and assign part
of them to software.
2. Requirements Analysis – understand data, functions, performance, and interfaces.
3. Design – define the architecture, data structures, and algorithms.
4. Code Generation – translate design into code.
5. Testing – verify that the system works correctly.
6. Maintenance – handle post-delivery changes and improvements.

Although simple, this model has a limitation: once a stage is completed, returning to a previous
one is difficult.
1.11 The Prototyping Model

The Prototyping Model helps when requirements are unclear or still evolving.
Developers create a prototype — an early, simplified version of the software — to visualize
ideas and gather feedback from users.

Typical Steps:

1. Requirements Gathering – developer and user outline overall goals.

2. Quick Design – build a rough version of the system’s interface or main functions.
3. Build Prototype – develop a working model.
4. Evaluate Prototype – users test it and suggest improvements.
5. Engineer the Final Product – the prototype is refined or rebuilt properly based on
lessons learned.

Figure 4: The Prototyping Model Cycle

This iterative process continues until both developer and user agree on the final system
requirements.

1.12 The Unified Process Model

The Unified Process (UP) is a modern software development model designed especially for
object-oriented systems.
It promotes iterative development — building the system in small, manageable steps (called
iterations), each producing a working subsystem.

Each iteration includes:

 Requirements analysis
 Design
 Implementation
 Testing

Over time, the system grows gradually and becomes more refined with each iteration.

1.13 Chapter Summary

In this chapter, we learned that:

 Software engineering is about applying disciplined engineering methods to software

creation.
 Computer-based systems include software, hardware, people, and procedures.
 Software must be reliable, maintainable, and reusable.
 The software crisis led to the need for structured engineering methods.
 Software engineering combines methods, processes, and tools.
 The main phases are definition, implementation, and maintenance.
 Different process models exist — such as the Waterfall, Prototyping, and Unified
Process — each with its strengths and applications.
 Chapter 2: Object-Oriented Concepts

2.1 Introduction

The object-oriented (OO) approach to software development is a way to design and build
systems by thinking in terms of objects — just like we think about things in the real world.
Instead of focusing on steps or procedures, OO development focuses on identifying objects,
their attributes (data), and their behaviors (actions).

This approach breaks complex systems into smaller, manageable, and reusable parts that interact
with each other.

Example: In a hospital system, we can think of objects like Doctor, Patient, and Appointment —
each having specific data and actions.

2.2 Objects

An object represents a person, place, thing, or concept that we need to model in software.
Objects are the building blocks of an OO system.

Each object has two main parts:

 Attributes (or properties): Data that describes the object (e.g., a patient’s name, age,
and address).
 Methods (or behaviors): Actions the object can perform (e.g., schedule an appointment,
update information).

The state of an object is determined by the values of its attributes and its relationships with other
objects at a given time.

Example:

 Object: Appointment
  Attributes: date, time, doctor, patient
 Methods: schedule(), cancel(), reschedule()

Figure 1: Example of an Object with Attributes and Methods

2.3 Classes

A class is a template or blueprint that defines the structure and behavior of similar objects.
While an object is a single instance, a class describes what all those instances have in common.

Example:
The Car class defines general attributes and operations common to all cars, like color, speed, and
the ability to start or stop.
Specific cars — like a Toyota or BMW — are objects (instances) of that class.

Class: Car
Attributes: color, speed
Methods: start(), stop(), accelerate()

(A Class defines the structure; an Object is a single instance of it.)

2.4 Encapsulation

Encapsulation means bundling an object’s data and the methods that operate on that data into a
single unit.
This concept keeps the internal details of an object hidden from the outside world, exposing only
what’s necessary.

Benefits of Encapsulation

1. Modularity:
o Each object’s code is independent from others, making systems easier to
maintain.
2. Information Hiding:
o An object’s internal data can only be accessed or modified through its defined
methods.
o This reduces dependency between parts of the system.

Example:
A BankAccount object hides the balance variable. Users interact with it only through deposit()
and withdraw() methods.

Figure 2: Encapsulation – Combining Data and Methods inside an Object

Encapsulation improves cohesion (objects do one clear task) and reduces coupling (objects don’t
depend too heavily on each other).
2.5 Inheritance

Inheritance allows one class to inherit attributes and methods from another class.
This enables reuse of existing code and creates a logical hierarchy among classes.

How It Works

 The superclass (or parent class) defines general attributes and operations.
 The subclass (or child class) inherits these and can add its own new features.

Example:
A Person class may define common attributes like name and address.
A Doctor class and a Patient class can inherit from Person while adding unique details (like
specialization or medical history).

Figure 3: Class Hierarchy Example

(Person → Doctor, Patient)

Concrete vs. Abstract Classes

  A concrete class can create real objects (instances).
 An abstract class defines common structure or behavior but cannot be instantiated; it
serves as a base for other classes.

2.6 Abstract Classes

An abstract class provides a general idea for a group of related classes but doesn’t represent a
complete object itself.
It often includes abstract methods — methods declared but not implemented.
Subclasses must implement these methods to become concrete.

Example:

class Shape {
virtual void Draw() = 0; // abstract method
};

class Circle : public Shape {

void Draw() { /* code to draw a circle */ }
};

Here, Shape is abstract because it defines a generic concept of drawing, while Circle provides
the actual implementation.
 Figure 4: Abstract Class and Derived Implementation

Abstract classes are useful for defining generic behaviors shared by multiple related classes.

2.7 Relationships between Classes

Beyond inheritance, classes can have several other relationships:

1. Aggregation ("has-a" relationship)

Used when one class is made up of other classes.

Example: A Car has-a Engine and has-a Wheel.

2. Composition (stronger form of aggregation)

Represents ownership — if the whole is destroyed, its parts are destroyed too.
Example: A ChessBoard consists of Squares. If the board is deleted, the squares disappear too.

3. Association

A general link between two classes that aren’t dependent on each other.
Example:

 A Student borrows a Book.

 A Person works for a Company.

2.8 Messages

In OO systems, objects communicate with each other by sending messages.

A message tells an object to execute one of its methods.

A message contains:
 1. The object that receives the message,
2. The name of the method to call,
3. Any parameters (inputs) needed.

Example:
[Link](lowGear)
Here, the object John (a Person) sends a message to the Car object to perform the
changeGears() method.

Figure 5: Message Passing Between Objects

This is how collaboration between objects happens in software.

2.9 Polymorphism

Polymorphism means “many forms.”

In programming, it allows different classes to respond differently to the same message or
method call.

This feature enables flexible and extensible systems.

Example:

class Shape {
virtual void Draw() = 0;
};

class Circle : public Shape {

void Draw() { /* draw circle */ }
};

class Rectangle : public Shape {

void Draw() { /* draw rectangle */ }
};

When the method DrawShape(Shape& s) calls [Link](), the system automatically runs
the correct Draw() for the actual shape (circle or rectangle).

Polymorphism lets developers design generic functions that work with different object types,
improving flexibility and code reuse.

2.10 Benefits of Object-Oriented Technologies (OTs)

Object-oriented technologies offer several practical advantages:

1. Reusability – Once an object or class is written, it can be reused in other applications.

2. Maintainability – OO systems are modular; changes in one part cause minimal effects
elsewhere.
3. Scalability – Large systems can be built by assembling smaller, reusable subsystems.
4. Adaptability – OO software can easily evolve as requirements change.

Overall, OO design leads to faster development, better organization, and higher-quality

programs.

2.11 Object-Oriented Analysis and Design (OOAD)

Many methodologies have been developed to support OO analysis and design, including:

 Shlaer and Mellor’s Method

 Coad and Yourdon’s Method
  Booch Method
 Rumbaugh’s OMT (Object Modeling Technique)
 Jacobson’s OOSE (Object-Oriented Software Engineering)

These methods help developers identify objects, define relationships, and model system behavior
in a structured way.

2.12 UML and the Unified Process

Three pioneers in OO design — Rumbaugh, Booch, and Jacobson — combined their methods
to create the Unified Modeling Language (UML) in 1997.
UML became the standard language for modeling object-oriented systems.

Later, they also developed the Unified Process (UP) — a framework for OO software
engineering using UML diagrams.

Today, UML and UP are widely used in software projects to visualize, design, and document
object-oriented systems.

2.13 Chapter Summary

In this chapter, we learned:

 The object-oriented approach models software as a set of objects interacting with each
other.
 Classes define the blueprint for creating objects.
 Encapsulation hides data and behavior within objects, improving reliability.
 Inheritance allows code reuse and hierarchy creation.
 Polymorphism lets objects respond differently to the same message.
 Relationships between classes (aggregation, composition, association) define system
structure.
 Object-oriented technologies lead to reusability, maintainability, and scalability.
 UML and the Unified Process provide the foundation for modern OO design.
 Chapter 3: Introduction to the UML

3.1 What is UML?

The Unified Modeling Language (UML) is a standard language used to visualize, design,
construct, and document software systems — especially object-oriented systems.

UML helps software engineers create blueprints for systems before writing code.
It allows developers, analysts, and even clients to communicate ideas clearly through diagrams
rather than long written descriptions.

In simple terms, UML is to software what architectural blueprints are to buildings.

UML can also be used beyond programming — for business modeling and describing non-
software systems — because it focuses on processes, interactions, and structure.

3.2 Components of UML

UML provides a variety of graphical elements (such as boxes, arrows, and symbols) that
represent different aspects of a system.
These elements combine to form diagrams, each showing a different view or perspective.

When all the diagrams of a system are put together, they form a model.

 Each diagram shows a specific part of the system (structure, behavior, flow, etc.).
 The model represents the system as a whole.

A UML model describes what the system should do, not how to implement it.

3.3 Common UML Diagrams

UML includes many types of diagrams, but the most commonly used are:

Diagram Type Purpose

Class Diagram Shows classes and their relationships.
Object Diagram Shows specific objects (instances) and their relationships.
Use Case Diagram Describes how users (actors) interact with the system.
State Diagram Shows how an object changes states over time.
Sequence Diagram Displays the order of messages between objects.
Activity Diagram Describes workflows or business processes.
Collaboration Diagram Shows object interactions and message flow.
Component Diagram Represents system components and their connections.
Deployment Diagram Shows hardware nodes and software deployment.

Other UML features include:

 Packages – for grouping related elements.

 Notes – for explanations or comments.
 Stereotypes – for extending UML with custom symbols.

3.4 Class Diagram

A class diagram is a static model that shows the structure of a system by displaying its classes,
attributes, operations (methods), and relationships.

Each class is drawn as a box with three sections:

+------------------+
| Class Name |
+------------------+
| Attributes |
+------------------+
| Operations |
+------------------+

Classes are then connected by lines showing how they relate to each other (e.g., inheritance,
association).

Figure 1: UML Class Diagram Structure

Example

In a hospital appointment system, classes might include:

 Doctor
 Patient
 Appointment

These classes connect through relationships such as “Patient schedules Appointment with
Doctor.”
3.5 Object Diagram

An object diagram shows a snapshot of objects (real instances of classes) and their
relationships at a specific moment in time.

While a class diagram shows general structure, an object diagram shows actual examples of
how those classes interact during runtime.

Example:

john : Patient
dr_smith : Doctor
app1 : Appointment

These objects illustrate one real-world situation, such as “John has an appointment with Dr.
Smith.”

Figure 2: Example of an Object Diagram

3.6 Use Case Diagram

A use case diagram helps describe the functional requirements of a system — what the system
does from the user’s perspective.

Each use case represents a specific goal or function the user can perform.
Each actor represents someone or something that interacts with the system (like a person,
another system, or a device).
 Figure 3: Use Case Diagram Components

Example:
In an appointment system, use cases might include:

 Schedule Appointment
 Cancel Appointment
 View Patient Details

Actors could include Doctor and Patient.

 Figure 4: Use Case Diagram for Appointment System

Use case diagrams help developers and clients agree on what the system will do before
implementation.

3.7 Relationships in Use Case Diagrams

Use cases can relate to each other in special ways:

 «include» relationship:
Means one use case always includes the behavior of another.
Example: “Process Order” includes “Validate Payment.”
 «extend» relationship:
Means one use case optionally adds to another.
Example: “Offer Discount” extends “Process Order.”
3.8 State Diagram

A state diagram shows how an object changes over time in response to different events.
Each object has various states, and transitions occur when certain actions or events happen.

Example:
A Patient object could have states like:

 New → Current → Former

Figure 5: Example of a State Diagram for a Patient

State diagrams are particularly useful for modeling systems with objects that react to inputs or
conditions (like machines, transactions, or orders).

3.9 Sequence Diagram

A sequence diagram focuses on the time order of interactions between objects.

It shows which objects communicate and in what sequence messages are exchanged.
Objects are represented by vertical lines, and messages are shown as arrows flowing between
them from top to bottom (in time order).

Figure 6: Sequence Diagram – Time-Ordered Object Interactions

Example:
In a login system, a sequence might look like:

1. User → LoginForm: enterCredentials()

2. LoginForm → AuthSystem: verifyUser()
3. AuthSystem → LoginForm: success()
4. LoginForm → User: displayWelcome()

3.10 Collaboration Diagram

A collaboration diagram (also called a communication diagram) shows how objects work
together by exchanging messages.
Unlike the sequence diagram, objects can be arranged anywhere, and messages are numbered
to indicate order.
Each message shows:

 The direction of communication

 The message name
 The order in which it happens

Figure 7: Example of a Collaboration Diagram (ATM System)

Example:
A client interacts with an ATM by inserting a card, verifying a PIN, selecting transactions, and
receiving money — all represented by messages exchanged among Client, ATM, Controller, and
Database objects.

3.11 Activity Diagram

An activity diagram describes the workflow or process of an operation or system.

It focuses on steps, decisions, and transitions between activities.

Each activity is shown as a rounded rectangle, and decision points are shown as diamonds.
Arrows indicate the flow from one step to the next.
 Figure 8: Example of an Activity Diagram

Example:
The process of creating and printing a document might include:

1. Open word processor

2. Create file
3. Type document
4. Add graphics or tables
5. Save and print the file
6. Exit application

Activity diagrams are useful for visualizing business processes, use case flows, or software
algorithms.
3.12 Other UML Features

1. Packages

A package groups related classes, diagrams, or components together.

This helps organize complex models into smaller, manageable parts.

Example: A “Billing” package might contain all classes related to payment processing.

Figure 9: Example of a UML Package

2. Notes

A note is a small annotation that provides explanations, reminders, or clarifications in a diagram.

It’s drawn as a rectangle with a folded corner and connected to an element by a dotted line.

Figure 10: Example of a UML Note

3. Stereotypes

A stereotype lets designers extend UML by creating new types of elements from existing ones.
It’s written inside double angle brackets like this: «Interface», «Entity», or
«Controller».

Example:
An interface in UML can be shown as:

«Interface»
PaymentGateway

Figure 11: UML Stereotype Example for Interface

Stereotypes are useful when we want to tailor UML for specific domains, such as databases,
embedded systems, or web apps.

3.13 Chapter Summary

In this chapter, we learned that:

 UML is a standard graphical language for modeling software systems.

 It helps visualize structure, behavior, and interaction before coding begins.
 UML models are composed of various diagrams, each showing a unique aspect of the
system.
 Class and Object Diagrams show structure.
  Use Case, Sequence, Collaboration, and Activity Diagrams show behavior and
interactions.
 State Diagrams describe object life cycles.
 Packages, Notes, and Stereotypes provide flexibility and organization in complex
systems.

UML is a universal communication tool that bridges the gap between analysis, design, and
implementation.
 Chapter 4: Introduction to the Unified Process Model

4.1 What is the Unified Process (UP)?

The Unified Process (UP) is a modern software development framework that provides a
structured, organized way to build object-oriented systems.

It is use case–driven, architecture-centric, and iterative and incremental — meaning the

system is built gradually through repeated cycles.

The UP was designed to combine the best practices of software engineering while addressing
the limitations of older linear models like the waterfall.

4.2 The History of the Unified Process

The Unified Process was created by three pioneers of object-oriented modeling:

 Grady Booch
 James Rumbaugh
 Ivar Jacobson

These three experts (often called the “Three Amigos”) combined their individual methods — the
Booch Method, OMT, and OOSE — to form the Unified Modeling Language (UML) and the
Unified Process (UP).

Later, Rational Software developed the commercial version known as the Rational Unified
Process (RUP), which became the industry standard for object-oriented system development.

4.3 Key Characteristics of the Unified Process

The UP is built around three main ideas that make it both flexible and effective:
1. Use Case–Driven

All development activities revolve around use cases — descriptions of how users interact with
the system.
Each iteration focuses on implementing a set of use cases that deliver value to the user.

2. Architecture-Centric

The system’s architecture — its fundamental structure — plays a central role in guiding design
and implementation.
By focusing on architecture early, the UP ensures the system remains scalable, maintainable,
and robust.

3. Iterative and Incremental

Instead of developing everything at once, the system is built step by step.

Each iteration produces a working version of the system, allowing early testing, feedback, and
refinement.

4.4 The Iterative and Incremental Approach

In traditional models like the waterfall, development happens in one long sequence.
If a mistake is found late, it’s very costly to fix.

The UP solves this by using iterations — smaller development cycles within the larger project.

Each iteration goes through most of the development activities:

 Requirements gathering
 Analysis and design
 Implementation
 Testing
 Integration and evaluation
At the end of every iteration, a working product (even if incomplete) is delivered.
This allows early user feedback and helps reduce risks.

Figure 1: Incremental Growth of a System through Iterations

Each iteration adds new functionality, gradually leading to the complete system.

4.5 The Four Phases of the Unified Process

The UP divides the project life cycle into four main phases:

1. Inception
2. Elaboration
3. Construction
4. Transition

These phases are sequential at a high level but contain multiple iterations within them.

Let’s go through each phase in detail.

4.6 The Inception Phase

The Inception phase is the starting point of the project.

Its goal is to understand the problem, define the vision, and establish whether the project is
feasible.

Key tasks include:

 Identifying the system’s main objectives

 Defining high-level requirements and main use cases
 Estimating cost, schedule, and risks
 Preparing the initial project plan

The result of this phase is a clear business case that justifies moving forward.

Typical deliverables:

 Vision document
 Initial use case model
 Preliminary project plan
 Risk assessment

4.7 The Elaboration Phase

The Elaboration phase is the most critical part of the UP.

It focuses on analyzing requirements in detail, defining the system’s architecture, and
addressing major risks.

Goals of this phase:

 Refine and prioritize use cases

  Design the system’s architecture (using UML diagrams)
 Identify reusable components
 Plan remaining iterations

The output is an architectural baseline, which provides a stable foundation for construction.

Deliverables:

 Detailed use case model

 Architectural design documents
 Updated project plan
 Prototype of core architecture

4.8 The Construction Phase

The Construction phase is where most of the system is designed, coded, and tested.
It involves multiple iterations, each adding more functionality.

Activities include:

 Implementing and testing system components

 Integrating modules into the evolving system
 Refining the design and code
 Performing system and integration tests

At the end of this phase, the system should be functionally complete and ready for deployment.

Deliverables:

 Executable software release

 User manuals and documentation
 Updated test results
4.9 The Transition Phase

The Transition phase focuses on delivering the product to users and ensuring it meets their
needs.
This includes final testing, bug fixing, and deployment.

Key activities:

 Beta testing with real users

 Training and user documentation
 Correcting final defects
 Preparing for full system release

The goal is to make sure the product is ready for operational use.

Deliverables:

 Final product release

 Installation guide
 User support materials

After this phase, the system enters its maintenance phase, where updates and improvements are
made as needed.

4.10 Workflows in the Unified Process

Within each phase, the UP defines several core workflows (disciplines) that guide what
activities should happen.

Workflow Description
Business Modeling Understand the business context and goals.
Requirements Identify what the system must do (use cases).
Analysis & Design Define how the system will meet the requirements.
Implementation Write and integrate code.
Testing Verify that the system works as expected.
Deployment Deliver the system to users.
Configuration & Management Track versions, changes, and artifacts.
Project Management Plan, monitor, and control the project.
Environment Prepare the tools and infrastructure needed.

Figure 10: Unified Process Workflows

Each iteration may focus more on certain workflows than others — for example, early iterations
emphasize requirements, while later ones focus on implementation and testing.

4.11 Artifacts in the Unified Process

An artifact is any tangible result produced during software development.

Examples include:

 Models (use case model, class model, sequence diagrams)

 Documents (requirements specification, design documents)
 Source code
 Test cases
 Executables

Artifacts are organized and managed carefully to maintain traceability — the ability to track
how each requirement is implemented in the system.
 Figure 2: Unified Process Artifacts and Their Relationships

4.12 Advantages of the Unified Process

The UP offers many advantages over older models:

1. Flexibility – Adapts to changing requirements through iterative development.

2. Risk Management – Identifies and mitigates risks early.
3. Early Feedback – Delivers partial systems early for user testing.
4. Reusability – Encourages reuse of components and designs.
5. Clear Structure – Provides organized phases and workflows.
6. Quality Assurance – Continuous testing ensures better quality.
7. Traceability – Every requirement is linked to its implementation.

4.13 Unified Process vs. Traditional Models

Aspect Unified Process (UP) Traditional (Waterfall)

Development Style Iterative and incremental Sequential
Risk Handling Early and continuous Late in development
Flexibility High (can adapt easily) Low
User Involvement Continuous feedback Mostly at beginning and end
Delivery Partial systems after each iteration One final product at the end
Error Correction Early discovery and fix Late and expensive fixes

Figure 3: Unified Process Disciplines

4.14 Chapter Summary

In this chapter, we learned that:

 The Unified Process (UP) is a modern framework for object-oriented software

development.
 It is use case–driven, architecture-centric, and iterative/incremental.
  The UP consists of four phases: Inception, Elaboration, Construction, and Transition.
 Each phase contains several workflows, such as requirements, design, implementation,
and testing.
 The UP produces artifacts that ensure clarity, traceability, and quality.
 Compared to older models, the UP offers greater flexibility, risk control, and
continuous improvement.

The Unified Process remains one of the most influential methodologies in modern software
engineering, especially for object-oriented projects.
 Chapter 5: The Inception Phase

5.1 Introduction

The Inception Phase is the first phase of the Unified Process (UP).
It marks the beginning of a software project, where the main goal is to understand what the
system should do and why it should be developed.

This phase focuses on defining the scope, identifying the main requirements, and
establishing a solid business case for the project.

The inception phase is short but crucial — it sets the direction for the entire project.

5.2 Purpose of the Inception Phase

The main purpose of this phase is to analyze the project’s feasibility and to decide whether it’s
worth continuing.

By the end of the inception phase, the development team and stakeholders should have a shared
understanding of:

 What the system will do

 Who will use it
 Why it is needed
 What risks and costs are involved

The result is a clear and realistic project vision.

(What? Who? Why? How much?)

5.3 Main Objectives

The objectives of the inception phase can be summarized as follows:

1. Define the System’s Scope and Purpose

o What is the goal of the system?
o What problems does it solve?
o What features are essential?
2. Identify Stakeholders and Users
o Determine who will interact with the system (actors).
o Identify their needs and expectations.
3. Develop the Initial Use Case Model
o Create preliminary use case diagrams describing how users will interact with the
system.
4. Estimate Project Cost and Time
o Provide a rough idea of how much the project will cost and how long it will take.
5. Assess Project Risks
o Identify potential obstacles and uncertainties.
6. Prepare a Business Case
o Evaluate whether the project is feasible and beneficial to the organization.

5.4 Activities in the Inception Phase

The inception phase includes several key activities that help the team gather the necessary
information for planning.

1. Establish the Project Scope

Define what the project will include — and what it will not include.
The scope should describe the system boundaries, main goals, and high-level features.

2. Identify Actors and Use Cases

Determine who will use the system (actors) and how they will interact with it (use cases).
At this stage, the use case model is high-level — it identifies main functionalities without all the
details.

3. Identify Risks

Discuss possible technical, financial, or organizational risks.

For example:

 Can existing hardware support the new system?

 Are there skill gaps in the team?
 Is the timeline realistic?

4. Estimate Resources

Estimate time, effort, budget, and personnel required for the next phase.
These are rough estimates but useful for decision-making.

5. Create the Business Case

The business case justifies why the project should proceed.

It includes cost-benefit analysis, project justification, and success criteria.

5.5 The Use Case Model

During inception, a use case model is developed to describe how users will interact with the
system.
This model includes:

 Actors: Users or external systems that communicate with the system.

 Use Cases: The major functions or goals that the system will support.

Example:
In a Library Management System, the actors might be:

 Librarian
 Member

The main use cases could include:

 Add Book
 Borrow Book
 Return Book
 Renew Membership

This early use case model helps everyone visualize what the system will do — even before
detailed design begins.

5.6 The Vision Document

The Vision Document is one of the main outputs of the inception phase.
It provides a clear overview of the system’s purpose, main features, and expected benefits.

It typically includes:

1. Introduction: Background and goals of the system.

2. Stakeholder Description: Who the system is for.
3. System Features: Main functionalities.
4. Constraints: Technical or business limitations.
5. Assumptions: Conditions assumed true for planning.
6. Risks and Dependencies: Factors that may affect success.

The vision document serves as a reference point for all future work.
5.7 The Business Case

The business case explains why the project should be developed and whether it makes sense to
invest in it.
It’s often presented to management for approval.

A good business case includes:

 Expected benefits (e.g., profit, efficiency, user satisfaction)

 Estimated costs (e.g., development, training, maintenance)
 Risk analysis and mitigation plans
 Return on investment (ROI) or payback period

If the business case is strong, the project can confidently move forward to the Elaboration
Phase.

5.8 Assessing Feasibility

Feasibility assessment determines whether the project is technically and economically viable.

1. Technical Feasibility

Can the system be built with current technology, skills, and resources?

2. Economic Feasibility

Will the benefits outweigh the costs?

3. Operational Feasibility

Will users accept and effectively use the system?

4. Schedule Feasibility
Can the project be completed within the required time?

5.9 Risks and Assumptions

Every project has risks — especially in early stages when information is incomplete.

Common project risks:

 Unclear requirements
 Over-optimistic timelines
 Inexperienced team members
 Dependence on new or untested technology

To handle these, the inception phase includes:

 Identifying the major risks

 Estimating their potential impact
 Planning how to reduce or monitor them

Assumptions made in this phase (like technology availability or user cooperation) should be
clearly documented and reviewed later.

5.10 The Project Plan

The project plan outlines the schedule and resources needed to reach project goals.
It is a living document — refined in later phases — but during inception, it gives a rough
estimate.

A typical inception-phase plan includes:

 High-level timeline
  Major milestones
 Resource estimates (staff, budget, tools)
 Risk management summary

This plan helps decision-makers evaluate whether the project should proceed.

5.11 Key Deliverables of the Inception Phase

By the end of the inception phase, several important artifacts (documents and models) should be
completed:

Deliverable Description
Vision Document Describes the system’s purpose, scope, and features.
Initial Use Case Model Identifies main actors and use cases.
Business Case Justifies the project’s existence.
Risk List Outlines key project risks.
Preliminary Project Plan Gives a rough estimate of cost, schedule, and resources.

These outputs are reviewed to decide whether to move to the next phase — Elaboration.

5.12 Milestones and Review

At the end of the inception phase, a Lifecycle Objective (LCO) milestone review takes place.
This review ensures that the project is ready to proceed.

Review questions include:

 Is the system vision clear and agreed upon?

 Are major risks identified and manageable?
 Is the business case sound?
  Are resources and schedule estimates realistic?

If the review is successful, the project advances to the Elaboration Phase.

Figure 1: Partial use case context diagram

5.13 Chapter Summary

In this chapter, we learned that:

 The Inception Phase is the starting point of the Unified Process.

 Its purpose is to define the scope, vision, and feasibility of the project.
 Major activities include defining the system’s purpose, identifying actors and use cases,
assessing risks, and preparing a business case.
 Key deliverables include the Vision Document, Use Case Model, Risk List, and
Preliminary Project Plan.
 The phase concludes with a milestone review to decide whether to proceed.
The inception phase ensures that a project begins with clear goals, realistic expectations, and a
solid foundation for success.
 Chapter 6: The Elaboration Phase

6.1 Introduction

After the Inception Phase confirms the project’s vision and feasibility, the next step in the
Unified Process (UP) is the Elaboration Phase.
This phase focuses on understanding the system in depth, stabilizing requirements,
resolving major risks, and building the core system architecture.

In other words, the elaboration phase is where ideas start turning into a working technical
foundation.

6.2 Purpose of the Elaboration Phase

The main goals of the elaboration phase are to:

1. Discover and stabilize requirements

– Most of the system’s requirements are clarified and refined.
2. Mitigate or eliminate major risks
– Technical and design uncertainties are addressed early.
3. Develop and validate the core architecture
– The basic structure of the system is built and tested.

By the end of this phase, the development team should have a clear and validated architecture,
a detailed plan for construction, and a working prototype demonstrating key system
capabilities.

6.3 Duration and Iterations

The elaboration phase usually consists of two to four iterations, each lasting between two and
six weeks.
Each iteration is timeboxed — meaning it has a fixed end date that must be met, even if some
lower-priority features need to be delayed.

Best Practice: If an iteration is running out of time, move unfinished tasks to a later iteration
instead of extending the deadline.
This keeps development predictable and disciplined.

6.4 Key Practices in the Elaboration Phase

Several important software engineering practices are emphasized during this phase:

1. Short, Timeboxed, Risk-Driven Iterations

o Each iteration focuses on the highest-risk and highest-value parts of the project.
2. Start Programming Early
o Begin coding core components early to validate designs and catch issues sooner.
3. Adaptive Design and Testing
o Continuously refine architecture, design, and implementation based on feedback.
4. Frequent, Realistic Testing
o Test not just for correctness, but for usability, performance, and reliability.
5. Feedback-Based Refinement
o Adjust plans based on results from tests and user feedback.
6. Detailed Requirements Workshops
o Hold sessions to write and refine most of the system’s use cases during
elaboration.

6.5 Building and Proving the Core Architecture

Early iterations should focus on building and proving the robustness of the core architecture.
This involves designing and connecting all the major subsystems of the system, even if some are
only partially implemented.

This is sometimes called a “wide and shallow” design, meaning:

 The system is built across many components (wide),

 But each component may be only partially implemented (shallow).

Example: NextGen POS System

In the NextGen Point-of-Sale (POS) project:

 The architecture includes subsystems like Sales, Payments, Tax Calculation, and
Inventory.
 Early iterations focus on defining and connecting these modules, even if they contain
only stub code.

This allows the team to verify interfaces, dependencies, and communication paths early in
development.

6.6 Refining Interfaces and Integrating Components

As part of architectural refinement:

 Interfaces between modules (including local and remote ones) are defined and tested.
 This includes setting up method parameters, return values, and data exchange formats.

Example:
In the NextGen POS system, one interface connects to a third-party accounting service.
Testing and refining such interfaces early prevents major integration issues later.

Integrating Existing Components

Where possible, reusable components or libraries (like a tax calculator) are integrated early to
confirm compatibility.

End-to-End Scenarios

Simplified versions of complete workflows (e.g., “Process Sale” scenario) are built to ensure all
system parts work together.

6.7 Importance of Testing During Elaboration

Testing plays a critical role in this phase.

Its purpose is not just to find bugs, but to validate design decisions and prove that the core
architecture is stable.

Examples of Early Testing in the NextGen POS:

1. Usability testing – Evaluate user interface design for the Process Sale scenario.
2. Recovery testing – Check how the system behaves when remote services (like credit
authorization) fail.
3. Performance testing – Simulate high load to see how remote services (like the tax
calculator) respond.

Early feedback from these tests helps the team make timely improvements and prevent expensive
redesigns later.

6.8 Planning the Next Iteration

After each iteration, the team plans the next one based on:

 Risk – Technical complexity, uncertainty, and potential impact.

 Coverage – Ensuring all major system areas are at least touched early.
  Criticality – Focusing on features with high business value.

These criteria guide which use cases or features to implement next.

Adaptive Planning

The plan is not fixed at the start of the project.

After every iteration, requirements and priorities are revisited and adjusted based on new
insights.

6.9 Example of Iteration Ranking

Below is an example of ranking features and use cases for the NextGen POS project:

Comment Requirement (Use Case / Rank

Feature)
Scores high on all criteria; essential and hard to add later Process Sale High
Needed for logging and maintenance Logging High
Affects security subsystem Maintain Users Medium

Based on this ranking, the Process Sale use case is addressed first since it’s architecturally
significant and high priority.

6.10 Iteration Plan

Each iteration has its own Iteration Plan, which lists:

 The use cases or features to be implemented.

 The responsible team members.
 The estimated timeline and resources.
If more detail is needed, specific tasks are described in Change Requests, and the overall
ranking of requirements is recorded in the Software Development Plan (SDP).

6.11 Example: Iteration 1 in NextGen POS

The first iteration in the NextGen POS system focuses on a simple, core scenario:

 Implement a basic Process Sale use case (cash-only payment).

 Include a Start Up use case to initialize the system.
 Skip external services like tax or product databases for now.
 Keep design simple — no complex pricing rules or external calls.

This iteration builds the foundation for future work while keeping the system functional and
testable.

6.12 Incremental Development Across Iterations

Not every use case is completed in one iteration.

Large use cases like Process Sale may be expanded across multiple iterations.

Each iteration adds new functionality or handles new scenarios:

 Iteration 1: Cash-only payment

 Iteration 2: Credit payment integration
 Iteration 3: Tax calculation and inventory update

This incremental approach ensures stable progress while maintaining flexibility.

6.13 Artifacts Started During the Elaboration Phase

Several key artifacts (documents and models) are created and refined during elaboration.

Artifact Description
Domain Model Visual representation of main concepts and relationships in
the system.
Design Model Logical design including class diagrams, interaction
diagrams, and packages.
Software Architecture Document Summary of architectural decisions and design rationale.
(SAD)
Data Model Database schema and mapping between objects and tables.
Test Model Defines what will be tested and how.
Implementation Model The actual code, executables, and databases.
Use-Case Storyboards / UI Early versions of the user interface and navigation paths.
Prototypes

These artifacts evolve over several iterations and become more detailed with time.

6.14 System Behavior and Sequence Diagrams

Before moving into detailed design, it’s important to understand the system behavior — what
the system does in response to user actions.

This is represented using System Sequence Diagrams (SSDs) in UML.

System Behavior:

 Describes what the system does (not how).

 Shows events from actors to the system, treating the system as a black box.
Example:
When a cashier enters an item ID, the system records the item and updates the total.
This is represented as a sequence of messages in an SSD.

6.15 System Sequence Diagrams (SSDs)

A System Sequence Diagram illustrates, for a specific use case scenario:

 The order of events sent by actors to the system.

 The system’s responses to those events.

Each message represents a system operation, and the diagram focuses on interactions across the
system boundary.
 Figure 1: Example of a System Sequence Diagram (SSD)

Main Success Scenario for Process Sale:

1. Cashier starts a new sale (makeNewSale()).

2. Cashier enters item ID (enterItem(itemID, quantity)).
3. System records sale line item and displays details.
4. Cashier ends sale (endSale()).
5. System displays total with taxes.
6. Cashier receives payment (makePayment(amount)).

The SSD visually summarizes this sequence of events.

6.16 Inter-System SSDs and Naming Conventions

SSDs can also describe interactions between systems, such as the POS and a credit
authorization service.
However, in early iterations, these external collaborations may be left for later phases.

When naming system events, follow these guidelines:

 Use intent-based verbs (e.g., enterItem(), makePayment()), not physical actions

(like “scan”).
 Keep names abstract from the interface technology.
o “Enter item” works for barcode scanning, manual entry, or voice input.

This keeps the design flexible and independent from specific UI implementations.

6.17 Chapter Summary

In this chapter, we learned that:

 The Elaboration Phase stabilizes requirements, reduces risks, and builds the system’s
core architecture.
 It includes several iterations, each timeboxed and focused on high-priority tasks.
 Key activities include refining interfaces, integrating components, and early testing.
 Planning is adaptive, guided by risk, coverage, and criticality.
 Artifacts such as domain models, design models, and sequence diagrams are initiated.
 System Sequence Diagrams (SSDs) are used to visualize how actors interact with the
system during a use case.

The elaboration phase ends when the architecture is proven stable, the main risks are under
control, and a solid foundation for construction is ready.
 Chapter 7: The Domain Model

7.1 Introduction

In object-oriented software engineering, one of the most important early steps in understanding a
system is to analyze the problem domain—the real-world environment in which the software
will operate.
This process is known as Object-Oriented Analysis (OOA).

The key goal of OOA is to identify the main concepts and relationships that exist in the
problem domain, and then represent them visually through a Domain Model.

A Domain Model is not a software design or code structure—it doesn’t show classes with
methods or software logic.
Instead, it focuses on conceptual classes and how they are related in the real world.

7.2 What Is a Domain Model?

A Domain Model is a visual representation of the important concepts (or “conceptual classes”)
and relationships in a given problem domain.
It is typically drawn using UML class diagrams, but without methods or behaviors.

It shows:

 Conceptual classes or domain objects

 Associations between these classes
 Attributes of each class

For example, in a retail store system:

 Sale, Payment, Item, and Register are all conceptual classes.

 A Sale is paid by a Payment, and recorded on a Register.
 Figure 1: A simple domain model for a sales system.

This model helps developers, analysts, and clients share a common understanding of what the
system is about before jumping into technical details.

7.3 Creating a Domain Model

To build a domain model, we follow four general steps:

1. List the Candidate Conceptual Classes

o Use a category list or analyze nouns from requirements and use cases.
2. Draw the Classes
o Represent them using UML boxes (one for each conceptual class).
3. Add Associations
o Show meaningful relationships between these classes.
4. Add Attributes
o Include important data values that each class should remember.
A good domain model focuses only on what exists in the problem, not on implementation
details.

7.4 Identifying Conceptual Classes

Two main techniques can be used to find conceptual classes:

1. Conceptual Class Category List

This is a prepared list of common categories of objects that frequently appear in different
domains.
You can use it as a checklist to identify possible conceptual classes.

Category Examples
Physical or tangible objects Register, Airplane
Specifications or descriptions ProductSpecification, FlightDescription
Places Store, Airport
Transactions Sale, Payment, Reservation
Transaction line items SalesLineItem
Roles of people Cashier, Pilot
Containers Store, Airplane
External systems CreditPaymentSystem, AirTrafficControl
Abstract concepts Hunger, Acrophobia
Organizations SalesDepartment, Airline
Events Sale, Crash, Flight
Processes SellingAProduct, BookingASeat
Rules or policies RefundPolicy
Catalogs ProductCatalog
Financial instruments LineOfCredit, Stock
Documents Receipt, Ledger, Contract

By checking which of these categories apply to your system, you can quickly generate a list of
candidate classes.

2. Noun Phrase Identification

Another useful technique is linguistic analysis.

By reading system descriptions, use cases, or user stories, underline or list the nouns and noun
phrases—each may represent a conceptual class or attribute.

For example, from the Process Sale use case:

1. Customer arrives at the checkout with goods.

2. Cashier starts a new sale.
3. Cashier enters an item identifier.
4. System records a sale line item and displays total.
5. System calculates tax and total.
6. Customer pays and receives a receipt.

From this, we can extract nouns like Customer, Cashier, Item, Sale, Payment, Receipt, Tax,
and Store — most of which are conceptual classes.

7.5 Example: NextGen POS System

In the NextGen Point-of-Sale (POS) application, we can use the techniques above to identify
the following conceptual classes:

 ProductSpecification
 SalesLineItem
  Cashier
 Customer
 Manager
 Register
 Item
 Store
 Sale
 Payment
 ProductCatalog

These classes can then be represented in a UML domain model diagram.

Figure 2: NextGen POS Domain Model

7.6 Adding Associations

Once conceptual classes are identified, we need to show how they are related through
associations.

An association is a meaningful connection between two or more conceptual classes.

For instance, a Sale is paid by a Payment, and a Sale is recorded by a Register.

Useful Associations

Include only associations that represent meaningful, “need-to-know” relationships that must be
remembered or understood in the domain.

For example:

 A Sale has multiple SalesLineItems — we must keep this link to calculate totals.
 A Sale has one Payment — this must be recorded for receipts and financial tracking.
 A ProductCatalog records ProductSpecifications — needed to find item details.

7.7 UML Association Notation

In UML:

 Associations are drawn as lines connecting classes.

 Each end may include multiplicity, showing how many instances can be connected.
 Optionally, a name and arrow may describe the association’s meaning.

Example:
Register — Records — Sale
means that one Register records many Sales.

7.8 Common Association Types

The Common Associations List provides patterns to help identify relationships.

Association Type Example

A is part of B SalesLineItem — Sale
A is contained in B Item — Store
A is recorded in B Sale — Register
A describes B ProductSpecification — Item
A is a member of B Cashier — Store
A uses or manages B Cashier — Register
A pays or initiates B Customer — Payment
A is related to another transaction B Payment — Sale

7.9 Multiplicity

Multiplicity specifies how many instances of one class relate to another.

It’s shown as a small number or symbol near the association ends.

Multiplicity Symbol Meaning

* Zero or more (“many”)
1..* One or more
0..1 Optional (zero or one)
1 Exactly one
1..40 Between one and forty

Example:
A Store stocks many Items, so the multiplicity is 1 Store → * Items.

Associations should also be named clearly, using a “ClassName–VerbPhrase–ClassName”

format, such as:

 Sale — Paid-by — Payment

  ProductCatalog — Contains — ProductSpecification

7.10 Adding Attributes

Attributes represent data values or properties of conceptual classes.

In UML, attributes are shown inside the class box, in the second compartment.

Include attributes only if the system needs to remember or display that information.
Common data types include:

 String, Number, Boolean, Date, Time

 Others like Address, Color, Phone Number, ZIP Code

7.11 Attributes in the NextGen POS Domain Model

From the Process Sale scenario, we can identify key attributes needed to support system
behavior:

Conceptual Class Attribute(s) Purpose

Payment amount Determine payment sufficiency and calculate change
ProductSpecification description, id, price Identify products and calculate totals
Sale date, time Record when the sale occurred
SalesLineItem quantity Capture number of items per sale line
Store name, address Display on receipts and reports

7.12 The Complete Domain Model

By combining conceptual classes, associations, and attributes, we can construct a comprehensive
Domain Model for the POS system.

This diagram shows how all entities are connected and what data they carry.

Figure 3: Complete Domain Model for the NextGen POS System

(Includes classes: Sale, Payment, Item, SalesLineItem, ProductSpecification, ProductCatalog,
Register, Cashier, Store, Customer, Manager.)

This model provides a foundation for further design — it helps developers understand the key
elements of the system before defining operations, interfaces, or databases.
7.13 Key Takeaways

 A Domain Model visualizes important concepts, associations, and attributes in the

real-world problem domain.
 It helps bridge the gap between requirements and design.
 Conceptual classes can be found using category lists and noun phrase analysis.
 Associations represent meaningful relationships, while multiplicity defines how many
objects participate in each relationship.
 Attributes capture essential data that the system must remember or display.
 The NextGen POS model demonstrates how these elements come together to describe a
real-world sales system.

7.14 Chapter Summary

The Domain Model is a central artifact in Object-Oriented Analysis.

It transforms textual requirements into a visual map of the real-world concepts that the system
will represent.

Through this model, software engineers can communicate effectively with stakeholders and
ensure that the system design is firmly grounded in the real-world context it aims to serve.
 Chapter 8: From Requirements to Design

8.1 Introduction

Up to this point, we have focused mainly on requirements analysis — understanding what the
system should do by studying use cases, domain models, and system interactions.

In this chapter, we begin the transition from requirements to design.

That means turning our understanding of real-world concepts into software classes and objects
that collaborate to perform the system’s behavior.

Each iteration in an object-oriented project naturally shifts focus:

 Early iterations emphasize understanding requirements.

 Later iterations focus on designing and implementing a working solution.

It’s perfectly normal for some requirements to evolve or change as we begin designing and
coding.
This iterative feedback loop is a strength of the Unified Process (UP).

8.2 From Analysis to Object Design

Object Design begins once the domain model and use cases are in place.
Here, we start defining software classes, methods, and messages — deciding how objects will
collaborate to satisfy each use case.

Definition:
Object design is the process of assigning methods and defining interactions between objects to
realize system behavior.

In practice, this involves:

 Creating interaction diagrams (sequence or collaboration diagrams).

  Defining responsibilities for each class.
 Adding methods that allow objects to perform tasks or share information.

8.3 Responsibilities and Methods

In object-oriented design, each class has responsibilities — the things it must do or know.
The UML defines a responsibility as “a contract or obligation of a class.”

There are two main types of responsibilities:

1. Doing Responsibilities

 Performing actions (e.g., creating objects, calculations).

 Initiating actions in other objects.
 Coordinating or controlling other objects.

2. Knowing Responsibilities

 Knowing its own data (attributes).

 Knowing related objects.
 Knowing derived or calculated information.

Example:

 A Sale object is responsible for creating SalesLineItem objects (doing).

 A Sale is also responsible for knowing its total (knowing).

These responsibilities are implemented through methods.

8.4 Assigning Responsibilities and Interactions

Once we identify responsibilities, we decide which object should fulfill each one.
We then represent how objects collaborate to achieve system tasks using interaction diagrams.

Each interaction diagram corresponds to one or more system events — for example,
makeNewSale() or enterItem() in the NextGen POS system.

8.5 Use-Case Realizations

A use-case realization describes how a particular use case is achieved through collaboration
among software objects.

 Each use-case realization corresponds to one or more interaction diagrams.

 These diagrams show how messages are exchanged to fulfill the use case.
 The objects involved are often based on the domain model.

8.6 Example: makeNewSale

When a cashier starts a new sale, the system receives the makeNewSale() message.

We must decide which class handles this message.

A good candidate is the Register class — since it represents the point of sale and logically
records sales.

The Register object then:

1. Creates a new Sale object.

2. The Sale object creates an empty collection (e.g., a list) to hold future
SalesLineItem objects.
 Figure 1: Sequence Diagram for makeNewSale()

8.7 Example: enterItem

When the cashier enters an item’s ID and quantity, the enterItem() operation is triggered.

The sequence of events is:

1. The Register receives the message enterItem(itemID, quantity).

2. The Register asks the ProductCatalog to find the matching
ProductSpecification.
3. The Sale then creates a new SalesLineItem, which is linked to the retrieved
ProductSpecification.

This example demonstrates how responsibilities are distributed:

 Register handles system input.

 ProductCatalog knows all product data.
 Sale manages its own line items.
8.8 Example: Calculating the Sale Total

When the sale is complete, the system must calculate the total.

The Sale object is responsible for knowing its total, but the total depends on:

 Each SalesLineItem’s subtotal (quantity × price).

 Each SalesLineItem gets the price from its ProductSpecification.

Therefore:

 Sale sends getSubtotal() to each SalesLineItem.

 Each SalesLineItem sends getPrice() to its ProductSpecification.
 The subtotals are summed to get the sale total.

This design follows the Information Expert principle — assign a responsibility to the class that
has the necessary information to fulfill it.
 Chapter 9: Design Class Diagrams (DCDs)

9.1 Introduction

After creating interaction diagrams, the next step is to define the software classes formally in a
Design Class Diagram (DCD).

A Design Class Diagram describes:

 Software classes and interfaces

 Their attributes and methods
 Relationships (associations, navigability, multiplicity)

In the Unified Process, these diagrams belong to the Design Model.

9.2 Creating a Design Class Diagram

Follow these steps to create a DCD:

1. Identify participating classes — from interaction diagrams.

2. Draw the class diagram — include relevant attributes and methods.
3. Add method names — based on the messages seen in interaction diagrams.
4. Add type information — for attributes, parameters, and return types.
5. Add associations and navigability — based on object interactions.

9.3 Example: NextGen POS DCD

From all interaction diagrams, we identify the following software classes:

 Register, Sale, Store, ProductCatalog, Payment,

ProductSpecification, SalesLineItem
Some conceptual classes (like Cashier) don’t need to appear in software yet.

9.4 Adding Methods

Every message in an interaction diagram implies a method in the corresponding class.

Example:

 The message makeLineItem() → method makeLineItem() in Sale

 The message getSpecification() → method getSpecification() in
ProductCatalog

By reviewing all diagrams, we can list main methods per class:

Class Main Methods

Register makeNewSale(), enterItem(), makePayment(), endSale()
Sale makeLineItem(), makePayment(), getTotal(), becomeComplete()
ProductCatalog getSpecification()
SalesLineItem getSubtotal()
ProductSpecification getPrice()
Store addSale()
Payment (constructors, attributes)

9.5 Adding Type Information

Each attribute and method parameter can specify a type for clarity.

Attribute/Parameter Type
Description Text
Price Money
itemID ItemID
Date Date
Time Time
quantity Integer

This helps programmers implement code correctly and consistently.

9.6 Associations and Navigability

Each association between classes represents a reference from one object to another.
Navigability arrows show which direction this reference goes.

Rules for Navigability:

 If class A sends a message to B, then A needs a navigable link to B.

 If A creates or stores B, a navigability arrow should point from A to B.

Example:

 Register → Sale (creates sales)

 Sale → SalesLineItem (contains line items)
 SalesLineItem → ProductSpecification (described by product data)
Figure 2: Associations and Navigability Example
 Chapter 10: Mapping Designs to Code

10.1 Introduction

Once the design is stable, we can start implementing it in code using an object-oriented
language like Java.

A Design Class Diagram provides everything needed to write:

 Class and interface definitions

 Attributes and reference fields
 Method headers and constructors

10.2 Implementing Class Definitions

A DCD shows enough detail to define class skeletons in code.

Example (Java):

public class SalesLineItem {

private int quantity; // Simple attribute
private ProductSpecification productSpec; // Reference
attribute

public SalesLineItem(ProductSpecification spec, int qty) {

... }
public Money getSubtotal() { ... }
}

A reference attribute refers to another object, not a primitive value.

10.3 Implementing Methods from Interaction Diagrams

Each message in an interaction diagram becomes a statement in the corresponding method.

Example:
From the enterItem() sequence diagram:

public void enterItem(ItemID id, int qty) {

ProductSpecification spec = [Link](id);
[Link](spec, qty);
}

This method in Register sends messages to both ProductCatalog and Sale, matching
the diagram flow.

10.4 Using Collections

When a class must maintain multiple related objects, a collection (like a List) is used.

Example:

public class Sale {

private List<SalesLineItem> lineItems = new ArrayList<>();
}

This allows the Sale to store and manage all SalesLineItem instances.

10.5 Example: [Link]()

Based on the enterItem() diagram, the method can be written as:

public void makeLineItem(ProductSpecification spec, int qty) {

 [Link](new SalesLineItem(spec, qty));
}

This shows how messages like create(spec, qty) and add(sl) translate directly to
code.

Figure 19: Code Implementation of makeLineItem()

10.6 Order of Implementation

When coding, start with least-coupled classes (those with few dependencies) first.
Then gradually move toward most-coupled ones.

Typical order:

1. ProductSpecification
2. SalesLineItem
3. Sale
4. Payment
5. ProductCatalog
6. Register
7. Store
 Figure 1: Implementation Order Based on Coupling

10.7 Chapter Summary

 The transition from requirements to design involves defining how objects collaborate to
fulfill use cases.
 Interaction diagrams show these collaborations.
 Design Class Diagrams formalize the structure and relationships.
 The DCD maps directly into source code definitions.
 Collections and associations are implemented using lists or reference attributes.
 Implementation proceeds from simple, independent classes to more complex,
interconnected ones.

This completes the journey from analysis through design and into coding — the essential path of
Object-Oriented Software Engineering.