OOAD Session 9

8/11/2019 OOAD Session 9

1/57

Object Oriented Analysis and

Design using UML

Session9

By Dr. K. Satyanarayan Reddy


2/57

So far

4 July 2014 2

BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy


3/57

Requirementsare capabilities and conditions

to which the systemand more broadly, theprojectmust conform

The UP promotes a set of best practices, oneof which ismanage requirements.

In the context of inevitably changing and unclear

stakeholder's wishes"a systematic approach to

finding, documenting, organizing, and tracking the

changing requirements of a system

Evolutionary Requirements

4 July 2014 3



4/57

Types of Requirements In the UP, requirements are categorized

according to the FURPS+ model:

Functionalfeatures, capabilities, security.

Usabilityhuman factors, help,documentation.

Reliabilityfrequency of failure,recoverability, predictability.

Performanceresponse times, throughput,

accuracy, availability, resource usage.Supportabilityadaptability,

maintainability, internationalization,

configurability.4 July 2014 4BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy


5/57

Types of Requirements

The "+" in FURPS+ indicates ancillary and

sub-factors, such as:Implementationresource limitations,

languages and tools, hardware, ...

Interfaceconstraints imposed byinterfacing with external systems.

Operationssystem management in itsoperational setting.

PackagingFor example, a physical box

Legallicensing and so forth.

4 July 2014 5



6/57

Requirements Artifacts Organization

Vision Short document for describing or learningthe project's big ideas

Glossarynoteworthy terms used in the project

Supplementary Specification Basically, allnonfunctional requirements such as reports,documentation, supportability, licensing, and soforth.

UseCase Model A set of typical scenarios ofusing the system (functional requirements)

Business Rules requirements or policies thattranscend the software project (ex. govern. taxlaws)

4 July 2014 6



7/57

Not All the Requirements at Once

In Iterative Development We Do Not

Implement All the Requirements atOnce.

4 July 2014 7



8/57

Use CasesAn actor is something with behaviour, such

as:

a person (identified by role) - cashier

computer system

Organization

A scenariois a specific sequence of actionsand interactions between actors and thesystem under discussion; it is also called ause case instance.

AUse Caseis a collection of related successand failure scenar ios that describe actors using a system to support a goal.

4 July 2014 8



9/57

Not exactly requirements

specification but useful for a betterunderstanding of system

requirements.

The use-case model describes the

uses of the system and shows the

courses of events that can beperformed.

Can be at different levels of detail

Use Cases

4 July 2014 9



10/57

Use case describe the sequence of

events in using the system. Systematically identify uses of the

system and therefore the system'sresponsibilities.

Use cases illustrate and imply

requirements in the stories that theynarrate.

Use Cases

4 July 2014 10



11/57

Use Case Formality Types In addition to the b lack-box versus whi te-box

visibility type, use cases are written in varying

degreesof formality:Briefterse one-paragraph summary, usually of

the main success scenario.

The priorProcess Saleexample was brief.

Casualinformal paragraph format. Multipleparagraphs that cover various scenarios.

The priorHandle Returnsexample was casual.

Fully Dressedthe most elaborate. All steps andvariations are written in detail, and there aresupporting sections, such as preconditions andsuccess guarantees.

4 July 2014 11



12/57

Use Case Diagrams

4 July 2014 12



13/57

Most important and classic model in OO analysis

Domain Model illustrates meaningful concepts in a

problem domainRepresentation of real world things, not software

components

Set of static structure diagrams; no operations are

defined. It shows:

concepts (conceptual classes)

associations between concepts

attributes of concepts

Domain Model: What is it?

4 July 2014 13



14/57

Domain Model: Example

4 July 2014 14



15/57

Domain versus Design Model

4 July 2014 15



16/57

System Sequence Diagrams

Use cases describe:-

How actors interact with

system.

Typical course of events that

external actors generate and

The order of the events.

4 July 2014 16



17/57

System Sequence Diagrams(2)

For a particular scenario of

use-case an SSD shows-The external actors that interact directly

with the system.The System (as a black box).

The system events that the actors

generate.

4 July 2014 17



18/57

System Sequence Diagrams(3)

The operations of the system in

response to the events generated.System Sequence Diagrams depict

the temporal order of the events.

System Sequence Diagramsshould be done for the main

success scenario of the use-case,and frequent and alternativescenarios.

4 July 2014 18



19/57

SSDs are derived from use cases.

4 July 2014 19


D i M d l A d C t t


20/57

Domain Model And Contracts

A Domain Model is a visual

representation of conceptualclasses or real-world objects in a

domain of interest.

Contracts describe detailed

system behavior in terms of state

changes to objects in the DomainModel, after a system operation

has executed.4 July 2014 20BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy


21/57

Example Contract : enterItem

Operation: enterItem(itemID : ItemID,quantity : integer)

Cross References: Use Cases: Process Sale

Preconditions: There is a Sale Underway.

Postconditions: -A SalesLineItem instance sli was

created (instance creation)-sli was associated with the

current Sale (association formed)

-sli.quantity became quantity

(attribute modification)

-sli was associated with a

ProductSpecification, based onitemID match (association formed)

Contract CO2: enterItem

4 July 2014 21


C S


22/57

Contract Sections

Operation: Name Of operation, and parameters.

Cross References: (optional) Use cases this

can occur within.Preconditions: Noteworthy assumptions about the

state of the system or objects in

the Domain Model before execution

of the operation.

Postconditions: -The state of objects in theDomain Model after completion of

the operation.

4 July 2014 22



23/57

Unified Process Artifacts

Business Model

Requirements

Design

Domain Model

Use Case Model

Operation Contract

Use Case Text

System SequenceDiagrams

Interaction Diagrams

SupplementarySpecifications

Vision

Glossary

See Figure 11.1 in text for more detail4 July 2014 23BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy


24/57

Requirements To Design -

Iteratively

Obj ti


25/57

Objectives

Motivate the transition to design

activities.

Contrast the importance of objectdesign skill versus UML notation

knowledge.

4 July 2014 25


I t d ti


26/57

Introduction

Following the UP guidelines, perhaps10% of the requirements wereinvestigated in inception, and a slightly

deeper investigation was started in thisfirst iteration of elaboration.

Now we shift our emphasis towarddesigning a solution for this iteration interms of collaborating software objects.

4 July 2014 26



27/57

Iteratively Do the Right Thing, Do the

Thing Right

The requirements and object-oriented analysishas focused on learning to do the right thing;that is, understanding some of the outstanding

goals for the Next-Gen POS, and related rulesand constraints.

In iterative development, a transition fromprimarily a requirements focus to primarily adesign and implementation focus will occur ineach iteration.

4 July 2014 27


Did t Th t T k W k T D ? N


28/57

Didnt That Take Weeks To Do? No,

Not exactly.

When one is comfortable with the skills of usecase writing, domain modeling, and so forth, theduration to do all the actual modeling that hasbeen explored so far is realistically just a few

days.However that does not mean that only a few

days have passed since the start of project.Many other activities such as proof-of-concept

programming finding resources (people,software .) planning, setting up theenvironment could consume a few weeks ofpreparations.

4 July 2014 28


O t Obj t D i


29/57

On to Object Design

During object design, a logical solution

based on the object-oriented paradigm isdeveloped. The heart of this solution isthe creation of interaction diagramswhich illustrates how objects collaborateto fulfill the requirements.

After-or in parallel with-drawinginteraction diagrams,( design) classdiagramcan be drawn.

4 July 2014 29



30/57

On to Object Design

In practice, the creation of

interaction and class diagram

happens in parallel andsynergistically, but their

introduction is linear in this casestudy for simplicity and clarity.

4 July 2014 30


I t f Obj t D i Skill


31/57

Importance of Object Design Skill vs

UML Notation skill

Drawing UML interaction diagrams is thereflection of making decisions about the objectdesign.

The object design skills are what really matter,rather than knowing how to draw UML diagrams.

Fundamental object design requires knowledge of:

Principles of responsibility assignment

Design patterns4 July 2014

31BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy


32/57

Logical Architecture andUML Package Diagrams

Applying UML and Patterns

Definition


33/57

Definition

Software Architecture:

There are various forms of it. But thecommon theme is that it has to do

with large scale-the Big Ideas in theforces, organization, styles, patterns,

responsibilities, collaborations,

connections and motivations of asystem and major subsystems.

4 July 2014 33


Definition Variance


34/57

Definition Variance

In software development,

architecture is thought of as bothnoun and a verb.

As a noun, the architecture includesthe organization and structure of the

major elements of the system.

As a verb, architecture is partinvestigation and part design work.

4 July 2014 34


Definitions


35/57

Definitions

Architectural Investigation:

involves functional and non-functionalrequirements that have impact on system

design.

Some of these are:Market trends, performance, cost and points

of evolution.

Architectural Design:

It is the resolution of these requirements in

the design of software.4 July 2014


Architectural Dimension and Views in UP


36/57

Architectural Dimension and Views in UP

The common dimensions are:

The Logical Architecture, describesthe system in terms of its conceptual

organization in layers, packages,classes, interfaces and subsystems.

The Deployment Architecture,

describes the system in terms of theallocation of process to processing

unit and network configurations.4 July 2014


What is a Layer?


37/57

What is a Layer?

A Layer is a coarse grained

grouping of classes packagesor subsystems that has

cohesive responsibility for amajor aspect of the system.

Higher layers call upon theservices of lower layers.

4 July 2014 37


A hit t l P tt d P tt C t i


38/57

Architectural Patterns and Pattern Categories

Architectural Patterns:

Relates to large-scale design and typicallyapplied during the early iterations(in

elaboration phase).

Design Patterns:Relates to small and medium-scale design of

objects and frameworks.

Idioms:Relates to language or implementation-oriented

low-level design solutions.

4 July 2014 38


Architectural Pattern:Layers


39/57

Architectural Pattern:LayersIdea behind Layer patterns:

Organize the large-scale logical structure of a system

into discrete layers of distinct, related responsibilities

with a clean, cohesive separation of concerns such

that the lower layers are low-level and general

services, and the higher layers are more applicationspecific.

Collaboration and coupling is from higher to lower

layers.

4 July 2014 39


Inter Layer and Inter Package Coupling


40/57

Inter-Layer and Inter-Package Coupling

It is informative to include a

diagram in the logical view

that shows the coupling

between the layers and

packages.

Following figure shows the

coupling.4 July 2014


P ti l C li B t P k


41/57

Partial Coupling Between Packages

4 July 2014 41


Inter Layer and Inter Package Interaction


42/57

Inter-Layer and Inter-Package Interaction

Emphasizes the dynamics of

how objects across the layers

connect and communicate.

The interaction diagramfocuses on the logical view and

on the collaborations betweenthe layers and package

boundaries.4 July 2014 42


Package Diagrams


43/57

Package Diagrams

UML Package Diagrams are

often used to show the contentsof components, which are often

packages in the Java sense.Each package represents a

namespace.

Packages, as components, can

be nested inside other packages.4 July 2014


Package Diagram


44/57

Package DiagramUI Domain

Swing Web Sales

4 July 2014 44


Logical vs. Process and Deployment of


45/57

Logical vs. Process and Deployment of

Architecture

Architectural Layers are a logical

view of the architecture

They are not a deployment view of

elements to process.Depending on platform, all layers

could be deployed within the sameprocess on same node.

Or across many computers.4 July 2014


Terminology : Tier Layers and Partitions


46/57

Terminology : Tier, Layers, and Partitions

Tier relates to physical

processing node or clusters ofnode, such as client tier.

Layers of an architecturerepresent the vertical slices

Partitions represents a horizontaldivision of relatively parallel

subsystems of a layer.4 July 2014


Layers and Partitions


47/57

Layers and Partitions

4 July 2014 47


How do we design application logic with


48/57

How do we design application logic with

objects?

We could create one class and put alllogic in it, but that violates the whole

spirit of object orientation.

We create software objects with namesdrawn from the real world, and assign

application logic responsibilities to them.

It takes a lot of skill and experience to doa good job of choosing objects and

assigning responsibilities.4 July 2014


Domain Layer and Domain Model


49/57

Domain Layer and Domain Model

These are not the same thing. Domain

model shows the real world, while theDomain layer shows the software

architecture.

But the Domain model inspires theDomain layer, and is the source of many

of the concept, especially class names.

Do not confuse the problem with the

solution.

4 July 2014 49


Information Systems (IS)


50/57

Information Systems (IS)

In IS layered architecture was known

as three-tier architecture.A three-tier architecture has interface,Application logic and a storage.

The singular quality of 3-tier architectureis:

Separation of the application logic into

distinct logical middle tier of software.The interface tier is relatively free of

application processing.4 July 2014


Information Systems(cont )


51/57

Information Systems(cont..)

The middle tier

communicates with the

back-end storage layer.

The following is an

example of 3-tier architecture.

4 July 2014 51


Example:


52/57

Example:

4 July 2014 52


Two-tier Design


53/57

Two tier Design

In this design, the application

logic is placed within windowdefinitions, which read and

writes directly to database.There is no middle tier that

separates out the applicationlogic.

4 July 2014 53


The Model-View Separation Principle


54/57

The Model View Separation Principle

The principle states that

model(domain) objects should nothave direct knowledge of

view(presentation) objects.

Furthermore, the domain classes

should encapsulate the information

and behavior related to applicationlogic.

4 July 2014 54


Need for Model-View Separation


55/57

Need for Model View SeparationTo support cohesive model definitions

that focus on the domain process, ratherthan on interfaces.

To allow separate development of themodel and user interface layers.

To minimize the impact of requirementschanges in the interface upon the domainlayer.

To allow new views to be easilyconnected to an existing domain layer,without affecting the domain layer.

4 July 2014 55


Continued


56/57

Continued..

To allow multiple simultaneous

views on the same model object.To allow execution of the model

layer independent of the userinterface layer

To allow easy porting of themodel layer to another user

interface framework.4 July 2014



57/57

THANK YOU

Documents

OOAD Session 9