Documenting Solutions

33
1 Documenting Solutions Todd Bacastow Penn State University Geog 468 GIS Analysis & Design

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 Presentation

Transcript of Documenting Solutions

Page 1: Documenting Solutions

1

Documenting Solutions

Todd BacastowPenn State University

Geog 468GIS Analysis & Design

Page 2: Documenting Solutions

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

Page 3: Documenting Solutions

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.

Page 4: Documenting Solutions

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

Page 5: Documenting Solutions

5

UML Diagrams1. Use Case Diagrams2. Class Diagrams3. Collaboration Diagrams4. Sequence Diagrams5. Package Diagrams6. Component Diagrams 7. Deployment Diagrams8. Activity Diagrams 9. State Diagrams

Page 6: Documenting Solutions

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.

Page 7: Documenting Solutions

7

Use Case Diagram

Telephone Customer

In-StoreCustomer

Clerk

Identify Movie

Open Account

Return Movie

Customer

ReviewAccount Status

Actor

Use Case

Page 8: Documenting Solutions

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

Page 9: Documenting Solutions

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.

Page 10: Documenting Solutions

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

Page 11: Documenting Solutions

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.

Page 12: Documenting Solutions

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()

Page 13: Documenting Solutions

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

Page 14: Documenting Solutions

14

Collaboration Diagram

• Collaboration diagrams describe interactions and links

• Focus on exchange of messages between objects

• Appears during Analysis phase• Enhanced during Design phase

Page 15: Documenting Solutions

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()

Page 16: Documenting Solutions

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

Page 17: Documenting Solutions

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

Page 18: Documenting Solutions

18

Package Diagram

Clerk User Interface

«facade»BusinessSystemClient

(to businesssystem )Custom er Data

Renta l Screen

ClassPackage

Page 19: Documenting Solutions

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

Page 20: Documenting Solutions

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

Page 21: Documenting Solutions

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

Page 22: Documenting Solutions

22

Identify Movie

PlaceOrder

Place Order

FillOrder

Pay

DeliverMovie

PickupMovie

Customer Manager Walking Clerk

Fork Point

Join Point

CollectMoney

Swimlanes and Fork/Join Points

Page 23: Documenting Solutions

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

Page 24: Documenting Solutions

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

Page 25: Documenting Solutions

25

A step back in time:Entity Relationship Diagrams

(Where UML began)

Page 26: Documenting Solutions

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.

Page 27: Documenting Solutions

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.

Page 28: Documenting Solutions

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

Page 29: Documenting Solutions

29

Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.

Page 30: Documenting Solutions

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.

Page 31: Documenting Solutions

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

Page 32: Documenting Solutions

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.

Page 33: Documenting Solutions

33