Unified
Modeling Language (UML)
Ø Object:
·
Graphical,
object-oriented modeling language. Options:
o
Sketch
language to define system requirements – Blueprint language for system design
o
Implementation
language to automatically generate software
·
• ‘Open standard’ managed by Object Management
Group
o
Many
implementations of UML (Microsoft, IBM, Borland, …)
·
• Why is UML coming into wide use?
o
Speeds
up requirements process
o
Lessens information loss between requirements
and design processes, and between design and implementation
o
Clearer
than natural language
·
• Provides a level of precision, but avoids
details
o
Supports
iterative development (i.e., spiral model)
·
• Supports both high level requirements/design
in early spirals and detailed requirements/design later
o
Hope
that analysts can produce software without programmers
Ø Unified Modeling Language uses:
·
• Requirements:
o
Use cases, which are very structured scenarios
used to define system requirements
§
Good basic approach, but needs narrative to
support
o
Class diagrams
§
Show relationships and behavior of all objects
(things) in system
§
Derived from data models, which we cover in next
lecture
o
Component
diagrams to show high level view of system
·
• Design:
o
More
detailed use cases, class diagrams, component diagrams
o
Activity
and/or sequence diagrams, used to model workflows, to find related or duplicate
processes that can be generalized
o
State
diagrams for complex objects – Other diagram types, as needed
·
• Implementation:
o
Class,
state and other diagrams (vendor specific)
Ø Use cases
·
• Capture requirements of system as structured
scenarios
o
Use
case diagrams capture how use cases relate to each other
o
The
actual use cases are usually text
o
A note: Users are called ‘actors’
·
• Exercise:
o
Passenger
browses bus routes and selects one to get info – Passenger selects day of week,
time period and direction – Passenger selects origin and destination points
o
System
displays schedule and countdown clock to next bus
o
Passenger
opts for mobile phone notification of given bus at given stop
·
• What alternatives are there?
o
Passenger
selects origin, destination first – Passenger clicks on map
·
• What can go wrong with the chosen
alternative?
o
No service at requested time or stops; out of
town phone,…
Ø Use case example
Ø Use case exercise
·
• Add one of the exception cases:
o
No
service
o
Out
of town phone – Others…
·
• Create ‘included’ use cases for one diagram
case:
o
Break
down complex use cases into smaller one
o
(You
can use ‘extend’ if you want, but it’s illdefined)
Use case solution
Ø Component diagram
·
• Draw the components for the bus information
system example:
o
Web
server
o
Application
server (creates Web pages dynamically) – Database server (holds bus route
database)
o
Telecom
system interface from Web server – Telecom system
Ø
Component diagram example
Component diagram example
Ø Dynamic UML models
·
• While static models (use cases, class
diagram, component diagram) are done for the system as a whole, dynamic models
are done only for key components
·
• State diagram
o
Specifies
behavior of a single object
·
• Sequence diagram
o
Shows
details of one scenario and messages that flow between objects in that scenario
over time
o
Heavily
used in standards
·
• Activity diagram
o
Shows
flow of logic, data, messages
o
Often
less structured than other UML diagrams – Replaces flow charts
·
• Communication diagram
o
Shows
flow of messages as a graph – Used as variant of sequence diagram
·
• Others, as needed
Ø 
State diagram example
State diagram example
Ø State diagram exercise
·
• Model one other state:
o
Suspended
account (identity theft)
Ø 
State diagram solution
State diagram solution
Ø Sequence diagram example
Ø Sequence diagram exercise
·
• Add a discount calculation based on the
total order quantity, in addition to the customer discount
Ø Sequence diagram
solution
Ø Activity diagram
·
• Shows flow of messages, logic, actions
·
• This is at a much higher level of
abstraction than flow charts
o
Flow
charts show logic for single method (if statements, loops, etc.)
o
Activity
diagrams show flow among objects
Ø 
Activity diagram example
Activity diagram example
Ø Activity diagram exercise
·
• Add a ‘close order’ activity
Ø Activity diagram
solution
Ø UML Summary
·
• Use UML after writing scenarios and
narratives as an initial requirements document
o
Refine
them into use cases
·
• Prepare the initial data model (next
lecture)
o
Add
operations/methods to the entities, after understanding the data, to create a
class diagram
·
• Use UML component diagrams to give overview
of the system, in requirements
·
• Use UML state diagrams, sequence diagrams
and activity diagrams to specify objects and processes
o
Prepare
these selectively for complex or interesting objects
·
• UML is becoming a ‘universal’ language: new
staff coming to a project can read it, and this reduces the learning curve very
substantially
o
Developers
and analysts can both understand it readily
o
I
use UML even for analysis only projects (as well as writing requirements and
modeling data)
No comments:
Post a Comment