2/27/2020

SOFTWARE
ENGINEERING II
ANALYSIS AND DESIGNING

COMSATS Institute of Information Technology, Abbottabad

 2

Contents
• Analysis and Design
• Object oriented analysis and design
• OOA/D basic concepts
• Visual modeling
• UML
• A simple Example - Dice Game
• Use case
• Domain model
• Interaction diagram – sequence diagram
• Class diagram
• Applying UML
• Perspective of UL
• Unified process
• Iterative and evolutionary development
• Feedback and adaptation
• Benefits of iterative and evolutionary development
• Risk driven and client driven iterative planning
 3

Analysis and Design

• Analysis
• •Emphasizes on the investigation of the problem and
requirements rather than solution.
• Design
• •Emphasizes on a conceptual solution that fulfills the
requirements rather than its implementation
• Both are summarized the following phrase:
• “Do the right things (analysis),and do the things right
(design).”
 4

Object Oriented Analysis and Design

• Object Oriented Analysis
• •Emphasize on finding and describing the objects or
concepts in the problem domain.
• –E.g. Flight Information System: Plane, Flight, Pilot etc.
• Object Oriented Design
• •Emphasize on defining domain objects and how they
collaborate to fulfills the requirements.
• –E.g. Flight Information System has flightNumber attribute
and getFlightHistory behavior
 5

OOA/D Basic Concepts

• •Encapsulation
• –Combines a piece of information with the specific behavior
that act upon that information. The we package these into an
object.
• –E.g Bank Account: Account Number, balance, customer
name, address, account type, interest rate etc. with behavior of
open, close, deposit, withdraw, change account type etc.
• –Its like a one-stop shop for all changes related to account
information and behavior
• –It limits the effect of change
• •Information Hiding
• –It’s the ability to hide murky details of an object from the
outside world.
• –Provides the same benefits as Encapsulation
 6

OOA/D Basic Concepts

• •Inheritance
• –Mechanism to create new objects (child objects) based on old ones
(parent object). New objects inherit the qualities of its old object.
• –E.g.
• •Parent Class: Mammals
• •Child Class: Human, Cat, Dog etc.
• –Ease of maintenance
• •If mammals became cold-blooded only change Mammals property
• •Polymorphism
• –Dictionay: Occurrences of different forms, stages, or types
• –Having many forms or implementation of a particular functionality
• –Also exist in real word like inheritance
• –E.g.
• •Draw command can have different implementation for circle, line,
rectangle.
• •In Lab WhoAreYou() method of Car, Truck and Bus classes
 7

Visual Modeling
• •A simple picture explains a story of more than 100 words.
• •In Software Engineering to present system analysis and
designing results we also need a way of blueprints/visual
design to explain system analysis and design in easy way,
minimum time and overcome terminologies differences and
different understanding.
• •Blueprints helps you plan an addition before you built it.
• •Model helps you plan a system before you built it.
• •Modeling: User’s description of the Problem domain >
Requirements > Development team understanding >
Implementation/Code tracing to the requirements
• •Visual Modeling is the process of taking the information from
the model and displaying it graphically using some sort of
standard set of graphical elements. Standard is very important
to help in communication of the model.
 8

Visual Modeling
• •Industry known visual modeling notations are
• –Booch
• –Object Modeling Technology (OMT)
• –Unified Modeling Language (UML)
• •UML has been adopted by the majority of the industry as
well as the standards governing boards as ANSI and
OMG
 9

UML
• The Unified Modeling Language is a visual language for
specifying and documenting the artifacts of the system.
[OMG03a]
• •Uses diagrammatic notations
 10

Simple Example – Dice Game

• Problem Statement:
• A dice game can be played by one user. When player rolls
the die if the faces values are seven he wins otherwise he
lose.
• •How to analyze and then design this game?
• •Instead of traditional approach, We have a better
analysis and designing language called UML.
• •Use Cases
• •Domain Model / Conceptual Diagram / Conceptual object
Model
• •Class Diagram
 11

Use case
• Play a Dice Game: Player requests to roll the dice.
System presents results: If the dice face value totals
seven, player wins; otherwise, player loses.
 12

Domain model
 13

Interaction diagram- sequence diagram

 14

Class diagram
 15

Applying UML
• •UML as sketch – incomplete diagrams with text
• •UML as blueprint – Detailed design diagram to visualize
and understand the code.
• –Forward Engineering
• –Reverse Engineering
• •UML as Programming Language
 16

Perspective of UML
• –Conceptual: the diagrams are interpreted as describing
things in a situation of real word or domain of interest.
• –Specification: Diagrams describe the software
abstraction or components with no commitment to
particular implementation
• –Implementation: Diagrams describe software
implementation in a particular technology.
 17

Unified Process
• •Emerged as a popular iterative software development
process for building object oriented systems
• •UP is very flexible and open, and encourages including
skillful practices e.g.
• –XP
• –SCRUM,
• –Iterative lifecycle
• –Risk-driven development, into a cohesive and well-
documented process description
• •The UP is an iterative process
 18

Unified Process
• •Agile practices such as Agile Modeling are key to
applying the UML in an effective way
• •Iterative and evolutionary development—contrasted with
a sequential or “waterfall” lifecycle
• •Involves early programming and testing of a partial
system, in repeating cycles
• •We rely on short quick development steps, feedback, and
adaptation to clarify the requirements and design
 19

Iterative and Evolutionary Development

• •Development is organized into a series of short, fixed-length
(for example, three-week) mini-projects called iterations
• •The outcome of each is a tested, integrated, and executable
partial system
• •Each iteration has its own requirements analysis, design,
implementation, and testing activities
• •The system grows incrementally over time, iteration by
iteration, and thus this approach is also known as iterative and
incremental development
• •Embrace the change in each iteration and proceeds through a
series of structured build-feedback adapted cycles
• How Long Should an Iteration Be? What is Iteration
Timeboxing?
• A key idea is that iterations are timeboxed
 20

Feedback and Adaptation

• In complex, changing systems (such as most software
projects) feedback and adaptation are key ingredients for
success.
• •Feedback from early development, programmers trying
to read specifications, and client demos to refine the
requirements.
• •Feedback from tests and developers to refine the design
or models.
• •Feedback from the progress of the team tackling early
features to refine the schedule and estimates.
• •Feedback from the client and marketplace to re-prioritize
the features to tackle in the next iteration.
 21

Risk-Driven and Client-Driven Iterative

Planning
• •The UP (and most new methods) encourage a
combination of risk-driven and client-driven iterative
planning.
• –Identify and drive down the highest risks. Early iterations
focus on building, testing, and stabilizing the core
architecture
• –Build visible features that the client cares most about