Object Oriented System

Software engineering
1
 Course Outline- Core Topics
2
 Chapter I- Introduction
 Understanding motivations and common /basic concepts

 Chapter II- Modeling using UML

 Understanding modeling tools in software development
 Chapter III- Requirement elicitation
 Collecting and organizing users requirement- WHAT- User

needs
 Chapter IV- Requirement Analysis
 Analyzing and modeling requirements-WHAT System
 Chapter V- System and Object design
 Specifying the new system-HOW

 Chapter VI- Implementation, Testing and Pragmatic

 Making it a reality
 References
3

• Ambler, Scott W. (2001). The Object Prime.

2nd ed.
Bernd Bruegge and Allen H. Dutoit. (2000)
Object Oriented Software Engineering:
Conquering Complexity and Changing
systems
• Hoffer, Jeffrey, Joey F. Geodrge, and Joseph S.
Valacich. Moderen Systems Analysis and
Design. 3rd ed. Addison-Wesley: New York.
1999.
 Chapter One Topics
4

Chapter I- Introduction: (2 weeks)

 Definitions and basic concepts (system/software,

system thinking..)
 Structured Vs OO approaches

 Basic Object Orientation concepts

 Process Models (Waterfall, Prototyping, Iterative,

Rational Unified Process -RUP)

 Work flows (Phases)- in object orientation
 Chapter Objectives
5

Understanding motivations and basic

concepts in Object Oriented Systems
Analysis and Design
Recalling system development concepts
from previous courses
Covering basic concepts on software
development
Revisiting concepts of object orientation
 Terminologies
6

The product
 Information System
 Software

The process
 System Development
 Software Engineering
 Points to be recalled
7

System, systems concepts, systems thinking,

information systems, their types
 What is a system?
 Living Vs Non-living
 Open vs Closed
 9 characteristics of a system
 What is systems thinking?

 Why we need system thinking?

 What is an Information system?

 How many types are there?......Reading

Assignment
 Cont…
8

System development ultimate objectives

 Problem solving

 Supporting business processes

Participants and roles in system/software

production
 Users
 Mangers (owners)
 Analysts
 Designers
 Programmers/Developers
 Administrators
 Consultants
 Cont…
9

Scenarios Initiating system/software

development
 Real problem on the day to day task
 By end users
 Looking for effectives and efficiency
 By mangers
 Sensing new opportunities and technologies
 By technical personnel
 Cont…
10

Modeling
 A reduced representation of a reality
 Helps to see one aspect of the reality at a time

 Avoid complexity

Principles of modeling
 Best models are connected to reality
 No single model is sufficient
 Every model may be expressed at different precision
 Represent the reality from different perspectives
 What is system/software?
11

and associated
 Computer programs
documentation such as requirements, design
models and user manuals.
Software products may be developed for a
particular customer or for a general
market.
System products may be
 Generic - developed to be sold to a range of
different customers e.g. PC software such as MS
Office, Peachtree..
 Custom - developed for a single customer or
enterprise according to their specification.
 The Nature of Software...
12

Software is intangible
 Hard to understand the development effort

Software is easy to reproduce

 Cost is in its development
 Other product manufacturing or development
 manufacturing is the costly stage

 The cost of production may increase time after time

The industry is skill-intensive

 Hard to automate

 Involves many experts

 Difficult to understand what users need

 The Nature of Software ...
13

Untrained people can hack something

 Quality problems are hard to notice

Software is easy to modify

 People make changes without fully understanding it
Software does not ‘wear out’
 Once developed with the required functions, it remains as
it is as long as it is operational in the organization
 It deteriorates by having its design changed:
 erroneously, or in ways that it was not anticipated, thus
making it complex
 The Nature of Software
14

Conclusions
 Demand for software is high and rising
 Automation is a must have resource in

organizations
 Much software has poor design and is

getting worse
 We are in a perpetual/continuous

‘software crisis’
 We have to learn to ‘engineer’ software
 What are the attributes of good
system/software?
15

 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 and reliable;
 Efficiency
 Software should not make wasteful use of system
resources;
 Acceptability (meet users requirement or functionality)
 Software must accepted by the users for which it was
designed. This means it must be understandable, usable
and compatible with other systems.
 Software Quality...
16
Usability
 Users can learn it and fast and get their job done easily
Efficiency
 It doesn’t waste resources such as CPU time and
memory
Reliability
 It does what it is required to do without failing
Maintainability
 It can be easily changed whenever necessary
Reusability
 Its parts can be used in other projects, so
reprogramming is not needed
 System/Software Quality and the
Stakeholders
17
Customer/Organization: User:
solves problems at easy to learn;
an acceptable cost in efficient to use;
terms of money paid and helps to get work done
resources used

QUALITY
SOFTWARE

Developer: Development manager:

easy to design; sells more and
easy to maintain; pleases customers
easy to reuse its parts while costing less
to develop and maintain
 Types of system/Software...
18

Based on application nature

 Custom
 For a specific customer or organization or business unit
 Generic
 Sold on open market (consider general requirements)
 Often called
 COTS (Commercial Off The Shelf)

 Shrink-wrapped

 Embedded
 Built into hardware
 Hard to change
 Cont…
19

Differences among custom, generic and

embedded software
Custom Generic Embedded
Number of copies in use low medium high

Total processing power low high medium

devoted to running this type
of software

Worldwide annual high medium low

development effort
 System/Software
Applications
20

system software
real-time software
business software
engineering/scientific software
embedded software
Artificial Intelligence software
Web applications
 Software Development Life Cycle
21

• SDLC has several clearly defined phases

• Planning Identifying the problem and possible
solution
• Requirements gathering What does the user want?
• Systems analysis Understanding/documenting
requirements
• Design Planning a possible solution (Blueprint)
• Implementation Building a solution
• Testing the implementation Ensuring it meets
requirements
• Software Development is and iterative process
 Other parts of the life cycle
22

• Other aspects of developing software

• Feasibility analysis
• Checking whether the project is worth doing
• 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.
 Other aspects of developing software
23

Project management
 Estimating development time,

 Ensuring people are used effectively

 Ensuring good communication

 Create and maintain healthy work environment

 Managing budgets,

 Planning and undertaking Training and

 Project handover to the users

 These issues won’t be the major focus of this

course.
Why “Scientific” Methods
for system/software
development?
24
 Industry status (2009)
25

How well are systems built?

Challenged means…
Delayed, over budget, or lacking important
business requirements
System development Process/ Software
Engineering Process
26
A process used to create a software system
Consists of:
 Methods (steps)
 A sequence of step-by-step approaches that
help develop the information system
 Techniques
 Processes that the analyst follows to ensure
thorough, complete and comprehensive
analysis and design
 Tools
 Computer programs that aid in applying
techniques
 What are system/software engineering
methods?
27

 Tools + steps + techniques= Methodology

 Well organized and Structured approaches to software
development which include system models, notations,
rules, design advice and process guidance.
 Model descriptions
 Descriptions of graphical models which should be
produced;
 Rules
 Constraints applied to system models;
 Recommendations
 Advice on good design practice;
 Process guidance
 What activities to follow.
 Structured Vs Object Oriented Approaches to
system/software development
28

Structured paradigm
 Modeling process and data separately
 Suitable for small sized software

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
 29

Object-Oriented Concepts
and Principles
 Object Oriented paradigm
30

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
31

objects

problem domain
 Cont…
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
 Cont…
33

For system/software developer in

object orientation
 Object oriented programming
 Object Oriented Analysis, design

 Object Oriented CASE tools

 Cont…
34

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
 Cont…
35

Abstraction
Denotes essential characteristics of an
object that distinguishes it from all other
kinds of objects
 Object -> something in the real world
 Class -> collection of objects
 Superclass -> more general than subclasses
 Operation -> methods
 Attributes and associations -> instance variables
 Encapsulation
36

 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
 Encapsulation/Hiding
37
The object encapsulates
both data and the logical
procedures required to method method
manipulate the data #1 #2
data
method
method #3
#6

method method
#5 #4

Achieves “information hiding”

 Cont…
38

 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

 Promotes independent development and

maintenance
 Hierarchy
39

 Hierarchy
 Is a ranking or ordering of abstractions
 Inheritance
 The mechanism where features in a hierarchy inherit
from superclasses to subclasses
 “is a”
 A secretary is an employee...

 Aggregation
 The process of creating a new object from two or more
other objects.
 “part of”
 A car is an aggregation of engine, wheel, body...
An Example Inheritance Hierarchy
40

Inheritance
 The implicit possession by all subclasses of
features defined in its superclasses
 Class
Hierarchy
41 (superclass)
furniture

furniture

table chair desk shelf

subclasses of the
furniture
superclass
instances of chair
Objects, Classes, Polymorphism, Message,
Attributes, Methods

42

OTHER CENTRAL CONCEPTS

 Classes and Objects
43

Object
 A chunk of structured data in a running software
system

 Has properties
 Represent its state
 The data elements
 Has behavior
 How it acts and reacts
 May simulate the behavior of an object in the real world
Objects
44
 Classes
45

A class:
 A unit of abstraction in an object oriented (OO)

program

 Represents similar objects

 Its instances

 A kind of software module

 Describes its instances’ structure (properties)
 Contains methods to implement their behaviour
Is Something a Class or an Instance?
46
 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
 Film
 Class; instances are individual films. (Eg: Rush Hour,
Coming to America, etc)
 Reel of Film:
 Class; instances are physical reels

 Film reel with serial number SW19876

 Instance of ReelOfFilm

 Science Fiction Film

 Class; instances include ‘Star Wars’ and ‘The Matrix’

 Showing of ‘Star Wars’ in the Phoenix Cinema at 7 p.m.:

 Instance of ShowingOfFilm
Classes
47

• object-oriented
thinking begins with
the definition of a
class often defined as:
– template
– generalized description
– pattern
– “blueprint” ... describing
a collection of similar
items
• once a class of items
is defined, a specific
instance of the class
can be defined
 What is a Class?
48
things roles
• object-oriented occurrences organizational units

thinking begins with places external entities

the definition of a structures

class often defined as:

– template class name
– generalized description attributes:
– pattern
– “blueprint” ... describing
a collection of similar
items operations:
• once a class of items
is defined, a specific
instance of the class
can be defined
 Methods
(Operations, Services)
49

•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.
 Messages
50

sender object

attributes:

receiver object

attributes:
operations:

operations:

message:
[sender, return value(s)]

message: [receiver, operation, parameters]

 Methods, Operations and
Polymorphism
51

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)
 Methods, Operations and
Polymorphism
52

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
 Polymorphism
53

 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
To be continued on
54

PROCESS MODELS AND

WORK FLOWS/PHASES