Object Oriented

Analysis and Design

(OOAD)

Lecture 1
Introduction
1
 Object Oriented Analysis and Design
(OOAD)
Lecture 1

Module Leader: Dr.K.Vijayalakshmi

Office : R303
Email : vijayalakshmi@nu.edu.om
Module Notes : elearn.nu.edu.om

2
 Contents

• Overview of the Module

• Why model?
• Some thoughts on the Software Development
Process
• The Unified Modelling Language (UML)
• Use Cases & Use Case Diagrams

3
 Overview of the Module
“Summary” from the module descriptor :

• This module provides a detailed coverage of object-

oriented analysis and design of software systems.

• It provides coverage of the Unified Modelling Language

(UML) notation and the practical application of UML in the
development of information systems using currently
available software modelling tools.

• It will also provide coverage of the use of Analysis and

Design Models
4
 Overview of the Module
“Learning Outcomes” from the module descriptor :

On completion of this module, students should be able to:

• Understand and apply object oriented techniques to the

analysis and design of software systems
• Develop object oriented specifications using the Unified
Modelling Language (UML)
• Develop UML models using currently available software
modelling tools
• Understand the integration between the design models
and implementation
5
 Overview of the Module
“Syllabus” from the module descriptor

Object Oriented Analysis And Design.

· An overview of the conceptual foundations of Object Oriented
Analysis and Design.
Class Diagrams
· Objects, classes, attributes, operations, inheritance, aggregation,
association, and generalisation.
· The development of class diagrams.
· The role of 'class diagrams' in analysis and design models.
Component Diagrams
· Components, component interfaces.
· Modelling system components using component diagrams.
6
 Overview of the Module
“Syllabus” from the module descriptor (continued) :
Interaction Diagrams
· Modelling object interaction using interaction diagrams (sequence
diagrams, communication diagrams, interaction overview diagrams
and timing diagrams).
Activity Diagrams
· Activities, actions, edges, decision nodes, merge nodes, partitions,
fork nodes, join nodes, objects in activities
· The development of Activity Diagrams during business analysis to
model workflow and business processes
Dynamic Modelling
· States, transitions, actions and events
Traceability
· from Requirements through to Implementation 7
 Overview of the Module
Lectures: 2 per week
Labs: 2 hours per week - working on group coursework

Students MUST attend all classes

8
 Teaching Material
All Material will be on Black board
• Module Notes (Part A and B ):
- will be made available
• Powerpoint Slides
- will be uploaded

• Textbook ….. UML @ Classroom

- free e-book … will be referenced in Lectures

Students MUST refer to Handbooks AND Slides

– Slides include :
• updated information, additional examples etc

9
Assessments:

• Coursework 50%
– Practical Group-Based Assignment

• Exam 50%
– Duration 2 Hrs

10
Plagiarism and Collusion !!!!!!!!

Do NOT do it !!!!!!

11
 Coursework
• Group based assignment

• All students must contribute

– will include peer assessment

• Students will identify own groups

12
 Coursework
Coursework
– get yourself into groups (3 or 4 students)
– one student from group will email me with list of group
members
• I will reply with a unique group number
• This MUST be done AS SOON AS POSSIBLE

• Any student NOT in a group will be assigned to

existing/new group

• Meetings with ‘Customer’ in week 5/6 and week 8/9

13
Literature

 The recommended book:

UML @ Classroom:
An Introduction to Object-Oriented Modeling
Martina Seidl, Marion Scholz, Christian Huemer
and Gerti Kappel
Springer Publishing, 2015
ISBN 3319127411

This book is used throughout the

module.

3
Literature

Topological UML Modeling: An Improved

Approach for Domain Modeling and
Software Development
20 Jun 2017 by Janis Osis

This a very detailed book about the use of

UML within specific aspects of
Software Development.

The first few chapters cover the various

uses of UML. The rest of the book is NOT
relevant to this module

This book is for information ONLY

15
 textbooks
Other useful books 

Schaum’s Outlines – UML; Bennett, Skelton & Lunn, McGraw-Hill (2005) second edition
ISBN 0-07-710741-1

 
• Bennet, Skelton & Lunn (2005), Schaum's Outlines - UML, 2nd Ed, McGraw-Hill [ISBN
0-07-710741-1]
• Perdita Stevens (2006), Using UML: Software Engineering With Objects And
Components, 2nd Ed, Addison Wesley [ISBN 0-321-26967-5]
• Martin Fowler (2006), UML Distilled: A Brief Guide To The Standard Object Modelling
Language, 3rd Ed, Addison Wesley [ISBN 0-321-19368-7]
• Dennis, Wixom and Tegarden (2005), Systems Analysis And Design With UML Version
2.0 An Object-Oriented Approach, 2nd Ed, Addison Wesley [ISBN 90-471-65920-7]

16
 From the Overview of the Module

• Understand and apply object oriented

techniques to the analysis and design
of software systems

* analysis and design are the 1st two stages of the

Software Development Process (also known as the
Software Process or Software Life Cycle)

17
 What is the Software Process?
• It is the cornerstone of successful software
engineering
• It is the Life Cycle that the software goes through from
conception to retirement
– A set of activities that covers the complete life span
of a piece of software
– Activities commence when the software is
envisaged, through its development stage
– Continuing through its operational lifetime
– Until it is finally ‘retired’
– Life cycle model links these activities

18
 Main life cycle Models

Some Life Cycle Models include the following …..

19
 The Waterfall Model

The “traditional” approach to software

development is to use the waterfall model.
The expectation is to complete each step
before proceeding to the next step in the
process.

The next slide outlines the steps in this

model.
The waterfall model
 Incremental Approach

There are alternatives to the Waterfall

model. These alternatives come under the
name “Agile”.
Agile approaches utilise a different
“ordering” of the development steps.
Incremental Development
 Agile Development
Fundamental Characteristics are:

Specification,Design and implementation are interleaved

The system being built is developed in a series of versions
An interactive approach is used to develop the User
Interface
The key then is to develop the system in increments
Ideally increments should be made available to customers
every 2 or 3 weeks involving customers in the
development process.
 Main life cycle activities
(common to all models)
Even, though these life cycle models were different -
they still included the activities ( may have used
slightly different names ):

1. Analysis
2. Design
3. Coding
4. Testing
5. Maintenance
25
Systems analysis :
– to understand what the system must do.

Systems design:
– to specify/plan how the components are
configured to provide the solution.

26
 Systems Analysis
• Systems Analysis consists of those activities that
enable a person to UNDERSTAND and SPECIFY
what the new system should accomplish.

• Systems Analysis is much more than simply a

brief statement of the problem.

• Systems Analysis describes in detail the “what”

that a system must do to satisfy the need or to
solve the problem.
27
 Systems Design
• Systems Design consists of those activities
that enable a person to describe in detail
the system that SOLVES the need.
• In other words, systems design describes
“how” the system will work.
• It specifies in detail all the components of
the solution

28
 Different Scenarios
Scenario 1.
– Current System is a ‘manual’ Paper-based System (e.g.
Library using files/forms)
– Requires a new ‘computerised’ software system

Scenario 2.
– Customer would like a new software system
• no existing system

Scenario 3.
– Customer would like a new software system
• based on an existing system

29
Systems Analysis activities
1. Gather detailed information
2. Define requirements
3. Prioritize requirements
4. Develop user-interface dialogues
5. Evaluate requirements with users

30
 1. Gather Detailed Information

• Systems analysts obtain information from people

who will be using the system, either by
interviewing them or by watching them work.
• Analysts also study existing systems, including
their documentation.
• They try to understand an existing system by
identifying and understanding the activities of all
users

31
Information-Gathering Techniques

• Interviewing users and other stakeholders

• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business
procedures
• Researching vendor solutions
• Collecting active user comments and
suggestions

32
 2. Define Requirements
The analyst uses information gathered from users and
documents to define requirements for the new system.

• functional requirements
– the activities that the system must perform (i.e., the
business uses to which the system will be applied).

• non- functional requirements

– related issues such as user interface formats and
requirements for reliability, performance, and
security
33
Functional Requirements :
CategoriesExamples
Functions Business rules and processes

Non-functional Requirements :
Categories Examples
Usability User interface, ease of use
Reliability Failure rate, recovery methods
Performance Response time, throughput
Security Access controls, encryption
Implementation Development tools, protocols
Physical Size, weight, power consumption.
Installation and updates
34
 3. Prioritize Requirements

• Once the system requirements are well understood, it

is important to establish which requirements are most
crucial for the system.

• Sometimes, users suggest additional system functions

that are desirable but not essential.

• However, users and analysts need to ask themselves

which functions are truly important and which are fairly
important but not absolutely required.

35
 4. Develop User-Interface Dialogues

• To most users, the user interface is all that matters.

• Thus, developing user-interface dialogs is a powerful

method of eliciting and documenting requirements

• A user-interface prototype developed in an early

iteration can be expanded in later iterations to
become a fully functioning part of the system.

36
5. Evaluate Requirements with Users

• Analysts usually use an iterative process

in which they :
– obtain user input
– work alone to model requirements
– return to the user for additional input or
validation,
– work alone to incorporate the new input and
refine the models.

• Prototypes of user interfaces and other

parts of the system may also be developed
37
Why Build Models?

38
39
 System Modelling

This is the process of developing abstract

models of the system that is being developed.

This approach will involve some form of

diagram …. UML Diagram.

Models are used at different points in the

development process.
 Models and Modelling

• UML@Classroom
• Chapter 1

• Natural Language is not a good choice –

imprecise and ambiguous – can lead to
misunderstandings between technical
(analyst/designers) and non-technical (users)

41
 Models and Modelling
• Modelling is an important part of analysis and design.

• Analysts build models to describe system

requirements and use those models to communicate
with users and designers

• By developing a model and reviewing it with a user,

an analyst demonstrates an understanding of the
user’s requirements.

• If the user spots errors or omissions, they can be

updated into the model before it becomes the basis
for subsequent design and implementation activities.
42
Many graphical models used in system
development are drawn according to the
notation specified by the Unified Modeling
Language (UML).

43
 The UML (Unified Modelling Language)
• Unified Modeling Language (UML) is a standardized general-
purpose modelling language in the field of software engineering.

• One of the most widespread graphical object-Oriented Modelling

languages

• UML includes a set of graphical notation techniques to create

visual models of software-intensive systems.

• UML is used to specify, visualize, modify, construct and document

the artifacts (e.g. use cases, class diagrams etc.) of an object-
oriented software system under development.
44
 Brief History of UML
• Designed by G. Booch, J. Rumbaugh, I. Jacobson (3
amigos)

• Started in 1994, version 1.0 finished in 1997

• They put aside their own methods and notations to end the
OO method wars

• Previously there was a lack of standardization : every

method, tool, practice has their own set of symbols and
terminology

45
 Brief History of UML
• For several years UML maintained by OMG (Object
Management Group) revision task force which produced
versions 1.3, 1.4, and 1.5 from 2000 to 2003

• Official version of UML 2.0 adopted by OMG early 2005

(this is a major revision of UML1 and includes many
additional features and many changes were made to
previous constructs based on experience with the previous
version).

• Version 2.4.1 was published in 2012

• Version 2.5 has been published ( same diagrams as 2.4.1)

46
 UML Formal Definition
• “UML is a visual language for specifying, constructing, and
documenting the artefacts of systems.”

• “It is a general-purpose modelling language that can be

used with all major object and component methods, and
that can be applied to all application domains (e.g., health,
finance, telecom, aerospace) and implementation
platforms (e.g., J2EE, .NET).”

47
 UML
• UML offers a standard way to write system’s blueprints,
including conceptual things such as business processes
and system functions as well as concrete things such as
programming language statements, database
schemas, and reusable software components

• UML it is not restricted only for software modelling. It has

been used for modelling hardware, and is used for
business process modelling, systems engineering
modelling and representing organizational structure,
among many other domains

• Thus, UML has got a wide variety of uses

48
• In this Module – we will look at various uses of
UML within different types of Systems
– a wide range of examples/scenarios will be used within
the Lecture and Tutorial material

• In particular, we will be examining the use of

UML within Object Oriented Analysis and
Design ( using Patterns )

49
 Object Oriented Analysis and Design
(using Patterns )
• Topological UML : Chapter 2.2.3

• A general approach is to identify requirements, create

Domain/class model and add operations to software
classes, and define the messaging between the
objects to fulfill the requirements.

• Deciding what operations belong to which class and

how the objects should interact is important and not a
trivial task—it takes careful analysis and explanation.

50
 Object Oriented Analysis and Design
(using Patterns )
• Operations of a class are addressed as responsibilities of
this class.

• Responsibilities answer to two questions: “What to do?”

and “How to do?”; and they are assigned to classes of
objects during the object design.

51
 Object Oriented Analysis and Design
(using Patterns )
• A responsibility is not the same concept as an operation,
but operations are implemented to fulfil assigned
responsibilities.

• Patterns can be used to help assign responsibilities

• ( The use of patterns is covered in detail in the Level 3

Module : Application Architecture & Design Patterns)

• In this module – we will be examining a wide ranges of

uses of UML within Object Oriented Analysis and Design 52
The 1st three steps (Analysis/Design/Coding) in the Software
Process can be viewed as a Series Of Model Transformations

Architecture
Model
Requirement
s Solution Code
Model Model

Design
Model

For each of the models (boxes), the UML has its own models and
diagrams.
This Module will deal with the UML modelling of the Analysis
(Requirements) Model and the Design Model.
The order in which the module deals with these UML models will be the
order that an analyst might when analysing and designing a system.
 UML
UML diagrams represent two different views:

Structural (Static) View

• emphasizes the static structure of the system using
objects, attributes, operations and relationships.

Behavioural (Dynamic) View

• emphasizes the dynamic behaviour of the system by
showing collaborations among objects and changes to
the internal states of objects.

54
Note : Same Diagrams in later versions ( 2.4.1 and 2.5) 55
 UML
In this module – we will only cover the following diagrams in
detail :

Structural (Static) View

• Class Diagrams
• Object Diagrams
• Component Diagrams

Behavioural (Dynamic) View

• Use Case Diagrams
• Activity Diagrams
• State Machine Diagrams.
• Sequence Diagrams 56
• Communication Diagrams
 Object Orientation

Class
Object
Encapsulation
Messages
Inheritance
Polymorphism

57
 REMINDER

Email your group to me AS SOON AS POSSIBLE

58