OOSE Chapter One

1-1
-1
Chapter One
Overview of object-oriented
Software Engineering
MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

1-2
-2
 Chapter Contents
• Introduction
• Software development lifecycle
• Development paradigm
• Unified modeling language (UML)

1-3
-3
Introduction
Definitions
• Software is the collection of computer programs
procedures, rules, and associated documentation and data.
• Software engineering is an engineering discipline that is
concerned with all aspects of software production from the
early stages of system specification through to maintaining
the system after it has gone into use.
MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula

3 T
1-4
Introduction
Software Engineering: A Working Definition
• Software Engineering is a collection of techniques,
methodologies and tools that help with the
production of
A high quality software system developed with a given budget
before a given deadline while change occurs
Challenge: Dealing with complexity and

change
20
1-5
Introduction
In software engineering we are not dealing with
programs that people build to illustrate something
or for hobby i.e student systems).
Instead the problem domain is the software that
solves some problem of some users where larger
systems or businesses may depend on the
software, and where problems in the software can
lead to significant direct or indirect loss. i.e
industrial strength software.
MLITC-CS Dep-OOSE Course Chapter One 5 5
1-6
Introduction
The Software Engineering approach
• The three main forces that govern quality
(Q)&productivity (P) are the people, processes,
and technology, often called the Iron
Triangle.
MLITC-CS Dep-OOSE Course Chapter One 6

1-7
Introduction
The basic approach of software engineering is to separate the
process for developing software from the developed product (i.e., the
software).
The premise is that to a large degree the software process
determines the quality of the product and productivity achieved.
A development process consists of various phases, each phase
ending with a defined output.
The phases are performed in an order specified by the process

model being followed.
MLITC-CS Dep-OOSE Course Chapter One 7 7
1-8
-8
TWO ORTHOGONAL VIEW OF SOFTWARE

Traditional technique
The traditional techniques view software, as acollection of
programs (or functions) and isolated data.
 focuses on the functions of the system-What is it doing?
Object oriented methodologies
Object-oriented systems development centers on the
object, which combines data and functionality.

1-9
-9
SUMMARY OBJECT ORIENTED Vs TRADITIONAL TECHNIQUES
TRADITIONAL APPROACH OBJECT ORIENTED

SYSTEM DEVELOPMENT
Collection of procedures(functions) Combination of data and functionality
Focuses on function and procedures, Focuses on object, classes, modules
different styles and methodologies for that can be easily replaced, modified
each step of process and reused.
Moving from one phase to another phase Moving from one phase to another phase
is complex. is easier.
Increases duration of project decreases duration of project
Increases complexity Reduces complexity and redundancy

1-10
-10
OBJECT ORIENTED SYSTEM DEVELOPMENT METHODOLOGY.
object-oriented systems development is a way to develop software by building self-
contained modules or objects that can be easily replaced, modified, and reused.
It encourages a view of the world as a system of cooperative and collaborating
objects.
In an object-oriented environment, software is a collection of discrete objects that
encapsulate their data as well as the functionality to model real-world "objects."
An object orientation yields important benefits to the practice of software
construction.
 Each object has attributes (data) and methods (functions).
Objects are grouped into classes; in object-oriented terms, we discover and describe
the classes involved in the problem domain.

1-11
-11
Object-Oriented Software Engineering (OOSE)
JACOBSON OOSE
 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.
 It includes requirements, an analysis, a design, an
implementation and a testing model.

1-12
-12
Object oriented software

engineering

1-13
-13
OBJECT-ORIENTED SOFTWARE ENGINEERING LIFE CYCLE

 Requirements Engineering:
 requirements gathering,
 Object oriented analysis and
 specification
 OO Design:
 architectural design
 detailed design
 both require the transformation of functional requirements into OO design elements
 Implementation or Coding:
 Programming using OO programming languages and tools.
 Testing:
 unit testing; test methods within each object
 integration testing; test collaborations between objects
 system testing; test the entire system as a collection of objects
 acceptance testing; test for standards and customer satisfaction

1-14
-14
WHY AN OBJECT ORIENTATION?

 Higher level of abstraction:
 The object-oriented approach supports abstraction at the object level.
Since objects encapsulate both data (attributes) and functions
(methods), they work at a higher level of abstraction.
The development can proceed at the object level and ignore the
rest of the system for as long as necessary.
This makes designing, coding, testing, and maintaining the
system much simpler.

1-15
 Seamless transition among different phases of software development:

The traditional approach to software development requires different styles
and methodologies for each step of the process.
Moving from one phase to another requires a complex transition of
perspective between models that almost can be in different worlds.
This transition not only can slow the development process but also
increases the size of the project and the chance for errors introduced in
moving from one language to another.
The object-oriented approach, on the other hand, essentially uses the
same language to talk about analysis, design, programming, and database
design.
This seamless approach reduces the level of complexity and redundancy
and makes for clearer, more robust system development

1-16
 Encouragement of good programming technique:

A class in an object-oriented system carefully delineates between its
interface (specifications of what the class can do) and the
implementation of that interface (how the class does what it does).
The routines and attributes within a class are held together
tightly.
In a properly designed system, the classes will be grouped into
subsystems but remain independent; therefore, changing one class
has no impact on other classes, and so, the impact is minimized.

1-17
However, the object-oriented approach will promote perfect design

or perfect code by raising the level of abstraction from the function
level to the object level and by focusing on the real-world aspects of
the system, the object-oriented method tends to promote clearer
designs, which are easier to implement, and provides for better overall
communication.
Using object-oriented language is not strictly necessary to
achieve the benefits of an object orientation.
However, an object-oriented language such as C+ +, Smalltalk, or
Java adds support for object-oriented design and makes it easier to
produce more modular and reusable code via the concept of class
and inheritance.

1-18
 Promotion of reusability:
Objects are reusable because they are modeled directly out of a real—world
problem domain.
Each object stands by itself or within a small circle of peers (other objects).
Within this framework, the class does not concern itself with the rest of the
system or how it is going to be used within a particular system.
This means that classes are designed generically, with reuse as a constant
background goal.
Furthermore, the object orientation adds inheritance, which is a powerful
technique that allows classes to be built from each other, and therefore, only
differences and enhancements between the classes need to be designed
and coded.
All the previous functionality remains and can be reused without change.

1-19
-19
OBJECT ORIENTED CONCEPTS
1)abstraction
2) encapsulation
3) modularity
4) hierarchy

1-20
-20
PRINCIPLE 1: ABSTRACTION
 A process allowing to focus on most important aspects while
ignoring less important details.
Abstraction allows us to manage complexity by concentrating

on essential aspects making an entity different from others.
PRINCIPLE 2: ENCAPSULATION
 Encapsulation separates implementation from users/clients.
 A client depends on the interface.

1-21
-21
PRINCIPLE 3: MODULARITY
 Modularity breaks up complex systems into small, self-
contained
 pieces that can be managed independently.

1-22
-22
PRINCIPLE 4: HIERARCHY
Ordering of abstractions into a tree-like structure.

1-23
-23
Notations, Methods, and Methodologies
Notation
 A notation is a graphical or textual set of rules for representing a model.
 The Roman alphabet is a notation for representing words. UML (Unified Modeling Language [OMG,
2009]), the notation we use throughout this course, is a notation for representing object-oriented
models.
 The use of notations in software engineering is common and predates object-oriented concepts.
 Data flow diagrams [De Marco, 1978] is a notation for representing systems in terms of data
sources, data sinks, and data transformations. Z [Spivey, 1989] is a notation for representing
systems based on set theory.
Method
 A method is a repeatable technique that specifies the steps involved in solving a specific
problem.
 A recipe is a method for cooking a specific dish. A sorting algorithm is a method for ordering
elements of a list.
 Rationale management is a method for justifying change.
 Configuration management is a method for tracking change.
1-24
-24
 A methodology is a collection of methods for solving a

class of problems and specifies how and when each
method should be used.
 A seafood cookbook with a collection of recipes is a
methodology for preparing seafood if it also contains advice on
how ingredients should be used and what to do if not all
ingredients are available.
 Royce’s methodology [Royce, 1998], the Object Modeling
Technique (OMT [Rumbaugh et al., 1991]), the Booch
methodology [Booch, 1994], and Catalysis [D’Souza &
Wills, 1999] are object-oriented methodologies for
developing software.

1-25
-25
 Software development methodologies decompose the process into activities.

 OMT provides methods for three activities:
 Analysis, which focuses on formalizing the system requirements into an object
model,
 System Design, which focuses on strategic decisions, and
 Object Design, which transforms the analysis model into an object model that
can be implemented.
 The OMT methodology assumes that requirements have already been defined and
does not provide methods for eliciting requirements.
 The Unified Software Development Process also includes an Analysis activity and
treats System Design and Object Design as a single activity called Design.
 The Unified Process, unlike OMT, includes a Requirements Capture activity for
eliciting and modeling requirements.
 Catalysis, while using the same notations as the Unified Process, focuses more on reuse of
design and code using patterns and frameworks.
 All of these methodologies focus on dealing with complex systems.
1-26
-26
Software Engineering Development Activities
As brief highlight/summary
 Object-oriented software development typically includes six development activities:
requirements elicitation, analysis, system design, object design, implementation, and testing.
» During requirements elicitation and analysis, software engineers formulate the problem with
the client and build the application domain model.
» Requirements elicitation and analysis correspond to steps 1 and 2 of the engineering method.
» During system design, software engineers analyze the problem, break it down into smaller
pieces, and select general strategies for designing the system.
» During object design, they select detail solutions for each piece and decide on the most
appropriate solution.
» System design and object design result in the solution domain model.
» System and object design correspond to steps 3 and 4 of the engineering method.
» During implementation, software engineers realize the system by translating the solution
domain model into an executable representation.
» Implementation corresponds to step 5 of the engineering method.
 What makes software engineering different from problem solving in other sciences is that change
occurs in the application and the solution domain while the problem is being solved.

1-27
-27
 It is an overview of the technical activities associated with object-oriented
software engineering.
 Development activities deal with the complexity by constructing and
validating models of the application domain or the system.
 Development activities include
 Requirements Elicitation
 Analysis
 System Design
 Object Design
 Implementation
 Testing
 Figure 1-1 (Next Slide) depicts an overview of the relationship among these
activities and their products.

1-28
-28

1-29
-29
Requirements Elicitation
 During requirements elicitation, the client and developers define the purpose
of the system.
 The result of this activity is a description of the system in terms of actors and
use cases.
 Actors represent the external entities that interact with the system.
 Actors include roles such as end users, other computers the system needs to
deal with (e.g., a central bank computer, a network), and the environment
(e.g., a chemical process).
 Use cases are general sequences of events that describe all the possible
actions between an actor and the system for a given piece of functionality.
 Figure 1-3 depicts a use case for the TicketDistributor example we discussed
previously.
1-30
-30

1-31
-31
Analysis
 During analysis, developers aim to produce a model of the system that is
correct, complete, consistent, and unambiguous.
 Developers transform the use cases produced during requirements elicitation
into an object model that completely describes the system.
 During this activity, developers discover ambiguities and inconsistencies in the
use case model that they resolve with the client.
 The result of analysis is a system model annotated with attributes, operations,
and associations.
 The system model can be described in terms of its structure and its dynamic
interoperation.
 Figure 1-4 depicts an example of dynamic model for the TicketDistributor.
 Figure 1-5 depicts an example of object model for the TicketDistributor.

1-32
-32

1-33
-33

1-34
-34

System Design
 During system design, developers define the design goals of the project and
decompose the system into smaller subsystems that can be realized by individual
teams.
 Developers also select strategies for building the system, such as the
hardware/software platform on which the system will run, the persistent data
management strategy, the global control flow, the access control policy, and the
handling of boundary conditions.
 The result of system design is a clear description of each of these strategies, a
subsystem decomposition, and a deployment diagram representing the
hardware/software mapping of the system.
 Whereas both analysis and system design produce models of the system under
construction, only analysis deals with entities that the client can understand.
 System design deals with a much more refined model that includes many entities
that are beyond the comprehension (and interest) of the client.
 Figure 1-6 depicts an example of system decomposition for the TicketDistributor.

1-35
-35

1-36
-36
Object Design
 During object design, developers define solution domain objects to bridge the
gap between the analysis model and the hardware/software platform defined
during system design.
 This includes precisely describing object and subsystem interfaces, selecting
off-the-shelf components, restructuring the object model to attain design
goals such as extensibility or understandability, and optimizing the object
model for performance.
 The result of the object design activity is a detailed object model annotated
with constraints and precise descriptions for each element.

1-37
-37
Implementation
 During implementation, developers translate the solution domain model into
source code.
 This includes implementing the attributes and methods of each object and
integrating all the objects such that they function as a single system.
 The implementation activity spans the gap between the detailed object design
model and a complete set of source code files that can be compiled.

1-38
-38
Testing
 During testing, developers find differences between the system and its models
by executing the system (or parts of it) with sample input data sets.
 During unit testing, developers compare the object design model with each
object and subsystem.
 During integration testing, combinations of subsystems are integrated together
and compared with the system design model. During system testing, typical
and exception cases are run through the system and compared with the
requirements model.
 The goal of testing is to discover as many faults as possible such that they can
be repaired before the delivery of the system.
 The planning of test phases occurs in parallel to the other development
activities:
 System tests are planned during requirements elicitation and analysis, integration
tests are planned during system design, and unit tests are planned during object
design.

1-39
Systems
• A system is an organized set of communicating parts
• Natural system: A system whose ultimate purpose is not known
• Engineered system: A system which is designed and built by
engineers for a specific purpose
• The parts of the system can be considered as systems again
• In this case we call them subsystems
Examples of natural systems:
• Universe, earth, ocean
Examples of engineered systems:
• Airplane, watch, GPS
Examples of subsystems:
• Jet engine, battery, satellite.
MLITC-CS Dep-OOSE Course Chapter One

1-40
Systems, Models and Views
• A model is an abstraction describing a system or a
subsystem
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual
rules for depicting models and views:
• formal notations, “napkin designs”
System: Airplane
Models:
Flight simulator Views:
Scale model Blueprint of the airplane components
Electrical wiring diagram, Fuel system
Sound wave created by airplane
Systems, Models and Views (“Napkin” Notation)
Flightsimulator
Aircraft
The picture can't be display ed. Fuel System
Blueprints Electrical
Scale Model Wiring
Views and models of a complex system usually overlap

1-42
Systems, Models and Views (UML Notation)
Class Diagram
* *
System Model View
Described by Depicted by
Airplane:
System
Object Diagram
Scale Model:Model Flight Simulator:Model
Blueprints: Fuel System: Electrical Wiring:

View View View
1-43
Model-Driven Development
1. Build a platform-independent model of an applications

functionality and behavior
a) Describe model in modeling notation (UML)
b) Convert model into platform-specific model
2. Generate executable from platform-specific model
Advantages:
• Code is generated from model (“mostly”)
• Portability and interoperability
• Model Driven Architecture effort:
• OMG: Object Management Group

1-44
Model-driven Software Development
Reality: A stock exchange lists many companies. Each
company is identified by a ticker symbol
Analysis results in analysis object model (UML Class Diagram):

StockExchange * * Company
Lists tickerSymbol
Implementation results in source code (Java):

public class StockExchange {
public m_Company = new Vector();
};
public class Company {
public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();
};
1-45
Application vs Solution Domain
• Application Domain (Analysis):

• The environment in which the system is operating
• Solution Domain (Design, Implementation):

• The technologies used to build the system
• Both domains contain abstractions that we can use for the

construction of the system model.

Object-oriented Modeling
Application Domain Solution Domain

(Phenomena) (Phenomena)
System Model (Concepts)(Analysis) System Model (Concepts)(Design)

UML Summary
Package MapDisplay Display
TrafficControl
FlightPlanDatabase
Aircraft TrafficController
TrafficControl
Airport FlightPlan
1-47
What is UML?
• UML (Unified Modeling Language)
• Nonproprietary standard for modeling software systems, OMG
• Convergence of notations used in object-oriented methods
• OMT (James Rumbaugh and collegues)
• Booch (Grady Booch)
• OOSE (Ivar Jacobson)
• Current Version: UML 2.5
• Information at the OMG portal http://www.uml.org/
• UML® specification (standard) is updated and managed by the
Object Management Group (OMG™) OMG UML
• Commercial tools: Rational (IBM),Together (Borland), Visual
Architect (business processes, BCD)
• Open Source tools: ArgoUML, StarUML, Umbrello
• Commercial and Opensource: PoseidonUML (Gentleware)
1-48
UML First Pass
• Use case diagrams
• Describe the functional behavior of the system as seen by the
user
• Class diagrams
• Describe the static structure of the system: Objects, attributes,
associations
• Sequence diagrams
• Describe the dynamic behavior between objects of the system
• Statechart diagrams
• Describe the dynamic behavior of an individual object
• Activity diagrams
• Describe the dynamic behavior of a system, in particular the
workflow.

1-49
UML Core Conventions
• All UML Diagrams denote graphs of nodes and

edges
• Nodes are entities and drawn as rectangles or ovals
• Rectangles denote classes or instances
• Ovals denote functions
• Names of Classes are not underlined

• SimpleWatch
• Firefighter
• Names of Instances are underlined
• myWatch:SimpleWatch
• Joe:Firefighter
• An edge between two nodes denotes a
relationship between the corresponding entities

1-50
UML first pass: Use case diagrams
Classifier
Use Case
Actor.
System boundary
Use case diagrams represent the functionality of the system

from user’s point of view
1-51
Historical Remark: UML 1 used packages
Package Use case

Watch
Actor
ReadTime
SetTime
WatchUser WatchRepairPerson
ChangeBattery
Use case diagrams represent the functionality of the system

from user’s point of view
1-52
UML first pass: Class diagrams
Association
Class
Multiplicity
SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time
Class diagrams represent the structure of the system

1-53
UML first pass: Class diagrams
Class diagrams represent the structure of the system
Association
Class
Multiplicity Watch
1 1 1 1
2
1 2 1
PushButton
state LCDDisplay Battery Time
push() blinkIdx Load Now
release() blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
Operations
Attribute referesh()

1-54
UML first pass: Sequence diagram
Actor Message Object Lifeline
:WatchUser :Watch :LCDDisplay :Time
pressButton1() blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButton1and2()
commitNewTime()
stopBlinking()
Activation
Sequence diagrams represent the behavior of a system

as messages
MLITC-CS Dep-OOSE Course (“interactions”)
Chapter One between different objects
1-55
UML first pass: Statechart diagrams
Event Initial state
button1&2Pressed button2Pressed
Blink Increment
Hours Hours
Transition button1Pressed
button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State
button1Pressed
button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
Final state
Represent behavior of a single object with interesting

MLITC-CS Dep-OOSE Course
dynamic
Chapter One
behavior.
1-56
Other UML Notations
UML provides many other notations, for example

• Deployment diagrams for modeling configurations
• Useful for testing and for release management
• We introduce these and other notations as we go along in the
lectures
• OCL(Object Constraint Language): A language for constraining UML models

1-57
What should be done first? Coding or Modeling?
• It all depends….
• Forward Engineering
• Creation of code from a model
• Start with modeling
• Greenfield projects
• Reverse Engineering
• Creation of a model from existing code
• Interface or reengineering projects
• Roundtrip Engineering
• Move constantly between forward and reverse engineering
• Reengineering projects
• Useful when requirements, technology and schedule are changing
frequently.

1-58
UML Basic Notation Summary
• UML provides a wide variety of notations for modeling

many aspects of software systems
• Today we concentrated on a few notations:
• Functional model: Use case diagram
• Object model: Class diagram
• Dynamic model: Sequence diagrams, statechart

OOSE Chapter One

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOSE Chapter One

Uploaded by

Copyright:

Available Formats

1-1

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula

Challenge: Dealing with complexity and

MLITC-CS Dep-OOSE Course Chapter One 6

The phases are performed in an order specified by the process

TWO ORTHOGONAL VIEW OF SOFTWARE

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

TRADITIONAL APPROACH OBJECT ORIENTED

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

Object oriented software

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

OBJECT-ORIENTED SOFTWARE ENGINEERING LIFE CYCLE

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

WHY AN OBJECT ORIENTATION?

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

 Seamless transition among different phases of software development:

MLITC-CS Dep-OOSE Course Chapter One 15

 Encouragement of good programming technique:

MLITC-CS Dep-OOSE Course Chapter One 16

However, the object-oriented approach will promote perfect design

MLITC-CS Dep-OOSE Course Chapter One 17

MLITC-CS Dep-OOSE Course Chapter One 18

OBJECT ORIENTED CONCEPTS

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

Abstraction allows us to manage complexity by concentrating

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

 A methodology is a collection of methods for solving a

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

 Software development methodologies decompose the process into activities.

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

Software Engineering Development Activities

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One Compiled by: Alula T

MLITC-CS Dep-OOSE Course Chapter One

Views and models of a complex system usually overlap

Scale Model:Model Flight Simulator:Model

Blueprints: Fuel System: Electrical Wiring:

1. Build a platform-independent model of an applications

MLITC-CS Dep-OOSE Course Chapter One

Analysis results in analysis object model (UML Class Diagram):

Implementation results in source code (Java):

• Application Domain (Analysis):

• Solution Domain (Design, Implementation):

• Both domains contain abstractions that we can use for the

MLITC-CS Dep-OOSE Course Chapter One

Application Domain Solution Domain

System Model (Concepts)(Analysis) System Model (Concepts)(Design)

MLITC-CS Dep-OOSE Course Chapter One