300144
Object Oriented Analysis
SCC1 2021
Dr Mahsa Razavi
Lecture 1 Introduction to OOA
References
Unit Outline
Unit Learning Guide Textbook Chapter 1 Bhuvan’s book Chapter 1
Main Topics of Lecture
• Unit information
• Introduction to OOA
– Positioning Object Oriented Analysis
– Object Oriented Paradigm – About UML
Unit Information
General Information
• 300144/300888 Object Oriented Analysis/Adv. – Level 2
– 10 Credit Points
• Assumed Knowledge
– 300585 System Analysis and Design (prerequisite), 300131 Introduction to Analysis and Design or Equivalent
• Have gained sufficient knowledge from the prerequisites to understand and master the concepts about software system analysis and design that are discussed and presented in this OOA unit.
• Desirable
– Basic programming knowledge and skills
– Experience of using OO programming languages
How many of you have done Programming Fundamentals?
What will you learn?
• Analyses and models requirements using the object-oriented (OO) approach.
• Creates OO models in the problem space by using the Unified Modelling Language (version 2.0) as a modelling standard
• Consolidates and extends the knowledge gained from System Analysis and Design and applies it to practical OO analysis work through case studies.
The core strength of this unit is to analyse and model business objectives and critical requirements of software systems to be developed using object-oriented (OO) approaches. The system analysis is taken to greater depths within the context of Object Orientation. The Unified Modelling Language V2.0 is used as the modelling standard for creating OO models in the problem space. The unit also covers the rational unified process methodology and applications of design patterns for software development through practical case studies.*
7
How does the unit run?
• 4 Hours per week:
– two hour lecture (not compulsory but strongly recommended for update announcement, latest materials, and workbook exercises)
– two hour practical (mandatory)
• At least 6 hours self-study per week
• Lecture sessions
– scheduled for 13 weeks
• Practical sessions
– scheduled for 12 weeks (only 10 marked tutorial sessions)
– no practical sessions in first week
• Check Unit Learning Guide for further details
8
Assessment
• Participation/Practical*: 20% (Weekly performance and attendance)
– Attendance at practical sessions are mandatory
– There are 10 sets of individual/group work for 10 practical
sessions.
• Applied Project**: 30%, OO Analysis Model in a CASE tool + Deliverables Report
– Submission by the end of the last week of the semester or as specified in class
– Students with very low attendance and poor participation may fail this assessment (not allowed to join the project team)
9
Assessment (Cont.)
• Final Examination: 50%
• Criteria for passing the unit:
– Participation of all mandatory assessments
– Achievement of at least 50% overall
• Assessment for OOA students:
– Practical Exercises: 20% – Assignment: 30%
– Final Examination: 50%
10
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7
Week 8 Week 9 Week 10 Week 11 Week 12
Week 13 Week 14
Unit Schedule
Introduction
UML Modelling
Package
Use Case & Actors
Use Case & Activity Diagrams
Classes and Class Diagrams
Sequence, Interaction Overview & State Machine Diagrams
Interface and Prototyping
Revision
Quality Assurance & Acceptance Testing
Operational requirements in Analysis
Advanced Topics including Design Patterns and Final Discussion on Project
Consolidation and Preparation for final exam
Exam
(Subject to changes. See unit learning guide for more details.)
Textbook and References
• Textbook:
– Daoust, Norman, UML Requirements Modeling for Business Analysts: Steps to Modeling Success, 2012, Technics
12
Textbook and References
• Significant Reference (Old Textbook):
– Unhelkar, Bhuvan, Practical Object Oriented Analysis, 2005, Thomson Publishing; ISBN: 0170122980
13
Textbook and References (Cont.)
• Main reference book:
– Grady Booch, Object-Oriented Analysis and Design with Applications, 2nd
or 3rd , Addison-Wesley (available online).
– Craig Larman, Applying UML and Patterns: An introduction of Object- Oriented Analysis and Design and Iterative Development, 3rd Edition 2004, Addition Wesley Professional, ISBN 0-13-148906-2
– Erich Gamma et al, Design Patterns: Elements of Reusable Object- Oriented Software, 2004, Pearson Education, ISBN: 1405837306, 9781405837309
• Other references
– Seelearningguide
14
Changes in Response to Students’ Feedback
• Project groups are formed by students themselves with variable sizes (3~5 members).
• The mark of each project group member composed of group mark and individual mark.
• The individual mark is based on that of group and is subject to adjustment according to peer reviews.
• Add a briefing session for Applied Project in tutorial and lecture sessions
• Introduce real project case studies to demonstrate major stages of Rational Unified Process for software development.
• Introduce Design Patterns as the frame work in object oriented system design.
• Continuing and unabated efforts are undertaken to improve the teaching and learning experiences.
15
Fundamentals of Object Oriented Analysis
16
Module Outline
• Positioning Object Oriented Analysis – Phases of software development
• Object Oriented Paradigm
– Procedural programming paradigm – Object oriented paradigm
– Methods for OOA
• About UML
– A brief introduction to UML – UML 2.0 diagrams
17
Sub-module
• Positioning Object Oriented Analysis
– Major phases of software development – Where is OOA
18
Build your dream home
Analyse
Design
Build
Your dream home
Inspection
19
Software development
Analyse Testing
Design Coding
20
Positioning Object-Oriented Analysis
• Analysis: Precise abstraction of what the desired system must do, not how it will be done. There is an emphasis on finding and describing the objects –or concepts – in the system.
– Object-Oriented Analysis (OOA) is method which examines requirements from the perspective of the classes and objects found in the vocabulary of the system.
• Design: How the system will meet the requirements. There is an emphasis on defining software objects and how they collaborate to fulfill the requirements.
– Object-Oriented Design (OOD) refers to any method that encompasses the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.
21
Positioning Object-Oriented Analysis (Cont.)
• Implementation: Build a solution based on the design
– Object-Oriented Programming is a method of implementation in which programs are organised as cooperative collections of objects, each of which represents instance of some class, and whose classes are related to one another via composition and inheritance relationships.
22
Major phases of software development
• Phase 1: what are we making: system specification
– Who will use this system?
– What can those actors do with the system?
– How does this actor do that with this system?
OOA
– How else might this work if someone else were doing this, or if the same actor had a different objective?
– What problems might happen while doing this with the system?
Major phases of software development (Cont.)
• Phase 2: how will we build it – Name classes
– Data fields
– Member functions
OOD
• Phase 3: build the core
• Mapping designs to code in an OO language • Test-driven development and refactoring
• Phase 4: Testing and maintenance
OOP
Object-Oriented Approach
• OOA is just one phase of software development.
• No solution can be developed without further done
OOD and OOP
• You can’t be a system analyst if you do not know OOD and OOP
• You may even can’t fully understand OOA if you don’t have experience of OOD&OOP. Don’t stop at OOA; otherwise, you only have a drawing of cake to see but never have a cake to eat!
25
Why analysis?
• Analysis of a system requires
– when starting from scratch
– when responding to a change request during the maintenance of an existing system
• Its primary goal is to answer the question
– What is the problem that needs to be solved – requirements?
26
Requirement Analysis
• Requirements for a software system are initially generated during the analysis phase of software development and are, typically:
– simple statements of desired functional capabilities • “the system should allow its users to sort records by
priority”
– statements of non-functional capabilities
• “the system should support 10,000 simultaneous users” – statements of constraints that must be met
• “the system will be run cross platform”
27
Requirement Analysis (Cont.)
• The problem? Experienced developers will tell you that
– Requirements are usually incomplete and unable to tell the
whole story
– Requirements are typically wrong: factually wrong or become obsolete
– Requirements and users are misleading. Users may be non- technical and may not understand the range of options that could solve their problem.
– Most importantly, “requirements always change”. • Needs changes
• Better ideas
• Environment changes
OO analysis, design and programming techniques provide you
with powerful tools to handle changes to software. 28
Sub-module
• Object Oriented Paradigm
– What does OO mean?
– Procedural programming paradigm – Object oriented paradigm
– Advantage of OOA
– Methods for OOA
29
What does object orientation mean?
Object orientation is a modeling paradigm mainly used in computer programming. Prior to the rise of OOM, the dominant paradigm was procedural programming, which emphasized the use of discrete reusable code blocks that could stand on their own, take variables, perform a function on them, and return values. The object-oriented paradigm assists the programmer to address the complexity of a problem domain by considering the problem not as a set of functions that can be performed but primarily as a set of related, interacting Objects. The modeling task then is specifying those objects (or the Class the Objects belongs to) and their respective set of Properties and Methods, shared by all Objects members of the Class.
Based on Wikipedia
30
Procedural programming paradigm
Build a Castle
First story
Second story
Third story
Procedural programming paradigm (Cont.)
Procedural programming is a method of problem solving that decomposes a problem into functional steps and arranges the steps into an order so that the problem is solved along the way.
Visualization: flow charts Code style
Procedural programming paradigm (Cont.)
There are two main problems with this approach to design
• It creates designs centered around a “main program”. This program is in control and knows all of the details about what needs to be done and all of the details about the program’s data structures
• It creates designs that do not respond well to change requests. These programs are not well modularised and so a change request often requires modification of the main program; a minor change in a data structure, for example, might cause impacts throughout the entire main program.
“Many bugs originate with changes to the code”
“Things change. They always do. And nothing you can do to stop change from occurring to your software system.”
33
Object-oriented paradigm
Class: Tower Class: ArchDoor
Class: WallBlock
Class: Castle
Class: Class: Class:
Tower Cylinder Pyramid
Class: Class:
Cylinder Circle
Object-oriented paradigm (Cont.)
• OO Analysis & Design is centered around the concept of an object. It produces systems that consist of objects collaborating to fulfill the responsibilities (requirements) of the systems.
• Objects are conceptual units that combine both data and behavior
– The data of an object is referred to by many names attributes, properties, instance variables, etc.
– The behavior of an object is defined by its set of methods
• Objects inherently know what type they are. Its attributes allows it to keep track of its state. Its methods allow it to
function properly.
35
Why object-oriented?
“Hello World” code in C.
#include
{
printf(“Hello World\n”); }
class HelloWorldApp {
public static void main(String[] args) {
System.out.println(“Hello World!”); }
}
“Hello World” code in JAVA.
Can’t see OO is any better than procedural?
36
Why object-oriented? (Cont.)
C++ Code for building a castle in OO style
• Library
– Circle.h
– Cuboid.h
– Cylinder.h
– Pyramid.h
– Tower.h
– ArchDoor.h – WallBlock.h – Castle.h
• Application
– castleApp.cpp
May be more complicated than a procedural style code but think about what part of the code can be reused or can be shipped from other programs.
Why object-oriented? (Cont.)
Why can OO be more robust with changes?
Example: Print a triangle of stars in five lines
* ** *** *** * *****
#include
{
cout<<“ *”<
{
cout<<“ *”<
using namespace std;
class Triangle {
int height;
public:
void setHeight(int s)
{height=s;}
void print();
};
void Triangle::print() { for(inti=1;i<=height;i++){
for(int j=0;j
#include”Triangle.h”
using namespace std;
int main() {
int num; Triangle t; cout<<"Key in height of the
triangle: "; cin>>num; t.setHeight(num); t.print(); return0; *
} * * * * *
Feel free to playthis part.
for(int j=0;j