Diagram Notations

Slides:



Advertisements
Similar presentations
Architecture. Outline Example Decomposition Style Activity 1.
Advertisements

Use Case & Use Case Diagram
Schedule and Effort. Planning Big Project: Waterfall-ish Style 1.Figure out what the project entails Requirements, architecture, design 2.Figure out dependencies.
Paper Prototyping.
Object-Oriented Design
Object-Oriented Analysis and Design CHAPTERS 15: UML INTERACTION DIAGRAMS 1.
Systems Analysis and Design 8th Edition
Use-case Modeling.
Android programming club Thursdays 5-7pm Info… Ryley Herrington iOS programming club Info… Ben Lanegan or.
Systems Analysis and Design in a Changing World, Fourth Edition
Design Patterns in Java Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Schedule & effort.
Diagram Notations
Essentials of interaction diagrams Lecture Outline Collaborations Interaction on collaboration diagrams Sequence diagrams Messages from an object.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Requirements
Object-Oriented Design
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
SE-565 Software System Requirements More UML Diagrams.
Unified Modeling Language
Systems Analysis and Design in a Changing World, Tuesday, Feb 27
UML Collaboration Diagram. Recap System Sequence Diagrams (SSD) UML for SSD Examples.
Lecture 6 Unified Modeling Language (UML)
The Next Stage in Analysis: Systems Use Case Diagrams 1 SYS366.
程建群 博士(Dr. Jason Cheng) 年03月
Schedule & effort.
Diagram Notations
4 2009/10 Object Oriented Technology 1 Topic 4: The Object-Oriented Approach to Requirements Adopted from: Ch.7 The Object-Oriented Approach to Requirements.
Systems Analysis and Design in a Changing World, Fifth Edition
Systems Analysis and Design in a Changing World, 6th Edition
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
In-Class Interviewing Activity (Grocery example) You can conduct a semi-structured/unstructured interview: How: Use the process outlined here. Individually.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
Systems Analysis & Design 7 th Edition Chapter 5.
Systems Analysis and Design 8 th Edition Chapter 6 Object Modeling.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
UML Review of diagram types. 2 Unified Modeling Language The Unified Modeling Language™ (UML) was developed jointly by Grady Booch, Ivar Jacobson, and.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Use Cases, Part I Understanding the Business Dynamics  Understand the business workflow  Identify system support points the system 'use cases'
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour UML Sequence Diagram.
(c) Addison Wesley Copyright © 2000 by Addison Wesley Version 1.0
Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Object-Oriented Design
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
Systems Analysis and Design in a Changing World, Fourth Edition
Notations. Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements.
Object-Oriented Design. 1 Objects and concerns Objects have a concern, meaning they have a purpose Not concerned as in worried All code should have a.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design,
Requirements
Chapter 3: Introducing the UML
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
Use Case Diagrams. Introduction In the previous Lecture, you saw a brief review of the nine UML diagrams. Now that you have the clear, you'll start to.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
CHAPTER 6 OBJECT ANALYSIS.
E- Patient Medical History System
Systems Analysis and Design in a Changing World, Fourth Edition
Unified Modeling Language
The Next Stage in Analysis: Systems Use Case Diagrams
SAD ::: Spring 2018 Sabbir Muhammad Saleh
CIS 375 Bruce R. Maxim UM-Dearborn
Interaction diagrams Interaction diagrams are models that describe how groups of objects collaborate in some behavior. Typically, an interaction diagram.
Analysis models and design models
Using Use Case Diagrams
Diagram Notations
CIS 375 Bruce R. Maxim UM-Dearborn
Object Oriented System Design Class Diagrams
Presentation transcript:

Diagram Notations

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

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

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

Notes on use case diagrams Stick man for user Ovals for use cases – Italicize “abstract” use cases Simple arrows when a UC “calls” another Open arrowheads for specialization – Similar to the role that subclassing plays in OO

UML class diagram: shows entities, attributes, relationships User + Twitter username Repression report + source (tweet) + location (geocode) + when (datetime) + details (string) 1 * Repression view + reports * Google map view + JavaScript RSS View + XML text Repression tweet + user + when (datetime) + text (string) 1 * System boundary Clarification tweet + report + when (datetime) + text (string) *

Notes on UML class diagrams One box per kind of entity, listing attributes – Italicize abstract entities, attributes Lines without arrowheads show references – Similar to member variables in OO – Labeled with cardinality (multiplicity) Integers, ranges, or asterisk (for unlimited) Lines with open arrowheads for specialization Lines with regular arrowheads can be used to indicate dependencies – Usually omitted in requirements’ class diagrams

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

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

Dataflow diagram: shows flow of information Reporter Viewing user Report Twitter DB Send clar req Reports DB Inter- pret Clarify Geocoder RSS View Map View

Notes on dataflow diagrams Each oval is a “function” provided by system. – 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

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

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 – 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

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

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”

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 – Unstructured text: functional & non-functional reqs – Dataflow diagram – Message sequence diagrams or state charts

An example system to support drug and alcohol counseling

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”

Requirements definition, non-functional reqs, with fit criteria Each survey will be short enough for an average user to complete within 10 minutes. Progress reports will each be 2 pages or less. The system will print progress reports within 2 minutes of a survey’s completion. 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”

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

Class diagram of entities Counselor + reports Counselee + counselor + surveys Survey + questions (String []) + answers (int []) + counselee 1 * User + lastname (string) + PIN (int) 1 * Report + surveys + counselor * * 1 * System boundary

Requirements specification, functional reqs, unstructured text Survey data will be stored in the database at the end of the survey, and a report will be sent to the printer. The system will provide screens for adding, editing, and deactivating counselee and counselor records from a database. Requirements specification: written from system’s viewpoint, involving internal details of system

Requirements specification, non-functional reqs, with fit criteria 95% of the code will be platform-independent (Java or platform-independent JavaScript). 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. Requirements specification: written from system’s viewpoint, involving internal details of system

Dataflow diagram (note: only shows UC#1) Survey DB Survey Counselee Counselor Create report Printer Pick up Authent icate

Message sequence diagram UC#1 [survey complete] CounseleeServerDatabase Log in Printer Present question Answer question Record answers Get report data Send report to printer

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

What’s next for you? Finish your HW by Tuesday, before class – me if you have questions Every team member should be contributing – Remember: Tuesday is last day to fire a teammate Do your reading for Tuesday