UNIT ONE-PART ONE

INTRODUCTION

1
Course Title Object Oriented System Analysis
and Design
Course Number COSC3072

Degree Program BSc. In Computer Science

Credits/Contacts 4/4

Prerequisite COSC 2071

Semester 2nd Semester / Year III
Status of Course Compulsory
2
 Course Objectives and Competences to be acquired
 After successful completion of this course, students will be
able to:
 Software Engineering and Software Engineering Concepts
 Managing Software Development
 Differentiate structured approach and object oriented
approach.
 Understand the different object oriented concepts.
 Understand the basics of Enhanced Life Cycle of UP
 Understand and identify different types of System
Development Process Model
 Design and develop software applications using object
oriented principles
 Develop object oriented system models using UML
artifacts.
3
 Course Description
 This is the second system analysis and design course
offered in the program for future computer programmers,
systems analysts, system designers and IT project
managers.
 The course presents a detailed overview of the
approaches used by today’s information system
developers to discover and model the requirements to
deliver a successful system solution.
 The course focuses on tools and techniques that system
analysts use to develop Information Systems.
 The course mainly focuses on using Unified Modeling
Language (UML) artifacts that will be used to model
different aspects of the system at different phases of the
system development life cycle. 4
1. Introduction
1.1 Software Engineering and its Concepts
1.2 Managing Software Development
1.3 Nature of Software
1.3.1 Quality System
1.3.2 Bad System
1.3.3 Attributes of Quality System
1.4 System Development Life Cycle (SDLC)
1.5 System Development Paradigm
1.5.1 Structured Paradigm
1.5.2 Object Oriented Paradigm
1.6 Object Oriented Concepts
1.7 Potential benefits of Object Orientation
1.8 System Development Process Model 5
2.Object Oriented Requirement Gathering
2.1 Fundamentals of requirement and requirement
gathering method
2.2 Essential Use Case Modeling
2.3 Essential UI Prototyping and UI flow diagram
2.4 Domain Modeling using CRC card
2.5 Developing Supplementary Specification
2.6 Requirement validation and verification basics
3. Object Oriented System Analysis
3.1 Introduction to OO Analysis
3.2 System Use Case Modeling
3.3 Dynamic Modeling
3.4 Conceptual Modeling using
Class Diagram 6
4. Object Oriented System Design
4.1 Layering your models – Class Type Architecture
4.2 Class Modeling
4.3 State chart Modeling
4.4 Collaboration Modeling (Communication Diagram)
4.5 Component Modeling and Deployment Diagram
4.6 Relational Persistence Modeling
4.7 User Interface Design
5.Implementation and Testing
5.1 Documentation
5.2 Coding
5.3 Testing and Inspection
5.4 Deployment
5.5 Maintenance and User Support
7
Teaching and  Lecture
learning Methods  Discussion and case studies
 Laboratory,
 Demonstration
Assessment/Evalua  Theoretical Tests (20%)
tion and Grading  Assignment (10%)
System  Project work (20%)
 Final Exam (50%) 
Text Books 1. Dennis, A. and Barbara H. and David T; Systems
Analysis and Design: An Object-Oriented
Approach with UML. 5th ed. (2015): Wiley USA
 
Reference 1. Booch, G. and et. al. 3rd ed.(2007) Object-
Materials Oriented Analysis and Design with
Applications:.
2. Ashrafi, N.and Hessam Ashrafi 1st ed. (2014).
Object Oriented Systems Analysis and
Design.Pearson Education Limited, USA 8
 1.1 What is Software Engineering(SE)?
 SE is a profession dedicated to Analyzing , Designing,
Implementing, & modifying software so that it is of higher
quality, more affordable, maintainable, & faster to build.
 SE is concerned with theories, methods & tools for
professional software development.
 SE means the construction of quality software with a
limited budget & a given deadline.
 SE means the designing quality software systems
with a limited budget & a given deadline in the
context of constant change.
 SE is an engineering discipline that is concerned with
all aspects of software production from the early stage
of system specification to maintaining the system.
9
 What is Software Engineering(SE)?
 Object-Oriented Software Engineering
(OOSE) is a software design technique that
is used in software design in object-
oriented programming.
 OOSE is developed by Ivar Jacobson in
1992. OOSE is the first object-oriented
design methodology that employs use cases
in software design. OOSE is one of the
precursors of the Unified Modeling
Language (UML), such as Booch & OMT.
 It includes a requirements, an analysis, a
design, an implementation & a testing
model. 10
 Software Engineering Concepts
 The following definitions follow those of the IEEE
Standards on Software Engineering.
 A project is composed of a number of activities.
 Each activity is in turn composed of a number of tasks.
 A task consumes resources & produces a work product.
 A work product can either be a system, a model, or a
document.
 Resources are either participants, time, or equipment.
 All persons involved in a project (developers, project
manager, client, end users, etc.) are referred to as
participants(Stakeholders).
 A role is a set of responsibilities in the project or the
system.
 A role is associated with a set of tasks and is assigned to a
11
participant.
 Software Engineering Concepts
 The same participant can fill multiple roles.
 The term system refers to the underlying reality, and the
term model refers to any abstraction of the reality.
 A work product (deliverables) is an artifact that is
produced during the development, such as a document or a
piece of software.
 A work product for the project’s internal consumption is
called an internal work product, while a work product for
a client is called a deliverable.
 An activity is a set of tasks that is performed toward a
specific purpose, for example, delivery.
 Activities are also called phases.
 A task represents an atomic unit of work that can be
managed.
12
 Software Engineering Concepts
 Resources such as time, equipment, and labor, are assets
that are used to accomplish work.
 The project manager breaks down the work into tasks and
assigns them to resources.
 A goal is a high-level principle that is used to guide the
project. Goals define the attributes of a system that are
important.
 A functional requirement is an area of functionality that
the system must support, whereas a nonfunctional
requirement is a constraint on the operation of the system.
 A notation is a graphical or textual set of rules for
representing a model.
 A method is a repeatable technique for solving a problem.
 A methodology is a collection of methods for solving a
class of problems. 13
 Software Engineering Concepts

Project

*
Activity

is produced by * consumes

WorkProduct * Task * Resources

System Participant

Model Time

Document Equipment

14
 Managing Software Development
 Management activities focus on :
 Planning the project,
 Monitoring its status,
 Tracking changes, and
 Coordinating resources such that a high-quality product is
delivered on time and within budget.
 Hence managing software development includes
communication, software configuration management,
project management & software lifecycle
 Project management is needed because software
development is always subject to budget & schedule
constraints that are set by the organisation developing
the software
15
 The Nature of Software...
i. Software is intangible
 Hard to understand development effort
ii. Software is easy to reproduce
 Cost is in its development
 In other engineering products, manufacturing is the
costly stage
iii. The industry is labor-intensive
 Hard to automate
iv. Untrained people can hack something together
 Quality problems are hard to notice
v. Software is easy to modify
 People make changes without fully understanding it
16
vi. Software does not ‘wear out’
 It deteriorates by having its design changed:
 Erroneously, or in ways that were not anticipated,
thus making it complex
Conclusions
 Much software has poor design and is getting worse
 Demand for software is high and rising
 We are in a perpetual ‘software crisis’
 We have to learn to ‘engineer’ software

17
What is Quality Software/System?
 Take few minutes to Enumerate
from the:
 End Users,
 Developers,
 Customers and
 Developing company’s point of view

18
 What are the Attributes of good System/Software?
 The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and acceptable.
 Maintainability
-Software must evolve to meet changing needs;
 Dependability
-Software must be trustworthy;
 Efficiency
-Software should not make wasteful use of system
resources;
 Acceptability (Meet Users Requirement)
 Software must accepted by the users for which it was
designed.
 This means it must be understandable, usable and
compatible with other systems. 19
 Usability
 Users can learn it and fast and get their job done
easily
 Reliability
 It does what it is required to do without failing
 Reusability
 Its parts can be used in other projects, so
reprogramming is not needed

20
 System/Software Quality and the Stakeholders
Customer: User:
 Solves problems at an
acceptable cost in terms  Easy to learn;
of money paid and  Efficient to use;
resources used  Helps get work
done
QUALITY
SOFTWARE

Developer: Development Manager:

 Sells more and
 Easy to Design; pleases customers
while costing less to
 Easy to Maintain;
develop and
 Easy to Reuse its parts
maintain
21
 Bad Systems
 A system is said to be bad when one of the following
issues are existed:
 Fail to meet requirements
 Poor performance
 Poor reliability
 Lack of usability
 Lack of reusability
 Lack of dependability
 Platform Compatibility and etc.
 Example difficulties:
 Not to schedule
 Not to budget
 Runaway = 100% over budget or schedule

22
 Reasons for Failure
 Complexity
 Shifting Requirements
 Bad Estimation
 Bad Management
 New Technology
 Must tackle complexity by, for example:
 Structure partitioning of problem
 Organized interaction of parts
 Ensure you achieve the task
 Systems are subject to the need for continuing change

23
 System Development Life Cycle (SDLC)
 SDLC is a process used by a systems analyst(stakeholders)
to develop an information system.
 Any high quality system requires SDLC in order to:
 Meets or exceeds Customer Expectations
 Complete the software project within the time frame
defined and budget allocated.
 To develop efficient and effective system that works in the
current and planned IT infrastructure,
 Release a system that is inexpensive to maintain and cost-
effective to enhance.
 SDLC is a type of methodology used to describe the process
for building information systems, intended to develop
information systems in a very deliberate, structured and
methodical way, reiterating each stage of the life cycle.
24
 SDLC adheres to important phases that are essential for
developers, such as planning, analysis, design, and
implementation.
 Several SDLC Models exist, the oldest of which —
originally regarded as "the Systems Development Life
Cycle" — is the Waterfall Model:
 It is a sequence of stages in which the output of each
stage becomes the input for the next.
 These stages generally follow the same basic steps, but
many different waterfall methodologies give the steps
different names and the number of steps seems to vary
between four and seven

25
 System/Software Development Life Cycle (SDLC)
 The life of a software system can be represented as a series
of cycle.
 A cycle ends with the release of a version of the system to
the customers.
 Software development life cycle encompasses the
phases/processes that a software developer goes through
when developing a new software.
 SDLC has several clearly 5-defined phases
System Planning
 includes initial investigation
System Analysis
 includes requirements capture/elicitation
System Design- Planning a possible solution
System construction and implementation
 includes system testing
System deployment and maintenance
26
 Requirement gathering and systems analysis are
performed iteratively.
 Design/Implementation/Testing are done
sequentially.
 Every system development models that have been
developed incorporates these basic phases into
their model, ex: - Waterfall Model, Iterative
Model, Unified Process etc

27
 Other Aspects of Developing Software/SDLC
 The following are Other aspects of developing software:
A)Project Scoping - putting limits on how much you will
develop
 Deals with putting limits on how much you want to
create/clearly specifying what you want to achieve.
B) Project Management
 Estimating development time, Ensuring people are used
effectively
 Ensuring good communication and a healthy work
environment
 Managing budgets, Training and handover

28
 C. Feasibility Analysis
 A feasibility study assesses the operational, technical,
and economic merits of the proposed system.
 There are three types of feasibility:
1. Technical Feasibility
2. Economic Feasibility
3. Operational Feasibility
1. Technical Feasibility
 Technical feasibility assesses whether the current
technical resources are sufficient for the new system.
 If they are not available, can they be upgraded to
provide the level of technology necessary for the new
system.
29
 2. Economic Feasibility
 Economic feasibility determines whether the money are
available to develop the system.
 Includes the purchase of:
 New equipment.
 Hardware.
 Software.
3. Operational Feasibility
 Operational feasibility determines if the human
resources are available to operate the system once it has
been installed.
 Users that do not want a new system may prevent it from
becoming operationally feasible.
3-30
 Structured Vs Object Oriented Approaches to
System/Software Development
1. Structured Paradigm
 Modeling process and data separately
 Suitable for small sized software
2. Object Oriented Paradigm
 Things are made up of objects
 Objects are identified having data and function
 Is a software development strategy based on the idea
of building systems/software from reusable
components called objects

31
 Object Oriented Paradigm
 An approach to the solution of problems in which all
computations are performed in the context of objects.
 The objects are instances of classes, which are:
 Data Abstractions
 Contain procedural abstractions that operate on the objects
 A running program can be seen as a collection of objects
collaborating to perform a given task
The OO Mindset
objects

problem domain
32
 Object Oriented Technology
 De –emphasizes procedures
 A system is made up of objects
 Users can more easily understand objects
Benefits
 Objects are reusable
 Maintenance cost are lowered
 Improved quality and maintainability
 For system/software developer in object orientation
 Object Oriented Programming
 Object Oriented Analysis, Design
 Object Oriented CASE Tools
33
 OOT is built up on a sound engineering foundation
whose elements we collectively called the object model.
 The Object model encompasses the principles of
 Abstraction
 Encapsulation
 Modularity
 Hierarchy
 Other Concepts
 Objects, Classes, Polymorphism, Message, Attributes,
Methods

34
A) Abstraction
 Denotes essential characteristics of an object that distinguishes it
from all other kinds of objects
 Abstraction
 Object -> something in the world
 Class -> objects
 Super class -> subclasses
 Operation -> methods
 Attributes and associations -> instance variables
B) Encapsulation
Hiding the inner workings of object’s operations from the outside
world and from other objects
• Example : a Monitor and CPU
Details can be hidden in classes
–This gives rise to information hiding:
 Programmers do not need to know all the details of a class 35
 The object encapsulates both data and the logical
procedures required to manipulate the data

method method
#1 #2
data

method
t h od
#6 me # 3

method method
#5 #4

Achieves “information hiding”

36
C) Modularity
The property of a system that has been decomposed in to a set of
cohesive and loosely coupled modules
Code can be constructed entirely of classes
Promotes understandability
D) Hierarchy
Is a ranking or ordering of abstractions
Inheritance
 The mechanism where features in a hierarchy inherit from
super classes to subclasses
 “is a”
Aggregation
 The process of creating a new object from two or more other
objects.
 “part of”
37
 A car is an aggregation of engine, wheel, body...
 An Example Inheritance Hierarchy

 Inheritance
 The implicit possession by all subclasses of
features defined in its super classes

38
 Class Hierarchy
furniture (superclass)

table chair desk "chable"

subclasses of the
furniture superclass

instances of chair

39
Objects, Classes, Polymorphism, Message,
Attributes, Methods

Other central concepts of OO

Approaches

40
 Classes and Objects
1) Object
A chunk of structured data in a running software
system
Object has its own properties
 Represent its state
Object has behaviour
 How it acts and reacts
 May simulate the behaviour of an object in the
real world

41
Objects

42
 2) Classes
 A class:
 A unit of abstraction in an object oriented (OO) program
 Represents similar objects or its instances
 It is a kind of software module
 Describes its instances’ structure (properties)
 Contains methods to implement their behavior
Is Something a Class or an Instance?
 Something should be a class if it could have instances
 Something should be an instance if it is clearly a single
member of the set defined by a class
 Let’s see the following examples to clearly understand the
difference between Class and Object:
 Film
 Class; instances are individual films.
 Reel of Film:
 Class; instances are physical reels
43
 Film reel with serial number SW19876
 Instance of ReelOfFilm
 Science Fiction Film
 Class; instances include ‘Star Wars’
 Showing of ‘Star Wars’ in the Phoenix Cinema at 7 p.m.:
 Instance of ShowingOfFilm
 Object-oriented thinking begins with the definition of a
class often defined as:
 Template
 Generalized description
 Pattern
 “Blueprint” ... describing a collection of similar items
 A meta-class (also called a superclass) is a collection of
classes
 Once a class of items is defined, a specific instance of the
class can be defined 44
 Building a Class

class name

attributes:

operations

attributes:
operations:

45
 3) Methods (Operations, Services)
 An executable procedure that is encapsulated in a class
and is designed to operate on one or more data
attributes that are defined as part of the class.
 A method is invoked via message passing.

sender object

attributes:
Messages
receiver object

attributes:
operations:

operations:

message:
[sender, return value(s)]

message: [receiver, operation, parameters] 46

 Methods, Operations and Polymorphism
A) Operation
 A higher-level procedural abstraction that specifies a
type of behaviour
 Independent of any code which implements that
behaviour.
 E.g. calculating area (in general)
B) Method
 A procedural abstraction used to implement the
behaviour of a class.
 Several different classes can have methods with the
same name
 They implement the same abstract operation in ways
suitable to each class.
 E.g. calculating area in a rectangle is done differently
from in a circle 47
 C) Polymorphism
 The mechanism by which several methods can have the
same name and implement the same abstract operation.
 A property of object oriented software by which an
abstract operation may be performed in different ways
in different classes.
 Requires that there be multiple methods of the
same name
 The choice of which one to execute depends on
the object that is in a variable
 Reduces the need for programmers to code many
if-else or switch statements
48
 Variety of Software Products
Examples
Real Time: -------- air traffic control
Embedded Systems: ----- digital camera, GPS
Data Processing: --- telephone billing, pensions
Information Systems:---- web Sites, Digital libraries
Sensors:--------------- weather data
System software: --- operating systems, compilers
Communications:-- routers, mobile telephones
Offices: --- word processing, video conferences
Scientific:---- simulations, weather forecasting
Graphical: ---- film making, design etc., etc.,
etc., .... 49