1. Diagram Notations

2. Did you plan to build the Enterprise all on your own????
Diagrams are often useful when…
You need to communicate, visualize, or analyze something
And that something has some sort of structure

3. Recall: Typical parts of requirements documentation
Functional requirements
Unstructured text
Use cases
Non-functional requirements
Fit criteria
Diagrams
Class diagrams and entity-relationship diagrams
Dataflow, sequence, and state diagrams

4. Use case diagram: shows activities supported by the system
UC#1: Report repression
UC#2: Clarify tweet
Repressed citizen
UC#3: View reports
UC#3a: View on map
UC#3b: View as RSS feed
Concerned public

5. Notes on use case diagrams
Stick man for user
Ovals for use cases
Simple arrows when a UC “calls” or initiates another
Open arrowheads for specialization (“is-a”)
Similar to the role that subclassing plays in OO
Italicize “abstract” use cases

6. UML class diagram: shows entities, attributes, relationships
Clarification tweet
Report
When: date/time
Text: string
User
Twitter username
Repression report
Source: tweet
Location: geocode
When: date/time
Details: string * *
0..1 1 * *
Repression tweet
User
When: date/time
Text: string 1
Repression view
Reports *
Google map view
JavaScript
RSS View
XML text
System boundary

7. Notes on UML class diagrams
One box per kind of entity, listing attributes
Italicize abstract entities, attributes
SOME MIGHT BE OUTSIDE THE SYSTEM
Three types of lines representing relationships
Lines without arrowheads show association
Lines with triangle arrowheads for specialization
“a is a b”

8. Entity-relationship diagram: shows entities, attributes, relationships
Clarification tweet
report
when (datetime)
text (string)
0..1
User
Twitter username
Repression report
source (tweet)
location (geocode)
when (datetime)
details (string) p 1
yields s
asks about
writes
shows n 1 q
Repression tweet
user
when (datetime)
text (string)
Repression view
reports
System boundary
Google map view
JavaScript
RSS View
XML text

9. Notes on entity-relationship diagrams (ERDs)
One box per kind of entity
List attributes on branches
Lines with a diamond show relationships
Diamond label indicates role of relationship
Numbers or variables on lines show cardinality

10. Dataflow diagram: shows flow of information
Tweet
Repression info
Report
Twitter DB
Reporter
Tweet
Clarification message
Send clar req
Clarification message
Repression info
Inter-pret
Clarify
Repression info
Location
Viewing user
Geocoder
Map
RSS feed
Geocode
System boundary
Report
RSS View
Reports
Reports DB
Reports
Map View

11. Notes on dataflow diagrams
Each oval is a “function”.
Each inward arrow is a parameter (labeled)
Each outward arrow is an output (labeled)
Each rectangle is an actor
A person, place, or thing that can do stuff and/or initiate events
Each “half-rectangle” is a data store
Often clearer if you do a separate dataflow diagram for each use case

12. Message sequence diagram: shows flow of control
User
Twitter
System
Database
Geocoder
[geocode != null]
Tweet event
Read tweets
Geocode
Create report [if geocode != null]
Request to clarify [if geocode == null]
Deliver request

13. Notes on message sequence diagrams
One box per entity involved
E.g.: if you have two users interacting with each other, then you would have two boxes
SOME ENTITIES MIGHT BE OUTSIDE THE SYSTEM
Each box has a dashed line, showing its “lifetime”, which can end if an object is destroyed
Arrows show messages
Also, draw an arrow back if there’s a return value
Conditionals are written with brackets [ ]
Loops can be enclosed in a shaded box

14. State chart: shows change over time
Report status
Raw (just text)
Geocoded (geocode != null)
record
geocoding fails & user retweets
In database (geocode == null)
geocoding succeeds

15. Notes on state charts One box per state
Arrows show a possible state transition
Annotated to indicate under what conditions the transition occurs
Filled circle shows where you “start”
Nested filled circle shows where you “stop”

16. Putting it together: a typical requirements document
Requirements definition
Unstructured text: functional & non-functional reqs
Use case descriptions
Class diagrams or ERDs showing external entities
Requirements specification
Dataflow diagram
Message sequence diagrams or state charts

17. An example system to support drug and alcohol counseling

18. Requirements definition, functional reqs, unstructured text
Before each counseling visit, each counselee takes a survey.
After each survey, the system prints a report showing the counselee’s progress.
Administrative assistants can add counselees and their counselors to the system.
Requirements definition: written from external viewpoint; system is like a “black box”

19. Requirements definition, non-functional reqs, with fit criteria
The system will print progress reports within 2 minutes of a survey’s completion.
Each survey will be short enough for an average user to complete within 10 minutes.
Progress reports will each be 2 pages or less.
Users can take a survey using a Windows machine that has a Pentium II 550 MHz CPU, with 0.5 GB of RAM.
Requirements definition: written from external viewpoint; system is like a “black box”

20. UC#1: Survey and report Actor: Counselee
Precondition: Counselee registered in system
Postconditions:
Counselee progress data is recorded in system
Report is printed for use by counselor
Flow of events:
Counselee logs in (lastname + PIN)
System collects survey data from counselee
System prints report

21. Identify the noun phrases Nouns can inspire entities and attributes
UC#1: Survey and report
Nouns can inspire entities and attributes
Actor: Counselee
Precondition: Counselee registered in system
Postconditions:
Counselee progress data is recorded in system
Report is printed for use by counselor
Flow of events:
Counselee logs in (lastname + PIN)
System collects survey data from counselee
System prints report

22. Class diagram of entities
First, we identify some entities
Report
Counselor
Survey
Counselee
System boundary

23. Class diagram of entities
User
lastname: String
pin: Integer
Report
Counselor
Survey
Counselee
System boundary
These two are both users of the system

24. Class diagram of entities
We can infer some more attributes
User
lastname: String
pin: Integer
Report
Counselor
Survey
questions: String [1..*]
answers: Integer [1..*]
Counselee
System boundary

25. Class diagram of entities
Some “attributes” are modeled as relationships
User
lastname: String
pin: Integer
patientreport
Report
Counselor
counselor
datasource
Survey
questions: String [1..*]
answers: Integer [1..*]
patient
respondent
Counselee
System boundary

26. Class diagram of entities
Don’t forget to specify multiplicities
User
lastname: String
pin: Integer
patientreport
Report * *
Counselor 1
counselor 1
datasource *
Survey
questions: String [1..*]
answers: Integer [1..*]
patient *
respondent
Counselee * 1
System boundary

27. Class diagram of entities
Associations can also be named
User
lastname: String
pin: Integer
patientreport
Report
Reads * *
Counselor 1
counselor 1
Reports
Counsels
datasource *
CollectedFrom
Survey
questions: String [1..*]
answers: Integer [1..*]
patient *
respondent
Counselee * 1
System boundary

28. Requirements specification, functional reqs, unstructured text
When survey input completes, survey data will be stored in the database, and a report will be output to the printer.
The system will provide screens for adding, editing, and deactivating counselee and counselor records; at conclusion of input to these screens, records will be inserted, updated, or deleted from a database.
Requirements specification: written from system’s viewpoint, involving internal details of system

29. Requirements specification, non-functional reqs, with fit criteria
The system will record completed surveys in the database within 30 seconds; reports will be sent to the printer within 30 seconds and emerge within 60 seconds.
95% of the code will be platform-independent (Java or platform-independent JavaScript).
Requirements specification: written from system’s viewpoint, involving internal details of system

30. Identifying the verbs can also be useful
UC#1: Survey and report
Actor: Counselee
Precondition: Counselee registered in system
Postconditions:
Counselee progress data is recorded in system
Report is printed for use by counselor
Flow of events:
Counselee logs in (lastname + PIN)
System collects survey data from counselee
System prints report
OK, “use” is not technically a verb in this case.

31. Dataflow diagram (note: only shows UC#1)
Counselee
Counselor

32. Dataflow diagram (note: only shows UC#1)
Authenticate
Last name & PIN
Counselee
User ID
Counselor

33. Dataflow diagram (note: only shows UC#1)
Authenticate
Last name & PIN
Counselee
User ID
Survey DB
Health Information
Survey answers
Survey
Counselor

34. Dataflow diagram (note: only shows UC#1)
Authenticate
Last name & PIN
Counselee
User ID
Survey DB
Health Information
Survey answers
Survey
All this patient’s answers (ever)
Create report
Postscript
Printer
Counselor

35. Dataflow diagram (note: only shows UC#1)
Authenticate
Last name & PIN
Counselee
User ID
Survey DB
Health Information
Survey answers
Survey
All this patient’s answers (ever)
Pick up
Create report
Printout
Postscript
Printer
Printout
Counselor

36. Message sequence diagram UC#1
: Counselee
: Server
: Database
: Printer

37. Message sequence diagram UC#1
: Counselee
: Server
: Database
: Printer
Present question
Answer question

38. Message sequence diagram UC#1
: Counselee
: Server
: Database
: Printer
[survey complete]
loop
Present question
Answer question

39. Message sequence diagram UC#1
: Counselee
: Server
: Database
: Printer
[survey complete]
loop
Present question
Answer question
Record answers

40. Message sequence diagram UC#1
: Counselee
: Server
: Database
: Printer
[survey complete]
loop
Present question
Answer question
Record answers
Get report data
data
Send report to printer

41. A few general comments These are just the basic diagrams.
Sufficient for our homework, exams, and probably 90% of what you’ll see after graduation
Fancier versions of these diagrams do exist
It’s OK to draw diagrams by hand
As long as you respect the notation
And, at least for homework, scan it into a PDF

42. What’s next for you? Today: Meet with your client! Finish your HW2:
Due Tuesday, Sept. 20 before class
me or Danielle if you have questions
Every team member should be contributing

43. Copyright (c) Christopher Scaffidi 2009 All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Oregon State University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Modified by Scott D. Fleming 2011.