Analysis Modeling CpSc 372: Software Engineering Foundations Jason O. Hallstrom jasonoh@cs.clemson.edu Authorship Disclaimer. These slides are intended to serve as teaching instruments for an undergraduate course in Software Engineering. While the slides were formatted by Dr. Hallstrom, the content is compiled from other sources, including the readings listed on the course website, Dr. Pressman s Software Engineering textbook, and various internet materials. In almost every case, the ideas belong to someone other than Dr. Hallstrom. Indeed, text is often quoted verbatim without an explicit citation (to improve the readability of the slides). The original authors retain all copyrights. If you are interested in citing any of the material in these slides, please contact Dr. Hallstrom for the original source(s). DO NOT CITE THIS PRESENTATION. THE CONTENT SHOULD NOT BE ATTRIBUTED TO DR. HALLSTROM. SEE DR. HALLSTROM IF YOU HAVE ANY QUESTIONS.
Activity Diagrams For complex use-cases, the process flow may be difficult to understand. Activity diagrams provide a graphical view of the interactions in a usecase. ot her f unct ions m ay also be select ed t hum bnail views valid passwor ds/ ID select major function select surveillance enter password and user ID invalid passwor ds/ ID prompt for reentry no input t r ies r em ain select a specif ic cam er a input t r ies r em ain select specific camera - thumbnails select camera icon Example: See Pressman Chapter 8, Section 8.5.2, pg. 192 view camera output in labelled window prompt for another view exit t his f unct ion see anot her cam er a
Swimlane Diagrams In some cases, it help to indicate which actors (or analysis classes) are responsible for which activities. h o m e o w n e r c a m e ra i n t e rf a c e enter password and user ID select m ajor function valid passwords/ ID in valid p asswo r d s/ ID A swimlane diagram serves this purpose. o t h er f u n ct io n s m ay also b e select ed select surveillance prom pt for reentry no input t r ies r em ain in p u t t r ies r em ain Example: t humbnail views select a specif ic camera See Pressman Chapter 8, Section 8.5.3, pg. 193 select specif ic cam era - thum bnails select cam era icon generate video output view cam era output in labelled window prom pt for another view exit t h is f u n ct io n see anot her cam er a
Use-Case Diagrams You ll probably have a lot of use-cases! Use case diagrams (UCD) provide a diagrammatic table of contents, and a high-level overview of the system. Diagrams Show: Actors Use-cases Relationships among them Customer Online Bookstore System Browse products Add products to shopping cart View shopping cart Checkout Example UCD Credit card transaction processor Billing system
A Roadmap We are going to examine some of the key tools used for creating an analysis model. General Use-cases Use-case diagrams Activity diagrams Swimlane diagrams Structured Analysis Data object diagrams ERD diagrams Data flow diagrams Process specifications These tools are not specific to either structured analysis or OO analysis. OO Analysis Class diagrams Packages CRC cards Sequence Diagrams
Data Flow Diagrams Structured Analysis: Models data elements Attributes Relationships Models processes that transform data modeled using modeled using Modeling Tools: Data object diagrams ERD diagrams Data flow diagram Process narrative A data flow diagram describes information flow among a set of processes and actors. A process narrative describes how a single process transforms input data to output data. 1 *
Data Objects A data object is a domain element that will be manipulated by the system. Characteristics: Plays a necessary role Characterized by attributes Uniquely identifiable (?) Examples: Roles Events Places External entities Structures Other things Object: car Modeling Attributes: VIN # Make Model Price
Relationships, Cardinality, Modality Relationships Define connections between objects Cardinality Defines the number of items on either end of a connection Modality Defines the necessity of a connection Person 1 1 insured owns * * Car 1 attached 1 Trailer Entity-Relationship Diagram (ERD)
DFD: A Basic Example (See Pressman Chapter 8, Section 8.6.1, pg. 195) Control panel commands and data SafeHome software display information alarm type Panel display Alarm Sensors sensor status telephone tones Telephone line External entities (squares) Data flows (directed edges) Processes (circles) Notice that the system is represented as a single bubble. This is known as a level 0 DFD, or a context diagram.
DFDs and Progressive Refinement (See Pressman Chapter 8, Section 8.6.1, pg. 196) Each DFD reveals progressively more detail than the DFD that preceded it. Level 1 DFD: Control panel commands and data Interact with user Configure request Start/stop request Configure system Refinement continues until each bubble can be (easily) implemented as a program module. password Activate / deactivate system Process password
Process Narrative (See Pressman Chapter 8, Section 8.6.4, pg. 200) password Process password A process specification describes all of the flow processes in the final (most detailed) DFD. The process password transform performs password validation at the control panel for the SafeHome security function. Process password receives a four-digit password from the interact with user function. The password is first compared to the master password stored within the system A process specification can be represented as a collection of process narratives.
How are DFDs Constructed? (See Pressman Chapter 8, Section 8.6.1, pg. 195) Scope document Grammatical parse Level 0 DFD Develop process narratives Grammatical parse Next level DFD (nouns = external entities, data/control objects, data stores) (verbs = processes) Note that nouns and verbs are associated with one another.
Some Guidelines Level 0 DFD should contain only a single bubble All arrows and bubbles should be meaningfully labeled Refinement begins by isolating next level processes, data objects, and data stores Refine only one bubble at a time Data flow continuity must be maintained between levels
Let s Try it Out! The Video Library Management System An excerpt from the scope document: The video library management system will interact with the user through a web-based browser interface. When the user logs into the system, the system will determine the user s access privileges based on the user configuration database. If the user is an administrator, the system will allow the user to enter new movie titles, new actor information, etc. If the user is not an administrator, the system will allow the user to query the system based on movie title, actor, director, etc. What might the level 0 DFD look like? Level 1?
And a Bit of Review Another excerpt from the scope document: The system will allow the user to store a number of information elements with each video, director, and actor. Each video will be characterized by a title, a genre descriptor, a short synopsis, a list of directors, a list of actors, a rating, and a UPC code. Each actor and director will be characterized by a first and last name, a year of birth, and a brief biography. When the user is viewing a video entry, they will be able to retrieve the full actor (or director) information by clicking the actor s (or director s) name. What would be an appropriate ERD diagram for this excerpt?