lecture for diagramming
Post on 03-Jun-2018
218 Views
Preview:
TRANSCRIPT
-
8/12/2019 Lecture for Diagramming
1/67
-
8/12/2019 Lecture for Diagramming
2/67
2
Chapter 3
Diagramming andSoftware Engineering
-
8/12/2019 Lecture for Diagramming
3/67
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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 -
8/12/2019 Lecture for Diagramming
12/67
12
House
Architect
produce design
Builder
refer to the design
build
UML - Architect vs Builder Analogy
-
8/12/2019 Lecture for Diagramming
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 !
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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 !
-
8/12/2019 Lecture for Diagramming
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%
-
8/12/2019 Lecture for Diagramming
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.
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
22/67
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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!
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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).
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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).
-
8/12/2019 Lecture for Diagramming
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
*
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
36/67
36
Composition
A solid diamond denote composition , a strongform of aggregation where componentscannot exist without the aggregate.
3
TicketMachine
ZoneButton
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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...
-
8/12/2019 Lecture for Diagramming
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.
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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 ]
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
46/67
46
Component Diagram Show dependencies among components, including source
code components, binary code components, and executablecomponents
OrderOptions
OrderOptions
OrderDetail
OrderDetail
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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 ..
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
50/67
50
Software Engineering
Activities A Review
f
-
8/12/2019 Lecture for Diagramming
51/67
51
Software engineeringactivities Review
Requirement analysis and specification Design Coding Testing Operation and maintenance
Here, the development model are irrelevant !
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
57/67
-
8/12/2019 Lecture for Diagramming
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.
-
8/12/2019 Lecture for Diagramming
59/67
59
Topic 4
Requirements andDesign
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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)
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
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..
-
8/12/2019 Lecture for Diagramming
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
-
8/12/2019 Lecture for Diagramming
67/67
top related