system analysis, design & implementation 2

7/29/2019 System analysis, Design & implementation 2

1/93

How can you explain the effect of

polluted water or global warmingissue?


2/93


3/93

1pictures worth 1000 words


4/93

UML & Business activitymodeling


5/93

Outline

UML

Business Activity Modeling


6/93

B Question

How many diagram in UML 1.4:1. 7

2. 8

3. 9

4. 105. 11

6. 12

7. 13

8. 14

9. 15


7/93

C Question

Key elements of the use-case diagram are:1. people, computers

2. actors, use-cases

3. people, classes, and objects

4. uses, cases5. scenarios in point form


8/93

C Question

In the UML notation, inside each class in a classdiagram are printed:1. its name, attributes, operations, and derived classes

2. its name, attributes and operations

3. its name, and attributes4. its name, and operations

5. just its name


9/93

C Question

An sequence diagram is: a time-line illustrating a typical sequence of calls between object

function members

a call tree illustrating all possible sequences of calls between

class function members a time-line illustrating the changes in inheritance and instantiation

relationships between classes and objects over time

a tree illustrating inheritance and relationships between classes

a directed acyclic graph illustrating inheritance and instantiationrelationships between classes and objects


10/93

A Question

What is the difference between Static/Structureview & Dynamic/Behavior view?


11/93

Unified Modeling Language


12/93

What is UML?

Unified Modeling Language OMG Standard, Object Management Group

Based on work from Booch, Rumbaugh, Jacobson

UML is a modeling language to express and design

documents, software Particularly useful for OO design

Not a process, but some have been proposed using UML

Independent of implementation language


13/93

Why use UML

Open Standard, Graphical notation for Specifying, visualizing, constructing, and documenting

software systems

Language can be used from general initial design to

very specific detailed design across the entire softwaredevelopment lifecycle

Increase understanding/communication of product tocustomers and developers

Support for diverse application areas

Support for UML in many software packages today(e.g. Rational, plugins for popular IDEs like NetBeans,Eclipse)

Based upon experience and needs of the user

community


14/93

Brief History

Inundated with methodologies in early 90s Booch, Jacobson, Yourden, Rumbaugh

Booch, Jacobson merged methods 1994

Rumbaugh joined 1995 1997 UML 1.1 from OMG includes input from

others, e.g. Yourden

UML v2.12 current version


15/93

History of UML


16/93

Contributions to UML


17/93

Diagrams

Structure diagram Object diagram

Class diagram

Component diagram

Deployment diagram

Package diagram

Composite structure diagram (UML 2.2)

Profile diagram (UML 2.2)

Behavior diagram

Interaction diagrams:

Sequence diagram

Collaboration diagram (communication diagram in UML 2.2)

Interaction overview diagram (UML 2.2)

Timing diagram (UML 2.2)

Use case diagram

Activity diagram

State diagram


18/93

Systems, Models and Views

A modelis an abstraction describing a subset of a system A viewdepicts selected aspects of a model

A notationis a set of graphical or textual rules for depictingviews

Views and models of a single system may overlap eachother

Examples:

System: Aircraft

Models: Flight simulator, machine model

Views: Radar, electrical wiring, fuel system


19/93

Systems, Models and Views

SystemView 1

Model 2View 2

View 3

Model 1

Aircraft

Flightsimulator

MachineModel

WeatherRadar

ElectricalWiring


20/93

UML Models, Views, Diagrams

UML is a multi-diagrammatic language Each diagram is a view into a model Diagram presented from the aspect of a particular stakeholder Provides a partial representation of the system Is semantically consistent with other views

Example views:


21/93

Models, Views, Diagrams


22/93

How Many Views?

Views should to fit the context Not all systems require all views

Single processor: drop deployment view

Single process: drop process view

Very small program: drop implementation view

A system might need additional views Data view, security view,


23/93

UML: First Pass

You can model 80% of most problems by usingabout 20 % UML

We only cover the 20% here


24/93

Basic Modeling Steps

Use Cases Capture requirements

Domain Model Capture process, key classes

Design Model Capture details and behaviors of use cases and domain objects

Add classes that do the work and define the architecture


25/93

UML Baseline

Use Case Diagrams

Class Diagrams

Package Diagrams

Interaction Diagrams Sequence

Collaboration

Activity Diagrams

State Transition Diagrams

Deployment Diagrams


26/93

Use Case Diagrams

Used during requirementselicitation to represent externalbehavior

Actorsrepresent roles, that is,a type of user of the system

Use casesrepresent asequence of interaction for atype of functionality; summaryof scenarios

The use case model is the set

of all use cases. It is acomplete description of thefunctionality of the system andits environment

Passenger

Purchase Ticket


27/93

Actors

An actor models an external entity whichcommunicates with the system:

User

External system

Physical environment An actor has a unique name and an

optional description.

Examples:

Passenger: A person in the train GPS satellite: Provides the system with GPS

coordinates

Passenger


28/93

Use Case

A use case represents a class offunctionality provided by the systemas an event flow.

A use case consists of:

Unique name

Participating actors

Entry conditions

Flow of events

Exit conditions

Special requirements

Purchase Ticket


29/93

Use Case Diagram: Example

Name:Purchase ticket

Participating actor:Passenger

Entry condition: Passenger standing in front of

ticket distributor.

Passenger has sufficientmoney to purchase ticket.

Exit condition:

Passenger has ticket.

Event flow:

1. Passenger selects the numberof zones to be traveled.

2. Distributor displays the amount

due.3. Passenger inserts money, of at

least the amount due.

4. Distributor returns change.

5. Distributor issues ticket.


30/93

The Relationship

relationships representexceptional or seldom invokedcases.

The exceptional event flows arefactored out of the main event flowfor clarity.

Use cases representingexceptional flows can extend morethan one use case.

Passenger

PurchaseTicket

TimeOut

NoChange

OutOfOrder

Cancel


31/93

The Relationship

relationshiprepresents behavior that isfactored out of the use case.

behavior isfactored out for reuse, notbecause it is an exception.

The direction of a relationship is to the using usecase (unlike relationships).

Passenger

PurchaseSingleTicket

PurchaseMultiCard

NoChange

Cancel

CollectMoney


32/93

Use Cases are useful to

Determining requirements New use cases often generate new requirements as the system is analyzed

and the design takes shape.

Communicating with clients

Their notational simplicity makes use case diagrams a good way fordevelopers to communicate with clients.

Generating test cases The collection of scenarios for a use case may suggest a suite of test cases

for those scenarios.


33/93

Use Case Diagrams: Summary

Use case diagrams represent external behavior

Use case diagrams are useful as an index into theuse cases

Use case descriptions provide meat of model, notthe use case diagrams.

All use cases need to be described for the model tobe useful.


34/93

Class Diagrams

Gives an overview of a system by showing itsclasses and the relationships among them. Class diagrams are static

they display what interacts but not what happens when they do interact

Also shows attributes and operations of each class Good way to describe the overall architecture of

system components


35/93

Class Diagram Perspectives

We draw Class Diagrams under three perspectives Conceptual

Software independent

Language independent

Specification

Focus on the interfaces of the software

Implementation

Focus on the implementation of the software


36/93

Classes Not Just for Code

A classrepresent a concept

A class encapsulates state (attributes)and behavior(operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information.

zone2pricegetZones()

getPrice()

TariffSchedule

Table zone2priceEnumeration getZones()PricegetPrice(Zone)

TariffScheduleName

Attributes

OperationsSignature

TariffSchedule


37/93

Instances

An instancerepresents a phenomenon.

The name of an instance is underlined and cancontain the class of the instance.

The attributes are represented with their values.

zone2price = {{1, .20},{2, .40},{3, .60}}

tarif_1974:TariffSchedule


38/93

UML Class Notation

A class is a rectangle divided into three parts Class name Class attributes (i.e. data members, variables) Class operations (i.e. methods)

Modifiers

Private: - Public: + Protected: # Static: Underlined (i.e. shared among all members of the class)

Abstract class: Name in italics

+getName() : string+setName()-calcInternalStuff(in x : byte, in y : decimal)

-Name : string+ID : long#Salary : double

Employee


39/93

UML Class Notation

Lines or arrows between classes indicate relationships Association A relationship between instances of two classes, where one class

must know about the other to do its work, e.g. client communicates toserver

indicated by a straight line or arrow

Aggregation An association where one class belongs to a collection, e.g. instructorpart of Faculty

Indicated by an empty diamond on the side of the collection

Composition Strong form of Aggregation

Lifetime control; components cannot exist without the aggregate Indicated by a solid diamond on the side of the collection

Inheritance An inheritance link indicating one class a superclass relationship, e.g.

bird is part of mammal Indicated by triangle pointing to superclass


40/93

Binary Association

myB.service(); myA.doSomething();

Binary Association: Both entities Know About each other

Optionally, may create an Associate Class


41/93

Unary Association

A knows about B, but B knows nothing about A

Arrow points in directionof the dependency

myB.service();


42/93

Aggregation

Aggregation is an association with a collection-member relationship

voiddoSomething()

aModule.service();

Hollow diamond onthe Collection side

No sole ownership implied


43/93

Composition

+getName() : string+setName()-calcInternalStuff(in x : byte, in y : decimal)

-Name : string+ID : long#Salary : double-adfaf : bool

Employee

-members : Employee

Team

1

*

Composition is Aggregation with:Lifetime Control (owner controls construction, destruction)Part object may belong to only one whole object

Filled diamond on side ofthe Collection

members[0] =new

Employee();

deletemembers[0];


44/93

Inheritance

Standard concept of inheritance

class B() extendsA

Base Class

Derived Class


45/93

UML Multiplicities

Multiplicities Meaning

0..1zero or one instance. The notationn . . m

indicatesn tom instances.

0..* or * no limit on the number of instances(including none).

1 exactly one instance

1..* at least one instance


46/93

UML Class Example


47/93

Association Details

Can assign names to the ends of the association togive further information

+getName() : string

+setName()-calcInternalStuff(in x : byte, in y : decimal)

-Name : string+ID : long#Salary : double-adfaf : bool

Employee

-members: Employee

Team -group

1

-individual

*


48/93

Static vs. Dynamic Design

Static design describes code structure and objectrelations Class relations Objects at design time Doesnt change

Dynamic design shows communication betweenobjects Similarity to class relations Can follow sequences of events May change depending upon execution scenario Called Object Diagrams


49/93

Object Diagrams

Shows instances of Class Diagrams and linksamong them An object diagram is a snapshot of the objects in a system

At a point in time

With a selected focus Interactions Sequence diagram

Message passing Collaboration diagram

Operation Deployment diagram


50/93

Object Diagrams

Format is

Instance name : Class name

Attributes and Values

Example:

O


51/93

Objects and Links

Can add association type and also message type

P k Di


52/93

Package Diagrams

To organize complex class diagrams, you cangroup classes into packages. A package is acollection of logically related UML elements

Notation Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle.

The dotted arrows are dependencies. One package depends on another ifchanges in the other could possibly force changes in the first.

Packages are the basic grouping construct with which you may organizeUML models to increase their readability

P k E l


53/93

Package Example

Dispatcher Interface

Notification IncidentManagement

M P k E l


54/93

More Package Examples

I i Di


55/93

Interaction Diagrams

Interaction diagrams are dynamic -- they describehow objects collaborate.

A Sequence Diagram: Indicates what messages are sent and when

Time progresses from top to bottom

Objects involved are listed left to right

Messages are sent left to right between objects in sequence

S Di F t


56/93

Sequence Diagram Format

Actor fromUse Case Objects

1

23

4

Lifeline Calls = Solid LinesReturns = Dashed Lines

Activation

S Di D t ti


57/93

Sequence Diagram : Destruction

Shows Destruction of b(and Construction)

S E l Al S t


58/93

Sequence Example: Alarm System

When the alarm goes off, it rings the alarm, putsa message on the display, notifies themonitoring service

Sequence Diagram Example


59/93

Sequence Diagram Example

Hotel Reservation

C ll b ti Di


60/93

Collaboration Diagram

Collaboration Diagrams show similar information tosequence diagrams, except that the verticalsequence is missing. In its place are: Object Links - solid lines between the objects that interact

On the links are Messages - arrows with one or more message name thatshow the direction and names of the messages sent between objects

Emphasis on static links as opposed to sequence inthe sequence diagram

C ll b ti Di


61/93

Collaboration Diagram

A ti it Di


62/93

Activity Diagrams

Fancy flowchart Displays the flow of activities involved in a single process States

Describe what is being processed Indicated by boxes with rounded corners

Swim lanes Indicates which object is responsible for what activity

Branch Transition that branch Indicated by a diamond

Fork

Transition forking into parallel activities Indicated by solid bars

Start and End

Sample Activity Diagram


63/93

Sample Activity Diagram

Ordering System

May need multiplediagrams from other

points of view

Activity Diagram Example


64/93

Activity Diagram Example



65/93


Fancy version of a DFA Shows the possible states of the object and the

transitions that cause a change in state i.e. how incoming calls change the state

Notation States are rounded rectangles Transitions are arrows from one state to another. Events or conditions that

trigger transitions are written beside the arrows. Initial and Final States indicated by circles as in the Activity Diagram

Final state terminates the action; may have multiple final states

State Representation


66/93

State Representation

The set of properties and values describing theobject in a well defined instant are characterized by Name

Activities (executed inside the state)

Do/ activity Actions (executed at state entry or exit)

Entry/ action

Exit/ action

Actions executed due to an event

Event [Condition] / Action ^Send Event

Notation for States


67/93

Notation for States

Simple Transition Example


68/93

Simple Transition Example

More Simple State Examples


69/93

More Simple State Examples

State Transition Example


70/93

State Transition Example

Validating PIN/SSN

State Charts Local Variables


71/93

State Charts Local Variables

State Diagrams can also store their own localvariables, do processing on them

Library example counting books checked out andreturned

Is-Member

Start / N=0

Return /

N=N-1

Borrow /

N = N+1

Clean-Up

Stop / N=0

Component Diagrams


72/93

Component Diagrams

Shows various components in a system and theirdependencies, interfaces

Explains the structure of a system

Usually a physical collection of classes Similar to a Package Diagram in that both are used to group elements intological structures

With Component Diagrams all of the model elements are private with apublic interface whereas Package diagrams only display public items.

Component Diagram Notation


73/93

Component Diagram Notation

Components are shown as rectangles with two tabsat the upper left

Dashed arrows indicate dependencies

Circle and solid line indicates an interface to thecomponent

Component Example Interfaces


74/93

Component Example - Interfaces

Restaurantorderingsystem

Define

interfacesfirstcomesfrom Class

Diagrams

Component Example Components


75/93

Component Example - Components

Graphical depiction of components

Component Example Linking


76/93

Component Example - Linking

Linking components with dependencies

Deployment Diagrams


77/93

Deployment Diagrams

Shows the physical architecture of the hardwareand software of the deployed system

Nodes Typically contain components or packages

Usually some kind of computational unit; e.g. machine or device (physical orlogical)

Physical relationships among software andhardware in a delivered systems

Explains how a system interacts with the external environment

Some Deployment Examples


78/93

Some Deployment Examples

Deployment Example


79/93

Deployment Example

Often the Component Diagram is combined with the Deployment

Sumary


80/93

Sumary


81/93

Business activity modeling

Why BAM


82/93

Why BAM

To ensure we are building customer-orientedsolutions, systems that please our customers, wemust not overlook the environment in which thesesystems will work

A good understanding of business processes isimportant to be able to build the right systems

UML diagrams for BAM


83/93

UML diagrams for BAM

Use case Activity

Class

Collaboration

Business use-case modeling


84/93

Business use case modeling

The first step in business modeling is to define theinteraction between your business processes andentities outside of your business (suppliers,customers, etc)

Activity diagram


85/93

Activity diagram

Activity diagrams can also show object flows, inthis case to visualize how business entities aredelivered throughout the workflow

Class diagram


86/93

Class diagram

A class diagram showing relationships amongbusiness entities in the business model

Collaboration diagram


87/93

Collaboration diagram

A collaboration diagram documents how businessworkers and business objects interact to perform abusiness use-case realization

Summary


88/93

Summary

C Question


89/93

C Question

A business ..visually represents theinteraction between the primary services yourbusiness provides and those to whom thoseservices are provided

B Question


90/93

B Question

What is the difference between Binary / Unary /Association / Composition?

A(C) Question


91/93

A(C) Question

In Activity diagram, the vertical fields are calledwhich are used to show which business

worker participates in the realization of the workflow

Next week presentation


92/93

Next week presentation

1. SDLC2. Problem, risk in requirement definition

3. Method to get customers requirement effectively

4. Process & requirement specification


93/93

THANKS FOR YOURATTENTION

system analysis, design & implementation 2

Documents