lecture for diagramming

8/12/2019 Lecture for Diagramming

1/67


2/67

2

Chapter 3

Diagramming andSoftware Engineering


3/67


4/67

4

Object-Oriented Modeling

UML Package

Problem Domain Solution Domain Application Domain Model System Model

Aircraft TrafficController

FlightPlan Airport

MapDisplay

FlightPlanDatabase

SummaryDisplay

TrafficControl

TrafficControl


5/67

5

Communicating with diagram

Why diagram? A diagram is worth a thousand words Unlike natural languages, diagram cant lie Needs a thorough understanding of the problem in

order to express it graphically E.g. Forth Railway Bridge in Scotland


6/67

6

The role of diagrams in softwaredevelopment

To be effective diagramsmust follow certainrules and must be clear

A diagram is notsupposed to act asintellectual puzzle.

UML fits in all of theseroles.

Why usediagrams

As a DESIGNtool

As aMAINTENANCE

tool

As aDOCUMENTATION

tool

As a

COMMUNICATIONmedium


7/67

7

Why model software?Software is already an abstraction: why model software?

Software is getting larger, not smaller NT 5.0 ~ 40 million lines of code

A single programmer cannot manage this amount of code in its entirety. Code is often not directly understandable by developers who did not

participate in the development We need simpler representations for complex systems

Modeling is a mean for dealing with complexity


8/67

8

OOAD

In this course, we will focus on the object oriented analysisand design (OOAD) based on the Unified Modeling Language(UML). At the same time, we will demonstrate codegeneration to a C++ and Java programming language.

What is the OOAD ?The system is viewed as a collection of interacting objects.Objects are instances of class and communicate by exchangingmethods calls

Why OOAD ?Easily map to real world concepts (i.e. objects/classes)Most new generations language are object oriented .e.g. C++, Java, C#.Hence, can manipulate the o-o language features (i.e. inheritance,polymorphism etc), for example, to encourage reuse


9/67

9

What is UML ? UML is a visual language for visualizing, specifying,

constructing, and documenting of software system Widely used in the industry. E.g. backed by leading software

producers including Hewlett Packard, IBM, Microsoft, Oracle,Digital etc. Supports the entire software development lifecycleand can be used in diverse application areas

Based on experience and needs of the user community (i.e.the unification of OMT technique, Use case technique, Boochtechnique)

Support by many tools, and the implementation can beprogramming language independent


10/67

10

UML CASE tools

Computer Aided Software Engineering (CASE)is a software to support softwaredevelopment and its evolution

Powerful toolset that can integrate all thetools in a single working environment

Facilitate automation, guidance and enforcement of

software engineering practicesIncrease the productivity and quality whilst facilitatesmaintenance


11/67

11

UML case tools contd. Many public domain/open source/ and commercial tools Ranging from: simply UML drawing tools to supporting round

trip engineering. May supports C++, Java, and C# Common ones:

Rational Rose Rhapsody Argo/UML (free) Borland Together

For more reference to UML case tools, visithttp://plg.uwaterloo.ca/~migod/uml.html
http://plg.uwaterloo.ca/~migod/uml.htmlhttp://plg.uwaterloo.ca/~migod/uml.html


12/67

12

House

Architect

produce design

Builder

refer to the design

build

UML - Architect vs Builder Analogy


13/67

13

Software Engineer

produce design using

UML

Programmer

refer to the design

UML - Architect vs Builder Analogy

round trip codegeneration usingUML case tools

We will learn about UMLthoroughout this course !


14/67

14

UML Diagrams

Nine types of diagrams: Use Case Diagram Sequence Diagram Class Diagram Object Diagram Collaboration Diagram State Chart Diagram Component Diagram Activity Diagram Deployment Diagram


15/67

15

UML Concepts

The diagrams describe either the structural or the behavioral of the system Use cases and actors display the boundary of a system and its major

functions Sequence and collaboration diagrams illustrate specific case realizations Object diagrams depict object interactions Class diagrams represent the static structure of a system State transition and activity diagrams represent the dynamic behavior of

objects Component and deployment diagram reveal the physical

implementation architecture

We will go over each diagram as we go along !


16/67

16

UML and This Course

You can model 80% of most problems byusing about 20% UML

In this course, we teach you those 20%


17/67

17

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, andAssociations.

Sequence diagrams Describe the dynamic behavior between actors and the system and

between objects of the system. Statechart diagrams

Describe the dynamic behavior of an individual object as a finite statemachine.

Activity diagrams Model the dynamic behavior of a system, in particular the workflow, i.e. a

flowchart.


18/67

18

UML First Pass: Use Case Diagrams

WatchUser

WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

Package SimpleWatch

Use case diagrams represent the functionality of the systemfrom users point of view


19/67

19

UML First Pass: Class Diagrams

Batteryload()

1

2

Timenow()

PushButtonstate

push()release()

1

1

1

1

1

2

blinkIdx blinkSeconds() blinkMinutes() blinkHours()

stopBlinking()referesh()

LCDDisplay

SimpleWatch

Class

AssociationMultiplicity

AttributesOperations

Class diagrams represent the structure of the system


20/67

20

UML First Pass: Sequence DiagramObject

Message Activation

Sequence diagrams represent the behavior as interactions

blinkHours()

blinkMinutes()

incrementMinutes()

refresh()

commitNewTime()

stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser :Time

:LCDDisplay

:SimpleWatch

UML Fi P S h


21/67

21

button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed Increment Minutes

Increment Hours

Blink Hours

Blink Seconds

Blink Minutes

Increment Seconds

Stop Blinking

UML First Pass: StatechartDiagrams

StateInitial state

Final state

Transition

Event


22/67


23/67

23

UML Second Pass: Use CaseDiagrams

Used during requirements elicitation torepresent external behavior

Actors represent roles, that is, a type of user

of the system Use cases represent a sequence of

interaction for a type of functionality The use case model is the set of all use

cases. It is a complete description of the

functionality of the system and itsenvironment

Passenger

PurchaseTicket


24/67

24

Actors An actor models an external entity which

communicates 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


25/67

25

Use CaseA use case represents a class of functionality

provided by the system as an event flow.

A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements

PurchaseTicket


26/67

26

Use Case Example

Name: Purchase ticket

Participating actor: Passenger

Entry condition: Passenger standing in front of

ticket distributor. Passenger has sufficient

money to purchase ticket.

Exit condition: Passenger has ticket.

Event flow: 1. Passenger selects the number

of zones to be traveled.2. Distributor displays the amount

due.3. Passenger inserts money, of atleast the amount due.

4. Distributor returns change.5. Distributor issues ticket.

Anything missing ?

Exceptional cases!


27/67

27

The Relationship relationships

represent exceptional or seldominvoked cases.

The exceptional event flows arefactored out of the main eventflow for clarity.

Use cases representingexceptional flows can extend

more than one use case. The direction of a

relationship is to the extendeduse case

Passenger

PurchaseTicket

TimeOut

NoChange

OutOfOrder

Cancel


28/67

28

Passenger

PurchaseSingleTicket

PurchaseMultiCard

NoChange

Cancel

CollectMoney

The Relationship An relationship

represents behavior that isfactored out of the use case.

An representsbehavior that is factored out for

reuse, not because it is anexception.

The direction of a relationship isto the using use case (unlike relationships).


29/67

29

Class Diagrams

Class diagrams represent the structure of the system. Class diagrams are used

during requirements analysis to model problem domain concepts during system design to model subsystems and interfaces during object design to model classes.

Enumeration getZones()Price getPrice(Zone)

TariffSchedule

* *

Tripzone:Zone

price:Price


30/67

30

Classes

A class represent 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()Price getPrice( Zone )

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule


31/67

31

Instances

An instance represents 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}}

tariff_1974:TarifSchedule


32/67

32

Actor vs. Instances What is the difference between an actor and a class and an instance? Actor:

An entity outside the system to be modeled, interacting with thesystem (Pilot)

Class: An abstraction modeling an entity in the problem domain, inside the

system to be modeled (Cockpit) Object:

A specific instance of a class (Joe, the inspector).


33/67

33

Associations

Associations denote relationships between classes. The multiplicity of an association end denotes how many objects the

source object can legitimately reference.

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* pricezone

TripLeg

*


34/67

34

1-to-1 and 1-to-Many Associations

1-to-1 association

1-to-many association

*

draw()

Polygon

x:Integery:Integer

Point1

Has-capital

name:StringCountry

name:StringCity11


35/67

35

Aggregation An aggregation is a special case of association denoting a consists of

hierarchy. The aggregate is the parent class, the components are the children class.

1

Exhaust System

Muffler Tailpipe0..2


36/67

36

Composition

A solid diamond denote composition , a strongform of aggregation where componentscannot exist without the aggregate.

3

TicketMachine

ZoneButton


37/67

37

Generalization

Generalization relationships denote inheritance between classes. The children classes inherit the attributes and operations of the parent

class. Generalization simplifies the model by eliminating redundancy.

Button

ZoneButtonCancelButton


38/67

38

From Problem Statement to Code Problem Statement

A stock exchange lists many companies. Each company isidentified by a ticker symbol

Class Diagram

Java Code public class StockExchange {

public Vector m_Company = new Vector();};

public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector();

};

*StockExchange

tickerSymbol

Company*

lists


39/67

39

UML Sequence Diagrams

Used during requirements analysis To refine use case descriptions to find additional objects

(participating objects) Used during system design

to refine subsystem interfaces Classes are represented by columns Messages are represented by arrows Activations are represented by

narrow rectangles

Lifelines are represented by dashedlines

selectZone()

pickupChange()

pickUpTicket()

insertCoins()

Passenger TicketMachine


40/67

40

UML Sequence Diagrams: NestedMessages

The source of an arrow indicates theactivation which sent the message

An activation is as long as all nested

activations

selectZone()

Passenger ZoneButton

TarifSchedule

Display

lookupPrice(selection)

displayPrice(price)

price

Dataflowto be continued...


41/67

41

Sequence Diagram Observations

UML sequence diagram represent behavior interms of interactions.

Complement the class diagrams whichrepresent structure.

Useful to find participating objects. Time consuming to build but worth the

investment.


42/67

42

Activity Diagrams

An activity diagram shows flow control within a system

An activity diagram is a special case of a state chart diagram in which states are activities (functions) Two types of states:

Action state: Cannot be decomposed any further Happens instantaneously with respect to the level of abstraction used in the model

Activity state: Can be decomposed further The activity is modeled by another activity diagram

H a n d l eI n c i d e n t

D o c u m e n tI n c i d e n t

A r c h i v eI n c i d e n t


43/67

43

Activity Diagram: ModelingDecisions

O p e nI n c i d e n t

N o t i f y

P o l i c e C h i e f

N o t i f yF i r e C h i e f

A l l o c a t eR e s o u r c e

[ f i r e & h i g h P r i o r i t y ]

[ n o t f i r e & h i g h P r i o r i t y ]

[ l o w P r i o r i t y ]


44/67

44

Activity Diagrams: ModelingConcurrency

Synchronization of multiple activities Splitting the flow of control into multiple

threads

SynchronizationSplitting

Archive Incident

Open Incident

Document Incident

Allocate Resources

Coordinate Resources


45/67

45

Activity Diagrams: Swimlanes

Actions may be grouped into swimlanes todenote the object or subsystem thatimplements the actions.

Archive Incident

Dispatcher

FieldOfficer

Open Incident

Document Incident

Allocate Resources

Coordinate Resources


46/67

46

Component Diagram Show dependencies among components, including source

code components, binary code components, and executablecomponents

OrderOptions

OrderOptions

OrderDetail

OrderDetail


47/67

47

Deployment Diagram

Displays the configuration of run-time processing elementsand the software component processes, and objects that liveon them

ApplicationServer

OrderServerExe

Database

Server

ClientWorkstation #1

OrderClientExe

ClientWorkstation #2

OrderClientExe

Printer


48/67

48

Process vs Design Notation

Remember, UML is merely design notationand not a process per se.

Software development using UML (possible

route) Use case->sequence diagram -> collaboration diagram -

> class diagram - > object diagram. Use case->object diagram->class diagram -> sequence

diagram. .. etc.. and UML does not dictate any sequence ..


49/67

49

Possible UML Development Process

Use case

Flow of Events

prioritize

Sequence diagram Collaboration diagram

(optional)

Class diagramState chart(optional)

Deployment diagram(optional)

CODE

Activity diagram(optional)

Object diagram(optional)

Component diagram

SPECIFICATION

DESIGN

IMPLEMENTATION


50/67

50

Software Engineering

Activities A Review

f


51/67

51

Software engineeringactivities Review

Requirement analysis and specification Design Coding Testing Operation and maintenance

Here, the development model are irrelevant !


52/67

52

High Level View?Customers &Stakeholders

IndependentV&V Teams

Known FailureEmpirical Data

interact

interact

producesolicit

REQUIREMENTELICITATION

PHASE

SoftwareDesign

SoftwareImplementation

IMPLEMENTATIONPHASE

refer

SoftwareSpecification

Software Engineers &Programmers

refer

design

develop

TestCases

develop

Test case execution

SoftwareRelease

VALIDATIONPHASE

analyze for conformance

S O F T W A R E E N G I N E E R I N G P R O D U C T L I F E C Y C L E

RequirementEngineers


53/67

53

Requirement analysis and specification

Determine the requirements and feasibility ofthe solution

A clear understanding between the user and developer

Acceptability of possible tradeoffs based on theobjectives and constraints of the project

Project plan includes the schedule, budget, outputs atthe end of each phase


54/67

54

Specification

What the solution look likeWhat inputs the system is going to processWhat functions it will perform for each input

What are the corresponding outputWhether the specified system meets the userrequirements, conforms to the project plan or theproject plan needs to be altered


55/67

55

Design

How the solution will be implementedStructures the system into its logically and functionallycohesive parts or modules

Select the proper data structures and algorithms forthe implementation of the input and output data andthe system functionsIdentify the major subsystems/modules and how theyinterrelateIdentify the functionality of each module

Design test cases


56/67

56

Coding

Translating the solution into actual codesWrite the program as being described in the designThe coding phase is complete when all codes have

been written, compiled and documentedRereading test code inspection, walkthrough

Software test description how and when to test whatpart of the code


57/67


58/67

58

Operation and maintenance

Keeping the system operationalCorrective maintenanceAdaptive maintenance

Produce multiple versions of software product

In next section to come, we will see how UML supports all these

activities.


59/67

59

Topic 4

Requirements andDesign


60/67

60

The importance of requirement

I know you believe youunderstood what youthink I said, but I am notsure you realize thatwhat you heard is notwhat I meant

Th i t f i t


61/67

61

The importance of requirements contd.

Try to develop anythingwithout them

They may be a legal

contract They are the basis for

later testing Poor requirements are

the common reason forproject failure (see thenext slide)


62/67

62

The requirement traceability

Must be prepared to be able to trace down/up fromspecification to design and tests

Essential for maintenance and evolution.

Module

Req.Module 1 Module 2 Module k..

Req. 1

Req. 2

Req. y

X X

X

X

X

X

X

X

X

X


63/67

63

Requirement Specification

Often a two step processi. High level requirements document For

management level/marketing peopleii. Specification with all the details filled in For

client/developers

ORi. System level specification with all components For

management level/marketing peopleii. Detailed requirements for each components For

client/developers


64/67

64

Non functional requirements Often not set by the customers Define system properties and constraints e.g.

reliability, response time and storage requirements. Constraints are I/O device capability, system

representations, etc. Sometimes, non-functional requirements may be

more critical than functional requirements. Typically:

Reliability, Security, Availability, Maintainability, Portability,Performance


65/67

65

Who needs to be involved ?

Everyoneas the stakeholders here is why: Customers as they are the users Marketing people as they are probably promoting its development Documentation people as they use requirements to write

documentation Testers as they will test codes against the requirements Technical support as they will have to support the system Developers as they will have to design/write codes based on the

requirement Customer Training as they need to develop course training material if

needed And many more..


66/67

66

Common problems

Long meetings involving many people. Hence, a lot of conflicts (e.g.political etc) Different users have different requirements and priorities.System end-users and organisations who pay for the system have differentrequirementsNatural language problems vague !

The system should be easy to use by experienced controllers andshould be organised in such a way that user errors are minimised. The error rate should be quantified

Experienced controllers should be able to use all the systemfunctions after a total of two hours training. After this training, theaverage number of errors made by experienced users should notexceed two per day.

Hence, prototyping often required to clarify requirements


67/67

lecture for diagramming

Documents