CS48704-1/47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.

Slides:



Advertisements
Similar presentations
Practice data flow diagramming as a tool for structured system programming (process modelling) DATA FLOW DIAGRAMs.
Advertisements

Alternative Approach to Systems Analysis Structured analysis
Chapter 7 Structuring System Process Requirements
Using Dataflow Diagrams
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
Analysis Modeling.
Chapter 8 Analysis Engineering Software Engineering: A Practitioner’s Approach by Roger S. Pressman.
CS 425/625 Software Engineering System Models
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.
Modeling the Processes and Logic
SE 555 Software Requirements & Specification Requirements Analysis.
CS /31 Illinois Institute of Technology CS487 Software Engineering Midterm Review David Lash.
Cardinality and Modality (ERD)
Requirements Modeling
Chapter 7 Structuring System Process Requirements
Entity-Relationship 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.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
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.
Lecture 6 Data Flow Modeling
CS 310 Ch8: System models Abstract descriptions of systems being analyzed to help the analyst understand the system functionality communicate with customers.
Chapter 7 Structuring System Process Requirements
PHASE 2: SYSTEMS ANALYSIS
Systems Analysis and Design in a Changing World, Fifth Edition
Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Analysis Modeling. Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Intro to Software System Modeling
CS /31 Illinois Institute of Technology CS487 Software Engineering OOA with UML David Lash.
1 Structuring Systems Requirements Use Case Description and Diagrams.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
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.
Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.
Software Engineering Lecture 11: System Analysis.
Modern Systems Analysis and Design Fifth Edition
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.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
CS223: Software Engineering
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Data Flow Diagram, Data Dictionary, and Process Specification PART I
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
Architectural Complexity  A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components.
CS646: Software Design and Architectures Design methods: SSA/SD †  Stands for: Structured Systems Analysis / Structured Design.  Primary applicable notations:
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 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 8 Analysis Engineering
Elaboration Process Lecture-16.
Analysis Classes Unit 5.
Business System Development
Some Simple Design Modeling Techniques
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Problem Solving How do we attack a large problem?
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Data Dictionaries ER Diagram.
Chapter 12 Analysis Modeling
Requirement Analysis using
Chapter 4: documenting information systems
Presentation transcript:

CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash

CS /47 Example of Modality and Cardinality

CS /47 Example of ERD

CS /47 Creating ERDs u Take each “things” (e.g., car, contact list) mentioned in requirements and ask about relationships to other things u Object-relationship pairs and therefore identified – Explore the carinality and modality of that relationship u Repeat for each object identified u Review the objects and establish attributes u Form the ERD and review

CS /47 ERD II example - Homesafe u Enables homeowner (HW) to config security system (SS), during install u HS monitors all sensors connected to SS u HS interacts with HW via Keypad on cntl panel (CP) u CP is used to program system u Each sensor (SEN) is assigned a # and type u A master passwd is programmed, Tel number are input for dialing on Sensor event (SEN) u on SEN event, alarm invoked & SS dials phone number, and gives info to (MS) monitoring Service u CP has keyboard input stuff

CS /47 ERD II example - Homesafe

CS /47 ERD II example - Derived Relationships u SS monitors sensor u SS enables/disables sensor u SS tests sensor u SS program sensor u Attributes of Sensor has type, internal id, zone location, alarm level

CS /47 ERD II example - Homesafe

CS /47 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.

CS /47 Data Flow Diagrams ( Information Flow ) u A graphical technique that depicts information flow and the transforms that are applied as data moves from input to output. – Input can be sensor, human operator, web page input, hardware – Transformation can be logical comparison, numerical algorithm, graphic algorithm, – Output can be LED, web page, report, effect on hardware

CS /47 Data Flow Diagram (Divide Operation) Level 0 DF (fundamental) diagram represents system with 1 bubble

CS /47 Data Flow Diagram (Symbols) Process (Data Transformation) External Entity (I/O Src/Dest) Data Store (all or part of the information store) System External Thing External Thing External Thing

CS /47 Data Flow Diagram (Data Flows or Connectors)

CS /47 Level 0 Data Flow Input Data

CS /47 Level 0 Data Flow

CS /47 Level 0 Data Flow (Interactive System)

CS /47 Data Flow Diagram (Divide Operation)

CS /47 Level 1 - Data Flow (Major Process Operators)

CS /47 Guidelines for building a Data Flow Diagram 1.Show the first level (level 0) as a single process with all of its external inputs and outputs sources. 2.Primary input and output should be carefully noted. 3.Refinement begins by isolating candidate processes. 4.All data flows and symbols should be labeled with meaningful names. 5.Information flow continuity must be maintained. (within the refinement) 6.One bubble at a time is expanded. 7.Record all components in the data dictionary.

CS /47 Level N Data Flow (Detailed Process to Transform)

CS /47 Data-Flow Example R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York p. 377

CS /47 Level 1 - introduce process and data store R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York p. 378

CS /47 Level 2 - Show more detail for each level 1 process (monitor sensors) R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York p. 379

CS /47 Behavioral Modeling u Behavior is the observable effects of an event, including its results. u Control flow diagramming – An extension to data flow diagramming – Adds events to the data model u State transition diagrams – More traditional behavior model. – Useful for a variety of applications.

CS /47 State Diagram u A state diagram illustrates how the system moves from state to state. For example – monitoring state -> alarm state -> monitoring state (homesafe) – What events trigger the change in state? u Sense danger, reset alarm u A state diagram shows the state machine – State Machine u A behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events

CS /47 What is the scientific base for state-machine? Conservation of Momentum Law When the resultant external force acting on a system is zero, the total momentum of the system remains constant.

CS /47 What are the components of a state machine? u States – Any observable mode of behavior. – A condition or situation during the life of an object during which it satisfies some condition, performs some activity or waits for some event. – Description is contained in a data dictionary. Name

CS /47 What are the components of a state machine? u Transitions – A relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. (Event & Conditions)

CS /47 Types of state transition diagrams u Action on transition – Actions are performed on event transition – On the diagram that is where the actions are defined. – Events, Conditions and Actions are described in the data dictionary. (Event & Conditions): Action(s)

CS /47 Example of action on transition

CS /47 Types of state-transition diagrams. u Action on state entry – Actions are performed when a state is entered. – Transitions carry optional data and not actions. – States, events, conditions and data are described in the data dictionary. State Name Action(s) (Event & Condition): Data

CS /47 Parser Example Given a text (stored on a file) consisting of words separated by SPACE characters or by CR (new line) characters, a program is supposed to read the text and suppress all extra SPACE characters according to the following rules: – Words should be separated only by one SPACE character, – Between a word and CR character there should be no SPACE character, – New line cannot start with a SPACE character, – Program terminates on EOF (End of File) character.

CS /47 Example u Processing States – New Line. Last character was a CR or beginning of process. – Word. Last character is not a space or CR. – Space. Last character is a space. – End-of-file.

CS /47 Example u Events (must be account for in each state) – End-of-file indicator – NL Character – Space Character – Text Characters

CS /47 Example u Actions – Read Next – Store Word – Set Error – List Stored Words

CS /47 State Diagram Example

CS /47 Analysis Modeling u Software models must represent: – the information that the sftwr acts on – the function that enable action – and overall system behavior u Requirements Models Roles: – Understand the information, function, behavior and information in the system – Focal Point for the review - Avoids lots of wrds help deal with complexity of problem – Become foundation for design process

CS /47 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.