FIT3077

Software Architecture and Design

Week 2
Object Oriented Analysis, Modelling and Design

8th March 2021

Dr Najam Nazar
OUTLINE
• Use case
• Diagrams
• Descriptions
• Domain modelling
• Class Diagrams
• Conceptual modelling
• Design modelling
• Interaction Diagrams.
Learning Outcomes

Model and design flexible software at the architectural level using various tools and techniques;

Take requirements for simple systems and develop software architectures and designs at a high level;
What is OO Analysis?

• Analysis:
• Investigation of problem and the requirements.
• OO Analysis:
• emphases finding and describing objects and related concepts in the problem domain.
• Tool
• Block diagram
• UML
• usecases to analyse requirements.
• Class diagrams to model the domain after use cases are developed
• Interaction diagrams to design the model.
 Use Cases

The indispensable first step to getting the things you want out of life: decide what
you want. ---Ben Stein
Specifications
Example

Scenario
A customer arrives at a checkout with items to return. The cashier uses the POS system to
record each returned item ...
If the customer paid by credit, and the reimbursement transaction to their credit account is
rejected, inform the customer and pay them with cash…
If the system detects failure to communicate with the external accounting system, ...
Use Case
Definitions

• A collection of related success and failure scenarios that describe an actor using the
system under discussion to support a goal.
• They are requirements, primarily functional or behavioural requirements that indicate what
the system will do.
• A use case captures a contract between the stakeholders of a system about its behaviour –
Cockburn.
• A useful tool for formalizing your understanding of requirements.
• What is an actor?
• something with behaviour (or that acts as a result of an action), such as a person (e.g. cashier),
computer system or organisation.
Use Case
Actors

Types
• Primary: An actor that initiates the use case or an actor whose goals fulfilled through using
services of the system under discussion (e.g., Client).
• Supporting (Secondary): That facilitates the primary actor or provides a service to
achieve the primary goal (e.g., Cashier)
• Offstage (External): has an interest in the behaviour of the use case, but is not primary or
supporting (e.g., a government tax agency).

Note: the system under discussion is never an actor. Other systems can be.
Use Case
Types

• OMG has defined standards for what should be in Use Case and how they can by
described.
• Primarily Use cases can be described in two forms
• Use Case Descriptions/Scenarios
• Use Case Diagrams.
Use Case
Use Case Descriptions/Scenarios

• Text stories used to discover and record requirements.

• Is a narrative document that describes the interaction between actor(s) and the system
during a usage scenario.
• a specific sequence of actions and interactions between actors and the system under
discussion.
• It can be described at different levels of details.
Use Case
Use Case Descriptions/Scenarios

Level of Details.
• High-level (Brief)
• Terse description of the activities without going into details of how activities are performed
• Casual
• Brief but including the alternative and extension scenarios
• Expanded (Fully Dressed)
• shows more detail than a high-level one, details the sequence of events in the process
• generally done in a conversational style
• show alternative courses
• shows the initiator of the use case
Use Case
Use Case Descriptions/Scenarios

Example of High-level (Brief) Use Case.

Use Case: Process Sale

Actors: Customer, Cashier
Description: A customer arrives at a checkout with items to purchase. The cashier uses the
POS system to record each purchased item. The system presents a running
total and line item details. The customer enters payment information, which
the system validates and records. The system updates inventory. The
customer receives a receipt from the system and then leaves with the items.
Use Case
Use Case Descriptions/Scenarios

Example of Casual Use Case

Use Case: Handle Returns
Actors: Customer, Cashier
Main Success Scenario: A customer arrives at a checkout with items to return. The cashier
uses the system to record each returned item ...
Alternate Scenario: If the customer paid by credit, and the reimbursement transaction to
their credit account is rejected, inform the customer and pay them
with cash.

If the system detects failure to communicate with the

external accounting system, ...
Use Case
Use Case Descriptions/Scenarios

Example of Expanded Use Case

UC1: Process Sale
Actors: Customer (initiator), Cashier
Purpose: Capture a sale and its payment
Description: A Customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and process payment. On completion, the
Customer leaves with the items.

Type: Primary Use Case.

Precondition: The customer has all items
Postcondition: The payment is processed, sales captured.
Use Case
Use Case Descriptions/Scenarios

Example of Expanded Use Case (Contd…)

Use Case
Use Case Diagrams

Definitions
• Illustrates a set of use cases for a system:
• the actors
• the relationships between actors and use cases
• the relationships between use cases and other use cases
• Each use case diagram typically shows actors and use cases for a particular (subset of)
system functionality.
Use Case
Use Case Diagrams

Relationships
• In many situations we find that use cases are very similar or have similar passages and
relationships.
• We need mechanisms to handle these relationships.
• UML provides three mechanisms:
• Generalisation
• Include
• Extend
Use Case
Use Case Diagrams

Generalisation
• This means that a child use case inherits and/or implements the behaviour and meaning of
the parent use case
• The child may add to or override the behaviour of the parent
• The child may be substituted in any place the parent may appear in the system
• Generalization appears as:
Use Case
Use Case Diagrams

Example of Generalisation in a Use Case Diagram

• There are two types of authentication methods

• Single signin by providing username and password
• Multifactor by having an extra layer of security.
Use Case
Use Case Diagrams

Include
• A use case incorporates the behaviour of another use case at a location specified in that
use case.
• An including use case never stands alone. It always includes the included use case
• The included use case, however, can
• The include relationship is used to avoid describing the same flow of events several times,
by putting the common behaviour in a use case of its own
Use Case
Use Case Diagrams

Include - Example
• Once you are placing an order or tracing an order a verification is needed. Though verification is a
separate independent use case for place order and trace order, it is mandatory otherwise the place
order and trace order will not be successfully completed.
Use Case
Use Case Diagrams

Extend
• “Extend” is used to separate optional behaviour from mandatory behaviour
• The base use case optionally incorporates the behaviour of another use case at a specified
location
• The extended use case may stand alone, but, under certain conditions, it may be extended by another
use case.
• It may be extended only at certain points known as “extension points”
Use Case
Use Case Diagram

Extend - Example
• While placing an order online I would like the order to be wrapped or not. It is optional and
the use case place order can still be successfully completed if we don’t ask for wrapping.
Use Case
Use Case Diagram System

Primary Actor Supporting Actor

Complete Example

Use Cases
Use Case
Strengths and Weaknesses

Strengths
• Use cases directly relate to actors. Hence, they directly relate to the users of the system
and specifies the suite of interactions with the system.
• Use cases help the business analyst to document requirements in a commonly accepted
format in the problem space of the project.
• Use cases capture the functional aspects of the system. More specifically, they capture the
business processes carried out in the system.
• Use cases facilitate tracing of requirements.
• Use cases can also provide a starting point for sequence diagrams
• Use cases are the basis for test case development.
Use Case
Strengths and Weaknesses

Weaknesses
• Use case documentation is not standardised. This leads to confusion and debates on what
makes up a good use case.
• Use cases are not object-oriented in nature.
• Use cases do not cover nonfunctional (operational) requirements
• Use cases do not provide a good basis for coding.
Activity

Is Login a Use Case?

The answer is no. Login is not a goal that
we try to achieve during a system working.
For example, you purchase goods on
eBay, your goal is to purchase goods and
not logging in to the system.
 Domain Modelling

It’s all well in practice, but it will never work in theory. --- Anonymous Management
Maxim
Basics of OOP
Pre-Requisites

Classes
A class is a template for Objects
Class is an abstraction of all existing and new objects with similar
characteristic
Objects
Objects are instances of a class
Data stored inside the object fields is often references as state and all object methods define it’s
behaviours
Pillars of OOP?
Domain Modelling
Conceptual Classes

Definition
A domain model is a representation of real-world conceptual classes, not of software
components. It is not a set of diagrams describing software classes, or software objects with
responsibilities.– Larman
• So what is conceptual class?
• conceptual class is an idea, thing, or object
• We model identity, state, and behaviour
• It represents things in the real world, not classes in code
• How to capture them?
• UML Class Diagram
Domain Modelling
Class Diagram

Components

• Classes
• Rectangle containing the class name
• and optionally fields/states/attributes and
methods/behaviours/operations.
• Classes have relationships that are:
• Associations
• Dependency
• Aggregation
• It can be shared or composite
• Generalisation
Domain Modelling
Class Diagram

Associations

• Associations
• Association is a type of relationship in which one object uses or interacts with another.
• In UML diagrams the association relationship is shown by a simple arrow drawn from an object and pointing
to the object it uses.
• use an association to represent something like a field in a class
• Associations should be named
• Note: the name ‘has’ adds very little to understanding.
• Associations have multiplicities.
Domain Modelling
Class Diagram - Reading direction arrow
- It has no meanings except reading
Associations - Code the direction of association label.
- It is different from association
direction.

public class Lecturer {

private ArrayList<Student> students;
}

public class Student {

...
}
Association
name/label Multiplicities
Domain Modelling
Class Diagram

Associations - Multiplicities

• Multiplicities can be
• One to many
• Many to many
• Zero to many
• Exactly
• Its is not ERD diagram so don’t use m or n for many
multiplicities. However, in some conditional cases
we may use m and n.
Domain Modelling
Class Diagram

Dependency

• Dependency is a weaker variant of association that usually implies that there’s no permanent link between
objects.
• Dependency typically (but not always) implies that an object accepts another object as a method parameter,
instantiates, or uses another object.
• A dependency exists between two classes if changes to the definition of one class result in modifications in
another class.
Domain Modelling
Class Diagram

Dependency

public class Professor {

private void mySalary(Salary salary) // I am dependent on Salary
}
public class Salary {
...
}
Domain Modelling
Class Diagram

Aggregation

• Aggregation appears between classes when one object merely contains a reference to another
• There is a sharing of classes happening i.e. The component can exist without the container and
can be linked to several containers at the same time.
• In UML it is shown by a diamond sign which can be directional.
Domain Modelling
Class Diagram

Aggregation – Code Example

public class Department {

Professor professor;
public void setProfessor(Professor professor) {
this.professor = professor;
}

public class Professor{

…
Even if you delete class Department, Professor will
exist
}
Domain Modelling
Class Diagram

Composition

• Is a type of aggregation which shows a “whole-part” relationship between two objects, one of which is
composed of one or more instances of the other.
• The distinction between this relation and others is that the component can only exist as a part of the
container.
• composition relationship is shown by a line with a filled diamond at the container end.
• It can be directional.
Domain Modelling
Class Diagram

Composition – Code Example

public class University{

Department department;
public void setDepartment(){
this.department = new Department();
}
public class Department{
… If we delete class University, Department won't
} exist
Domain Modelling
Class Diagram

Generalisation (is-a)

• It represents the class hierarchies i.e. inheritance

• Superclass is inherited by subclasses.
• Subclasses can override the behaviour of methods that
they inherit from parent classes.
• A subclass can either completely replace the default
behaviour or just enhance it with some extra stuff.
• Generalisation with interfaces is called realisation.
Domain Modelling
Identifying Domain Classes

Methods

• There are three standard methods to identify domain classes.

• Identify Noun Phrases
• Identify Category List
• Reuse or modify existing models
• Method 3 is primarily reuse; it is not covered further.
Domain Modelling
Identifying Domain Classes

Noun Phrase Method.

• Make a list of candidate conceptual classes or attributes by identifying nouns in textual domain
descriptions
• Scenario: Process Sale (Basic Flow)
• Customer arrives at POS checkout with goods and/or services to purchase. Cashier starts a new sale.
Cashier enters item identifier. System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules.
• Cashier repeats steps 2-3 until indicates done. System presents total with taxes calculated. Cashier tells
Customer the total, and asks for payment.
• And so on…
• Guideline: Careful evaluation required: not mechanical.
Domain Modelling
Identifying Domain Classes

Category List Method

• Make a list of candidate conceptual classes in the domain, based on commonly occurring
categories.
• Sometimes they are physical objects or abstract concepts.

Conceptual Class Category Examples

Business Transactions Sale, Payment, Reservation
Physical Objects Item, Register, Board, Aeroplane
Container of things Store, Bin
Transactions Ledger, FlightManifest etc.
Domain Modelling
Identifying Domain Classes

Candidate classes

• Draw them as classes in a UML Class Diagram.

Domain Modelling
Identifying Domain Classes

Bringing it all Together.

• Draw them as classes in a UML Class Diagram.

• How I identify associations name?
• Is a member of -> Cashier, store
• Is a role related to -> Customer , payment
• Is physically or logically contained in/on ->
Register, store
• Is known/recorded/logged/reported or
captured -> Sale, register
• And so on….
Domain Modelling
Identifying Domain Classes

Rejecting Classes

• Redundant classes such as Customer, User for an ATM system

• retain the more descriptive name
• Irrelevant classes
• context-dependent
• e.g. Customer complaint is outside the scope of the ATM example
• Vague classes
• A class should be specific
• e.g. “ATM Death” is not clearly defined in our material
• Attributes
• e.g. name, age, weight, are not usually classes
• They will be part of fields in the diagram.
Domain Modelling
Identifying Domain Classes

Examples
Domain Modelling
Identifying Domain Classes

Example 2

• Don’t use attributes as Foreign

Keys. It’s not ERD diagram.
Domain Modelling
What should go into a conceptual class diagram for domain analysis?

Purpose
You’re creating the diagram to ensure that you, your team, and your clients all share an
understanding of how the domain works.
Important classes.
• talk to the customer or user to see what’s important to them.
• Include only class names, at least initially. You can add data storage and responsibilities as they become
clear to you, if you find that you need to clarify them, but you only need to put them in if the diagram is
hard to understand without them.
Relationships between these classes.
• Start off with generalisation (i.e. inheritance) and associations.
• If you can’t decide between composite or shared aggregation, leave it as an association for the
time being.
Note: At the conceptual level, names and types of attributes are typically not yet known
 DESIGN MODELLING

In theory, there is no difference between theory and practice. But, in practice, there
is. --Jan L. A. van de Snepscheut
Design Modelling
Introduction

• Emphasises defining software objects and their collaboration.

• Models which show how groups of objects interact to carry out some behaviour
• Typically we describe how the behaviour of a single use case is accomplished by a group of
objects and the messages they pass between them
• This is achieved through sequence and communication diagrams.
Design Modelling
Sequence Diagrams

Definition
• shows object interactions arranged in time sequence.
• It depicts the objects involved in the scenario and the sequence of messages exchanged
between the objects needed to carry out the functionality of the scenario.
Design Modelling
Sequence Diagrams

Lifelines
• Lifelines demonstrates an
object and it is shown as a
box.
Design Modelling
Sequence Diagrams

Messages
• Messages are written as
horizontal arrows.
Design Modelling
Sequence Diagrams

Self Message (this)

• Self calls can be shown as
well. Programmatically they
are this calls.
Design Modelling
Sequence Diagrams

Showing Results
• If there is a return call that
will be shown by a broken
horizontal line.
Design Modelling
Sequence Diagrams

Object Creation & Lifelines.

• Objects are shown at the
place they are created.
Design Modelling
Sequence Diagrams

Object Destruction
• Objects can be destructed.
Design Modelling
Sequence Diagrams

Frames
• Three types of frames are
used
• Loops
(loop)[condition or items]
• If/then
(opt)[condition]
• If/then/else
(alt)[condition or else]
with dashed separator
Design Modelling
Sequence Diagrams

Frames – Loop Collections.

Design Modelling
Sequence Diagrams

Frames – sd/ref
• Sd -> Define
• Ref -> refer
Design Modelling
Deriving a SSD from a Use Case.
Design Modelling
Communication Diagrams

• Same as sequence diagrams

• Different representation
 MAPPING DESIGNS TO
CODE - EXAMPLES

Beware of bugs in the above code; I have only provide it correct, not tried it. –
Donald Knuth
Mapping Designs to Code
Sequence Diagrams.
Mapping Designs to Code Public class SalesLineItem{
private int quantity;
private ProductDescription description;
Class Diagrams
public SalesLineItem(ProductDescription desc, int qty){
…
Examples }
public Money getSubtotal(){…}
}
Design Modelling
Class Diagrams

Examples
Mapping Designs to Code
Sequence Diagrams

Examples
Design Modelling
Class Diagrams

Examples