Analysis Modeling Two primary methods today

Slides:



Advertisements
Similar presentations
Alternative Approach to Systems Analysis Structured analysis
Advertisements

Chapter 7 Structuring System Process Requirements
Analysis Concepts, Principles, and Modeling
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Lecture 8- Analysis Modeling The Elements of Anaylsis Model The Elements of Anaylsis Model Data Modeling, Functional Modeling and Information Flow Data.
Chapter : Analysis Modeling
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Analysis Modeling.
Chapter 4 Enterprise Modeling.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Lecture 4 Behaviour Modelling Requirement Specification Object-Oriented Paradigm.
Chapter 14: Design Method --- data and architectural design Design -- A multistep process in which representations of data structure, program structure,
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Analysis Modeling Over view of today’s lesson T he analysis model is the first technical representation of a system. Analysis modeling uses a combination.
Analysis Modeling Instructor: Dr. Jerry Gao. Analysis Modeling Jerry Gao, Ph.D. Jan Elements of the analysis model - Data modeling - Functional.
CS /31 Illinois Institute of Technology CS487 Software Engineering Analysis Modeling Instructor David Lash.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
Cardinality and Modality (ERD)
1 Lecture 3 Requirement Analysis System Analysis Concepts Modeling Techniques.
Systems Analysis I Data Flow Diagrams
Requirements Modeling
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CS451 - Lecture 6 1 CS451 Topic 6: DFD Tutorial Yugi Lee STB #555 (816)
Chapter 7 Structuring System Process Requirements
Lesson 3 ANALYSIS MODELLING.
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
CS451 Introduction to Software Engineering Behavioral Modeling.
Chapter 10 Architectural Design
Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
1 Chapter 14 Architectural Design. 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 6-7 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides Jochen.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Data Flow Diagrams.
Real-Time Systems time dependent control oriented driven by events rather than data.
1 Ref: Prof Sarda Process Modeling…… Lecture Outline Data flow diagram (DFD)
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
1 Chapter 7 Requirement Modeling flow, behavior, patterns and Webapps.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Analysis Modeling. Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input.
Chapter 3 Software Requirements
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Intro to Software System Modeling
Chapter 12 Analysis Modeling
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 8 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily.
Software Engineering Lecture 11: System Analysis.
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Chapter 12 Analysis Modeling. Analysis Modeling ä Two primary methods today ä Structured Analysis ä Object-oriented analysis ä Some important considerations.
CS223: Software Engineering
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Functional Modeling Lecture # Recap We had talked about object-oriented static modeling in quite detail We had developed a OO static model of.
Course Instructor: Kashif I hsan 1. Chapter # 6 2.
Elements Of Modeling. 1.Data Modeling  Data modeling answers a set of specific questions that are relevant to any data processing application. e.g. ◦
1 8.1 Requirements Analysis Rules of Thumb Rules of Thumb Models should focus on requirements that are visible within the problem or business domain. The.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 8 Analysis Modeling copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Requirements Modeling: Flow, Behavior, Patterns, and WebApps
Chapter 8 Building the Analysis Model (2) Analysis Modeling
Data Dictionaries ER Diagram.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 8 Analysis Modeling copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
ANALYSIS MODELING.
CS 8532: Advanced Software Engineering
Chapter 12 Analysis Modeling
Requirement Analysis using
Presentation transcript:

Analysis Modeling Two primary methods today Structured Analysis Object-oriented analysis Some important considerations Analysis products must be maintainable Effective partitioning is essential Graphics should be used whenever possible Distinguish between logical and implementation December 2007

Structured Analysis Elements of Analysis Describe what customer requires Establish basis for creating software design Define requirements that can be validated December 2007

Graphical View of Model Data Dictionary Entity Relationship Diagram Data Flow State Transition Object Description Process Specification Control ( ERD) (DFD) (STD) December 2007

Data Modeling The model consists of Data objects Data object [types] Attributes Relationships Data objects A representation of almost any composite information that must be understood by software. December 2007

Data Modeling Attributes Attributes define the properties of a data object and take on one of three different characteristics: Name an instance of the data object Describe the instance Make reference to another instance Make Model ID# Body type Color Owner Ford Taurus Q12A45.. Sedan Blue ABC Lexus LS400 AB123... Sports White XYZ Naming attributes Descriptive attributes Referential Identifier December 2007

Data Modeling Relationships Defined pairwise -- many varieties Book Bookstore orders displays sells returns December 2007

Cardinality and Modality How many occurrences of object X are related to how many occurrences of object Y One-to-one (1:1) One-to-many (1:N) Many-to-many (M:N) Modality =0 => optional relationship =1 => relationship must appear December 2007

Example Customer Repair action is provided with Mandatory: in order to have a repair action, we must have a customer Optional: there may be a situation in which a repair action is not necessary December 2007

Entity Relation Diagrams (ERD) Cornerstone of the data model -- includes data objects, attributes, relationships, and various type indicators manufacturer car builds ID# model body type engine transmission . . . Data Object Table December 2007

Example December 2007

Data Object Hierarchies December 2007

Associating Data Objects December 2007

Functional Modeling Data Dictionary Entity Relationship Diagram Data Flow State Transition Object Description Process Specification Control ( DFD ) December 2007

Data Flow Diagrams (DFD) A graphical technique that depicts information flow and the transforms applied as data move from input to output Not the same as flow charts. Does not show the logic of the transformations Can be used at any level of abstraction December 2007

General Information Flow Model December 2007

Basic Notation December 2007

External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something December 2007

A data transformer (changes input to output) Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function December 2007

Data Flow Data flows through a system, beginning as input and be transformed into output. base compute triangle area area height December 2007

Data Stores Data is often stored for later use. look-up sensor data sensor #, type, location, age look-up sensor data report required type, location, age sensor number sensor data December 2007

Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic December 2007

Constructing a DFD—I review the data model to isolate data objects and use a grammatical parse to determine “operations” determine external entities (producers and consumers of data) create a level 0 DFD December 2007

Level 0 DFD Example user digital video monitor processor video source processing request user requested video signal digital video processor monitor video source NTSC video signal December 2007

Constructing a DFD—II write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio December 2007

The Data Flow Hierarchy b x P y level 0 c p2 a f p1 b p4 d 5 g p3 e level 1 December 2007

Flow Modeling Notes each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information) December 2007

Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts December 2007

DFDs: A Look Ahead analysis model Maps into design model December 2007

Real Time Extensions Fundamental issue - The time at which results are produced is a part of the correctness of the computation. Hatley/Pirbhai notation December 2007

Ward/Mellor Notation December 2007

Example December 2007

Example December 2007

Hatley and Pirbhai Extensions Use separate data flow diagram (DFD) and control flow diagram (CFD) Data flow diagrams Used to represent data and the processes that manipulate it Control flow diagrams Show how events flow among processes and show those external events that cause various processes to be activated December 2007

Control Flow Diagrams Represents “events” and the processes that manage events An “event” is a Boolean condition that can be ascertained by: listing all sensors that are "read" by the software. listing all interrupt conditions. listing all "switches" that are actuated by an operator. listing all data conditions. recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs. December 2007

The Control Model the control flow diagram is "superimposed" on the DFD and shows events that control the processes noted in the DFD control flows—events and control items—are noted by dashed arrows a vertical bar implies an input to or output from a control spec (CSPEC) — a separate specification that describes how control is handled a dashed arrow entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the December 2007 processes—this is done via the CSPEC

Relationship Between Models December 2007

Example December 2007

CFD for Photocopier paper feed status alarm (jammed, empty) start/stop manage status produce Copy Info copying user read displays operator input Problem type Reload status perform problem reload diagnosis paper full December 2007 repro fault

Control Specification (CSPEC) The CSPEC can be: state diagram (sequential spec) state transition table combinatorial spec decision tables activation tables December 2007

Guidelines for Building a CSPEC list all sensors that are "read" by the software list all interrupt conditions list all "switches" that are actuated by the operator list all data conditions recalling the noun-verb parse that was applied to the software statement of scope, review all "control items" as possible CSPEC inputs/outputs describe the behavior of a system by identifying its states; identify how each state is reach and defines the transitions between states focus on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?" December 2007

Behavioral Modeling Description Process Object Specification Data Flow Dictionary Entity Relationship Diagram Data Flow State Transition Object Description Process Specification Control ( STD ) December 2007

State Transition Diagrams A State is any observable mode of behavior e.g., reading commands, computing control, waiting for next time event States represented as rectangles Arrows represent transitions Value above arrow identifies event causing transition Value below arrow indicates ensuring action December 2007

State Transition Diagram reading commands making copies reloading paper diagnosing problem jammed invoke perform problem-diagnosis empty invoke reload paper not jammed invoke read-op-input full idle full and start invoke manage-coping copies done December 2007

Creating an ERD List entities that customer addresses For each, determine the connections For each connection, create one or more object-relationship pairs For each relationship, determine cardinality and modality Define the attributes of each entity Formalize and review ERD Iterate December 2007

Home Security System Example Initial entities Homeowner, control panel, sensors, security system and monitoring service December 2007

Home Security System Example Relationships between sensor and security sys. Security system monitors sensor Security system enables/disables sensor Security system tests sensor Security system programs sensor December 2007

Creating a Data Flow Model First create level 0 diagram Depict software system as single bubble Show primary inputs and outputs Identify processes, data objects, and data stores to be expanded at next level Label all arrows with meaningful names Information flow continuity must be maintained Refine only one bubble at a time December 2007

Home Security System Example December 2007

Refinement Analyze textual description of bubble Examples verbs are often processes nouns are often external entities, data or control objects or data stores Examples Control panel is used to program and configure the system Upon a sensor event, the software invokes an alarm December 2007

Home Security System Example December 2007

Home Security System Example December 2007

Creating Control Flow Models Strip arrows from DFD Add event and control items. E.g., try List all sensors read by the software List all interrupt conditions List all operator actuated switches List all data conditions Check noun-verb parse for possible CSPEC I/O Identify states, how each is reached and transitions Focus on possible omissions One of the issues here is to find the controlling events. December 2007

Level 1 CFD for Safe-Home December 2007

Control Specification December 2007

Process Activation Table December 2007

Process Specifications Describes all flow model processes at final level of refinement Narrative text, Program design language description Mathematical equations Tables Diagrams Charts December 2007

Data Dictionary Description Process Object Specification Entity Data Flow Data Relationship Diagram Diagram Data Dictionary State Transition Diagram December 2007 Control Specification

Data Dictionary Why a data dictionary? Need an organized way to represent data & control characteristics Usual contents Name Alias Where and how used Content description (of composite items) Supplementary information, e.g., restrictions, limitations, preset values December 2007

Example Name: Shuttle pose Aliases: Position-orientation vector Where used: Display of Shuttle on map Content: x, y, z position wrt to Earth’s Center, roll, pitch, yaw Supplementary Info: Elevation must be above 140 nautical miles December 2007

Data Dictionary Common tools supporting DD Preventing creation of duplicate names Enforce naming conventions Printing dictionary Determine the range of impact of changes, i.e., which processes are affected Assist configuration management December 2007

Summary Key elements Data modeling Functional modeling Data objects, attributes and relationships Cardinality and modality Entity-relationship diagrams Functional modeling Data and control flow diagrams Behavioral modeling State transition diagrams Data Dictionary December 2007