documenting solutions
DESCRIPTION
Documenting Solutions. Todd Bacastow Penn State University Geog 468 GIS Analysis & Design. Documenting (system) solutions. Models – used to organize and document a system’s processes. Flow of data through processes Business logic Business policies Business procedures. - PowerPoint PPT PresentationTRANSCRIPT
1
Documenting Solutions
Todd BacastowPenn State University
Geog 468GIS Analysis & Design
2
Documenting (system) solutions
Models – used to organize and document a system’s processes.
– Flow of data through processes– Business logic– Business policies– Business procedures
3
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.
4
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
5
UML Diagrams1. Use Case Diagrams2. Class Diagrams3. Collaboration Diagrams4. Sequence Diagrams5. Package Diagrams6. Component Diagrams 7. Deployment Diagrams8. Activity Diagrams 9. State Diagrams
6
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.
7
Use Case Diagram
Telephone Customer
In-StoreCustomer
Clerk
Identify Movie
Open Account
Return Movie
Customer
ReviewAccount Status
Actor
Use Case
8
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
• Brief description• Precondition• Flow of events
– Main flow– Subflows– Alternate flows
• Postcondition• Special Requirements• Enclosures
– Diagrams– Pictures of the UI
9
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.
10
UML Class Diagram
DVD Movie VHS Movie Video Game
Rental Item{abstract}
Rental Invoice
1..*1
Customer
Checkout Screen
0..1
1
Simple
Association
Class
Abstract
Class
Simple
Aggregation
Generalization
Composition
(Dependency)
Multiplicity
11
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.
12
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()
13
Class and Object Diagrams
0..1
0..n
Customer Rental Item
Rents+name:string
+id:integer
+released:date
+id:integer
Joe: Customer Casablanca: Movie
+name:Joe Smith
+id:1667
+released:1942
+id:22340
Class Diagram
Object Diagram
Class Name
Object Name
Attributes
Association Name
14
Collaboration Diagram
• Collaboration diagrams describe interactions and links
• Focus on exchange of messages between objects
• Appears during Analysis phase• Enhanced during Design phase
15
Collaboration Diagram
:Check-out Manager
:Customer
:Inventory
1: enter_customer()
3: enter_movies()
5: add(customer, movies)
7: print invoice()2: IsValidCust(CustId)
4:GetMovieByBarcode()
:Clerk
Object
Message
:Rented Items
8: generateRentalTotal()
16
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
17
Sequence Diagram
1: find customer()2: search (string)
4: search (string)
6: add(Cust, item)
3: enter movie()
5: rent (movie)
7: printInvoice() 8: generateRentalTotal()
Object
Lifeline
ActivationMessage
:CheckoutMgr :InventoryCust:Customer :RentedItems:Employee
18
Package Diagram
Clerk User Interface
«facade»BusinessSystemClient
(to businesssystem )Custom er Data
Renta l Screen
ClassPackage
19
Component Diagram
«applica tion»V ideo
W orksta tion(vsta tion .exe)
« lib rary»D B S erverIn terface
(dbsvr.d ll)
Supplied byM icrosoft
«lib rary»A pplica tionFram ework(appfr.d ll)
Component
Interface
Dependency
Note
20
C heck O ut Term ina l:C lerk C lien t
P hone C lerk Term ina l:C lerk C lien t
:S tore S erver
S erverD B
S toreS erver
A pp«TC P /IP »
«TC P /IP »
Node
Communication
Association
Deployment Diagram
21
Identify Caller
Create Account
Obtain Name& Address
Open Account?Current
Customer? [no] [no]
[yes][yes]
Action State
Start State
Decision
End State
Activity Diagram
22
Identify Movie
PlaceOrder
Place Order
FillOrder
Pay
DeliverMovie
PickupMovie
Customer Manager Walking Clerk
Fork Point
Join Point
CollectMoney
Swimlanes and Fork/Join Points
23
State Diagram
Validate
do/checkaccount
custom er appears
Check-Out
do/check-outvideo
[account valid ]/get firs t video
[m ore videos]/get next video
Check-OutComplete
[no m ore videos]
[account notvalid ]State
Transition
Activity
Guard
Action
Event
24
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
25
A step back in time:Entity Relationship Diagrams
(Where UML began)
26
Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data.
27
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.
28
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
29
Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.
30
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.
31
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
32
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.
33