2-1

-1

Chapter Two
Object oriented analysis and modeling
(Part One)

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

 2-2
-2
OBJECT ORIENTED ANALYSIS AND MODELING
 Object-Oriented Analysis And Design (OOAD)
It’s a structured method for analyzing, designing a system by applying the object-
orientated concepts, and develop a set of graphical system models during the
development life cycle of the software.
 Object-oriented analysis (OOA):
It is an iterative stage of analysis, which takes place during the software development
life cycle, that aims to model the functional requirements of the software while remaining
completely independent of any potential implementation requirements.
 To accomplish this task via OOAD:
 an object-oriented analysis will focus everything through the lens of objects.
 an object is an instance of a thing that typically represents a real world object and has
all the same types of characteristics (properties), behaviors (methods), and states
(data).
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-3

In the object-oriented analysis, we:

Elicit requirements: Define what does the software
need to do, and what’s the problem the software
trying to solve.
Specify requirements: Describe the requirements,
usually, using use cases (and scenarios) or user
stories.
Conceptual model: Identify the important objects,
refine them, and define their relationships and
behavior and draw them in a simple diagram.
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-4
-4

OBJECT-ORIENTED DESIGN
The analysis phase identifies the objects, their relationship, and
behavior using the conceptual model (an abstract definition for the
objects).

While in design phase, we describe these objects (by creating class

diagram from conceptual diagram — usually mapping conceptual model
to class diagram), their attributes, behavior, and interactions.

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

 2-5
-5

In the object-oriented design,

we:

Describe the classes and their relationships using class diagram.

Describe the interaction between the objects using sequence

diagram.
Apply software design principles and design patterns.

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

 2-6

A class diagram gives a visual representation of the classes you need.

And here is where you get to be really specific about object- oriented
principles like inheritance and polymorphism.

Describing the interactions between those objects lets you better

understand the responsibilities of the different objects, the behaviors
they need to have.

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

 2-7
-7

SYSTEM MODELING

 System modeling is the process of developing models of the

system, with each model representing a different perspectives
of that system.

 The most important aspect about a system model is that it

leaves out detail; It’s an abstract representation of the system.

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

 2-8

The models are usually based on graphical notation, which is almost

always based on the notations in the Unified Modeling Language (UML).

Other models of the system like mathematical model; a detailed

system description.

Models are used during the analysis process to help to elicit the
requirements, during the design process to describe the system to
engineers, and after implementation to document the system structure
and operation.
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-9
-9

UML VIEWS
There is no sharpline between the various concepts and
constructs in UML, but for convenience, we divide them into several views.
A view is simply a subset of UML modeling constructs that represents one
aspect of a system.
One or two kinds of diagrams provide a visual notation for the concepts
in each views.
 The views used are not part of the UML specification.
 At the top level views can be divided into these areas:
 Structural classification
 Dynamic behavior ,
 Physical layout and
 Model management.

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

 2-10

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

 2-11

Structural classification describes the things in the

system and their relationships to other things.
 The classifier concept models things in a system.
Classifiers includeclass,use case, actor, node,
collaboration, and component.
Classifiers provide the basis on top of which
dynamic behavior is built.

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

 2-12

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

 2-13

Dynamic behavior describes the behavior of a

system or other classifier over time.
Behavior can be described as a series of changes
to snapshots of the system drawn from the static
view.

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

 2-14

Physical layout describes the computational

resources in the system and the deployment of
artifacts on them.

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

 2-15

Model management describes the organization of the

models themselves into hierarchical units.
The package is the generic organizational unit for models.
A model is a package hierarchy that provides a semantically
complete abstraction of a system from a particular viewpoint.
The model management view crosses the other views and
organizes them for development work and configuration
control.
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-16

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

 2-17
-17

SOFTWARE DEVELOPMENT PROCESS

 A software development process is the process of dividing software
development work into distinct phases to improve design, product
management, and project management.
 It is also known as a software development life cycle.

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

 2-18

Due to the importance of the development

process, various models have been proposed.
Waterfall Model
Prototyping model
Iterative Development model
Spiral model
Timeboxing Model

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

 2-19
-19
WATERFALL MODEL

 In this model,
Feasibility analysis  requirement analysis and project planning 
system design  coding  testing system installation

After system installation, the regular operation and

maintenance of the system takes place.

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

 2-20

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

 2-21

 advantages of this model is:

 its simplicity.
 divides the large task of building a software system into
a series of cleanly dividedphases, each phase dealing
with a separate logical concern.
 It is also easy to administer

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

 2-22

Limitations
It assumes that the requirements of a system can
be frozen (i.e., base lined) before the design
begins.
This is possible for systems designed to
automate an existing manual system.
But user requirements are usually unknown and
can be changed

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

 2-23

Freezing the requirements usually require choosing

s
hardware (because it forms a the the
of
part
specification).
 Large projects can take few requirements
years complet
e
to by then the hardware specified might be
obsolete.

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

 2-24

The entire software is delivered in one shot at the end. This

entails heavy risks, as the user does not know until the very end
what they are getting.

It is a document-driven process that requires formal documents at

the end of each phase.

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

 2-25
-25

PROTOTYPING
Instead of freezing the requirements before any design or coding
can proceed
a throw-awayprototype is built to help understand the
requirements.
Based on known requirement design, coding, and
testing of the prototype is done.
 The user interact with prototype and give feedback
Final results in more stable requirements that change less
frequently.

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

 2-26

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

 2-27

 Suitable for
 complicated and large systemsfor whichthere is no manual process or
existing system to help determine the requirements.
It is also an effective method of demonstrating the feasibility of a certain
approach.
Exception handling, recovery,and conformance to some standards
and formats are typically not included in prototypes.
minimal documentation need (design documents, a test plan, and a test case
specification are not needed )
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-28
-28

ITERATIVE DEVELOPMENT
 Basic
idea
Software developed in increments, each increment
adding some functional capability to the system unit the full
system is implemented
Combine thebenefits of both prototyping and
the waterfall model.

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

 2-29

 Advantage
better testing because testing each
increment is likely to be easier than testing the
entire system as in the waterfall model.
as in prototyping, the increments provide feedback to the client
that is useful for determining the final requirements of the system

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

 2-30
-30
THE ITERATIVE ENHANCEMENT MODEL
 The iterative enhancement model is an example of
this approach.
 Steps
 First create initial implementation & project
control list (tasks that must be performed to
obtain the final implementation.)
 Remove one task at a time and
 design  implement  analysis
The process is iterated until the project control
list is empty
MLITC-CS Dep-OOSE Course Chapter Two Compiled by: Alula T
 2-31

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

 2-32
-32

THE SPIRAL MODEL

 It is another iterative model that has been proposed
 Models do not deal with uncertainly which is inherent to software
projects.
 Important software projects have failed because project risks were
neglected & nobody was prepared when something unforeseen
happened.
 Barry Boehm recognized this and tired to incorporate the
“project risk” factor into a life cycle model.
 The result is the spiral model, which was presented in 1986.

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

 2-33

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

 2-34
-34
TIMEBOXING MODEL
Uses parallelism between the different iterations
a new iteration commences before the system produced by the current
iteration is released
 Each time box is divided into a sequence of stages
Each stage performs some clearly defined task for the iteration and
produces a clearly defined output.
 duration of each stage is the same
 team for a stage performs only tasks of that stage

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

 2-35

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

 2-36

 Example
 If the time box is of size T days, then the first software delivery will occur
after T days. The subsequent deliveries, however, will take place after every T/3 days.
 T is 9 weeks
 first delivery is made on 9th week, then 12th , 15th week

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

 2-37

 Linear execution of iterations,

 The first delivery will be made after 9

weeks,

 the second will be made after 18 weeks,

 the third after 27 weeks,

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

 2-38

 Man-power
 Suppose ;
 it takes 2 people 2 weeks to do the requirements for iteration,
 4 people 2 weeks to do the build for the iteration, and
 it takes 3 people 2 weeks to test and deploy.
If the iterations are serially executed, then the team for the project will be 4 people
(the maximum size needed for a stage)
If this project is executed using the timeboxing process model separate team is needed so
(2+4+3=9) peoples are needed
 Hence, the timeboxing provides an approach for utilizing additional man-power to reduce

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

 2-39

 If this project is executed using the timeboxing

process model separate team is
 needed so (2+4+3=9) peoples are needed
 Hence, the timeboxing provides an approach for
utilizing additional man-power to reduce the delivery
time.
 Timeboxing is well suited for projects that require a
large number of features to be developed in a short
time

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

 2-40

 Timeboxing is not suitable for

 Projects where it is difficult to partition the overall
development into multiple iterations of approximately
equal duration.
 It is also not suitable for projects where different
iterations may require different stages, and
 for projects whose features are such that there is no
flexibility to combine them into meaningful deliveries.

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