Documenting Solutions
Todd Bacastow
Penn State University
Geog 468
GIS Analysis & Design
1
Documenting (system) solutions
Models – used to organize and document a system’s
processes.
–
–
–
–
Flow of data through processes
Business logic
Business policies
Business procedures
2
Why document using models?
• Models remove biases that are the result of the way the
system is currently implemented, or the way that any one
person thinks the system might be implemented.
• Models reduce the risk of missing business requirements
because we are too preoccupied with technical results.
• Models allow us to communicate with end-users in
nontechnical or less technical languages.
3
What is the UML?
•
•
•
•
Unified Modeling Language
It is a modeling language, not a development method
In 1996, work on the UML was begun by Rational
Supports Object Oriented Analysis and Design (OOA&D)
– is a methodology for system design and data modeling
– consisting of assessment, decomposition, conceptualization,
and physical modeling techniques
• Support the use of Computer-aided software
engineering (CASE) tools
4
UML Diagrams
1.
2.
3.
4.
5.
6.
7.
8.
9.
Use Case Diagrams
Class Diagrams
Collaboration Diagrams
Sequence Diagrams
Package Diagrams
Component Diagrams
Deployment Diagrams
Activity Diagrams
State Diagrams
5
Use Cases
• Describe interactions between users
and computer systems (both called
actors) .
• Capture user-visible functions.
• Achieve discrete measurable goals.
• Are typically used during Analysis and
Design.
6
Use Case Diagram
Use Case
Actor
Identify Movie
Customer
Open Account
Clerk
Return Movie
In-Store
Customer
Telephone
Customer
Review
Account Status
7
Use Case Report
• The Use Case Report
provides
documentation for
the Use Case.
• A Use Case is not
complete without
the report.
• The elements of the
Use Case Report are
shown on the right.
• Brief description
• Precondition
• Flow of events
– Main flow
– Subflows
– Alternate flows
• Postcondition
• Special Requirements
• Enclosures
– Diagrams
– Pictures of the UI
8
Class Diagrams
• Called the most fundamental UML Diagram.
• Describe the classes in the system, and the
static relationships between classes.
• Class diagrams are used during Analysis, Design
and Development.
9
UML Class Diagram
Multiplicity
Customer
Class
Simple
1
Aggregation
Rental Invoice
Abstract
Class
Rental Item
{abstract}
1..*
1
0..1
Composition
Simple
(Dependency)
Generalization
Association
Checkout Screen
DVD Movie
VHS Movie
Video Game
10
Parts of a Class
• Classes can have four
parts
–
–
–
–
Name
Attributes
Operations
Responsibilities
• Classes can show
visibility and types.
• All parts but the Name
are optional.
MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()
Responsibilities
-- can optionally be described here.
11
Object Diagrams
• An Object is an instance of a
class.
• Object names are underlined.
• Object diagrams are similar to
class diagrams. Many of the
same notations are used.
• Object diagrams capture
instances of classes, and allow
the dynamic relationships to be
shown.
ThisOne : MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()
12
Class and Object Diagrams
Class Name
Association Name
Customer
Rental Item
Rents
+id:integer
+name:string
0..1
0..n +id:integer
+released:date
Class Diagram
Attributes
Object Name
Joe: Customer
Casablanca: Movie
+id:1667
+id:22340
+name:Joe Smith
+released:1942
Object Diagram
13
Collaboration Diagram
• Collaboration diagrams describe
interactions and links
• Focus on exchange of messages
between objects
• Appears during Analysis phase
• Enhanced during Design phase
14
Collaboration Diagram
:Rented Items
1: enter_customer()
Object
5: add(customer, movies)
8: generateRentalTotal()
3: enter_movies()
2: IsValidCust(CustId)
7: print invoice()
:Check-out
Manager
:Customer
:Clerk
4:GetMovieByBarcode()
:Inventory
Message
15
Sequence Diagram
• Can be “morphed” from Collaboration Diagrams.
• Describe interactions between objects arranged in
time sequence
• Focus on objects and classes involved in the scenario
and the sequence of messages exchanged
• Associated with use cases
• Used heavily during Analysis phase and are
enhanced and refined during Design phase
16
Sequence Diagram
:CheckoutMgr Cust:Customer
:
:Inventory
:RentedItems
Employee
1: find customer()
2: search (string)
3: enter movie()
4: search (string)
Object
Activation
Message
5: rent (movie)
6: add(Cust, item)
Lifeline
7: printInvoice()
8: generateRentalTotal()
17
Package Diagram
Clerk User Interface
Customer Data
«facade»
Business
System
Client
Class
(to business
system)
Package
Rental Screen
18
Component Diagram
Component
«library»
DB Server
Interface
(dbsvr.dll)
«library»
Application
Framework
(appfr.dll)
Interface
Dependency
«application»
Video
Workstation
(vstation.exe)
Note
Supplied by
Microsoft
19
Deployment Diagram
Node
Communication
Association
Phone Clerk Terminal
:Clerk Client
Check Out Terminal
:Clerk Client
:Store Server
Server
DB
«TCP/IP»
«TCP/IP»
Store
Server
App
20
Activity Diagram
Start State
Action State
Identify
Caller
Obtain Name
& Address
Current
Customer?
Decision
Open
Account?
[no]
[no]
[yes]
[yes]
End State
Create
Account
21
Swimlanes and Fork/Join Points
Customer
Identify
Movie
Manager
Walking Clerk
Fork Point
Place
Order
Place
Order
Pay
Collect
Money
Pickup
Movie
Deliver
Movie
Fill
Order
Join Point
22
State Diagram
Guard
Event
Transition
[more videos]
/get next video
customer appears
Validate
do/check
account
[account valid]
/get first video
Activity
State
[account not
valid]
Check-Out
do/check-out
video
Action
[no more videos]
Check-Out
Complete
23
Views
• The User View
– Use Case Diagram(s)
• Structural View
– Class Diagram
• The Behavior View
– The Sequence Diagram
– Collaboration Diagram
– Activity Diagram
– State Diagram
• The Implementation View
– Component Diagram
– Deployment Diagram
24
A step back in time:
Entity Relationship Diagrams
(Where UML began)
25
Entity relationship diagram (ERD) – a data model
utilizing several notations to depict data in terms of the
entities and relationships described by that data.
26
Entity – a class of persons, places, objects, events, or
concepts about which we need to capture and store
data.
– Named by a singular noun

Persons: agency, contractor, customer,
department, division, employee,
instructor, student, supplier.

Places: sales region, building, room,
branch office, campus.

Objects: book, machine, part, product, raw material, software
license, software package, tool, vehicle model, vehicle.

Events: application, award, cancellation, class, flight, invoice,
order, registration, renewal, requisition, reservation, sale, trip.

Concepts: account, block of time, bond, course, fund,
qualification, stock.
27
Attribute – a descriptive property or
characteristic of an entity. Synonyms include
element, property, and field.
– Just as a physical student can have attributes, such
as hair color, height, etc., data entity has data
attributes
28
Key – an attribute, or a group of attributes, that
assumes a unique value for each entity instance. It
is sometimes called an identifier.
29
Relationship – a natural business association that exists
between one or more entities.
The relationship may represent an event that links the entities
or merely a logical affinity that exists between the entities.
30
Cardinality – the minimum and maximum number of
occurrences of one entity that may be related to a single
occurrence of the other entity.
Because all relationships are bidirectional, cardinality must
be defined in both directions for every relationship.
bidirectional
31
Degree – the number of entities that participate in the
relationship.
A relationship between two entities is called a binary
relationship.
A relationship between three entities is called a 3-ary or
ternary relationship.
A relationship between different instances of the same entity
is called a recursive relationship.
32
33