Analysis Modeling. Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input.

Slides:



Advertisements
Similar presentations
Requirements Modeling Strategies
Advertisements

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
Chapter 4 Enterprise Modeling.
Chapter 8 Analysis Engineering Software Engineering: A Practitioner’s Approach by Roger S. Pressman.
Software Design Deriving a solution which satisfies software requirements.
Chapter 4.
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.
Systems Analysis and Design 9th Edition
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,
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.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Modeling the Processes and Logic
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
Chapter 4.
Cardinality and Modality (ERD)
Requirements Modeling
Analysis Modeling Two primary methods today
DATA FLOW DIAGRAMS IT 155.
Chapter 10: Architectural Design
 A data flow diagram ( DFD ) is a graphical representation of the "flow" of data through an information system.  A data flow diagram can also be used.
Chapter 7 Structuring System Process Requirements
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
Traditional Approach to Requirements Data Flow Diagram (DFD)
Modeling the system the data flow diagram the context diagram level decomposition the cornucopia case portfolio project Systems Analysis and Design for.
Chapter 10 Architectural Design
Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides.
1 Chapter 14 Architectural Design. 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
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.
Using Dataflow Diagrams – Part 2 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
Chapter 7 Structuring System Process Requirements
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
DFDs vs. Use Case Modeling COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University.
Context Diagrams. What are dataflow diagrams used for? Dataflow diagram  A graphical representation that depicts information flow and the transforms.
Analysis Modelling Approaches - Structured Analysis Considers data and the process that transforms the data into separate entities –Data objects Modelled.
Modeling ECE 417/617: Elements of Software Engineering Stan Birchfield
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.
Design Methods Instructor: Dr. Jerry Gao. Software Design Methods Design --> as a multistep process in which we design: a) data structureb) program structure.
IS3320 Developing and Using Management Information Systems Lecture 16: Data-Flow Diagrams 1 (Intro to Context-Level diagrams) Rob Gleasure
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.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
Building analysis model  Analysis modeling uses a combination of text and diagrammatic forms to depict requirements for data function and behavior in.
Systems Analysis and Design 8th Edition
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.
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.
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
1 Functional Modeling Lecture # Recap We had talked about object-oriented static modeling in quite detail We had developed a OO static model of.
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.
Chapter 8 Analysis Engineering
Business System Development
DFD(Data Flow Diagram)
Problem Solving How do we attack a large problem?
System Design and Modeling
Requirements Modeling: Flow, Behavior, Patterns, and WebApps
System Design.
Requirements Engineering
Data Dictionaries ER Diagram.
ANALYSIS MODELING.
Requirement Analysis using
Software Modelling and Design
Presentation transcript:

Analysis Modeling

Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input in a variety of forms; applies hardware, software, and human elements to transform it; and produces output in a variety of forms  Structured analysis began as an information flow modeling technique.  A rectangle is used to represent an external entity (software, hardware, a person)  A circle (sometimes called a bubble) represents a process or transform that is applied to data (or control) and changes it in some way.

 An arrow represents one or more data items (data objects) and it should be labeled.  The double line represents a data store—stored information that is used by the software.  First data flow model (sometimes called a level 0 DFD or context diagram) represents the entire system.  It provides incremental detail with each subsequent level. Function Modeling & Information Flow

Information Flow model

Creating a Data Flow Model  It enables software engineer to develop models of the information domain and functional domain at the same time.  Data flow diagram may be used to represent a system or software at any level of abstraction  As DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition of the system.  As DFD refinement results in corresponding refinement of data as it moves through the processes that represent the application

DFD Guidelines  Depict the system as single bubble in level 0.  Primary input and output should be carefully noted  Refine by isolating candidate processes and their associated, data objects and data stores  All arrows and bubbles should be labeled with meaningful names.  Information flow continuity must be maintained from level to level.  One bubble at a time should be refined.

Data flow models  A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows.  Level 0 DFD refinement into level 1 DFD with all relevant processes to the system.  Level 1 DFD each processes can be refined into level 2 DFD.  Refinement of DFD continues until each bubble performs a simple function.

Control flow model  Application which contains collection of classes are dependent on event rather than data, produce control information rather than reports or displays.  Such application require the use of control flow modeling in addition to data flow modeling.

Guideline for control flow  List all processes that are performed by the software.  List all the interrupt conditions.  List all activities that are performed by operator or actor.  List all data conditions.  Review all the “Control items” as possible for control flow inputs / outputs.  Describe the behavior of a system by identifying its states; identify how each state is reached; define the transitions between states.  Focus on possible omission – a very common error in specifying control

Control Specification (CSPEC)  CSPEC represent the behavior of the system in two different ways.  It contains a state diagram – sequential specification of behavior.  It also contain program activation table – combinatorial specification of behavior.  By reviewing the state diagram, a software engineer can determine the behavior of the system and can discover whether there are “holes” in specified behavior.  CSPEC describe the behavior of the system, but it gives us no information about the inner working of the processes that activated result.

Process Specification (PSPEC)  Used to describe all flow model processes that appear at the final level of refinement.  It include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, diagrams or charts.  By providing a PSPEC to accompany each bubble in the flow model, the software engineer creates a “mini-spec” that can serve as guide for design of the software component that will implement the process.