Intro to Software System Modeling

Slides:



Advertisements
Similar presentations
Tutorial 8: Developing an Excel Application
Advertisements

IFS310: Week 3 BIS310: Structured Analysis and Design 5/4/2015 Process Modeling and Data Flow Diagrams.
Chapter 7 Structuring System Process Requirements
Analysis Modeling.
1 SWE Introduction to Software Engineering Lecture 21 – Architectural Design (Chapter 13)
CS /31 Illinois Institute of Technology CS487 Software Engineering Analysis Modeling Instructor David Lash.
Basic of DFD. Developing a DFD There are no FIXED rules about how a DFD should be developed… There is no such a DFD call “CORRECT DFD”… Expert SAs may.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
Cardinality and Modality (ERD)
Process Modeling and Data Flow Diagrams
Data Flow Diagram Notations
Copyright © 2013 FingerTec Worldwide Sdn.Bhd. All rights reserved.
S R S S ystem R equirements S pecification Specifying the Specifications.
Monitoring systems COMET types MS55 & MS6 MS55/MS6 Configuration.
Process Modeling SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
Application architectures
Chapter 7 Structuring System Process Requirements
Entity-Relationship Design
Architectural Design.
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
1 Structured Analysis Techniques. 2 Data Flow Diagrams.
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.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Process.
Typical Software Documents with an emphasis on writing proposals.
1 Chapter 2 Revision: Documentation DFD System FC.
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.
Data-Flow Diagrams Week 10 Lecture 1. Data Flow Diagrams (DFDs) One of most important modelling tools used by system analysts In use since late 1970’s.
Data Flow Diagram A method used to analyze a system in a structured way Used during: Analysis stage: to describe the current system Design stage: to describe.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
Chapter 7 Structuring System Process Requirements
Logic Modeling Logic and timing are not represented on data flow diagrams or entity-relationship diagrams Processes contain logic - what happens under.
Requirements Engineering How do we keep straight what we are supposed to be building?
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
2/6/01D-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Using PARTS to Illustrate Requirements Concepts.
Functional Modeling Question How do you know if you have enough information to compute the necessary output values? How do you know if you have.
Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING.
10 ITK261 The traditional approach to design Reading: Chapter 10 Oct 9, 11.
Home Guard Security System. Introduction & Basic Ideas Home Guard Security System.
TCS2411 Software Engineering1 Data-Flow Oriented Design “From DFD to Structure Chart”
CORE 1: PROJECT MANAGEMENT Designing. This stage is where the actual solution is designed and built. This includes describing information processes and.
DataFlow Diagram – Level 0
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
Week 7 - Systems Engineering and Analysis
Software Requirements Engineering Elaboration Process Lecture-14.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.
Chapter 12 Analysis Modeling. Analysis Modeling ä Two primary methods today ä Structured Analysis ä Object-oriented analysis ä Some important considerations.
section II Analysis Systems Analysis and Design
System Requirements Specification
CS223: Software Engineering
Intelligent Thief & Home Security System: Brahms Perspective
Application architectures Advisor : Dr. Moneer Al_Mekhlafi By : Ahmed AbdAllah Al_Homaidi.
1 Functional Modeling Lecture # Recap We had talked about object-oriented static modeling in quite detail We had developed a OO static model of.
CS646: Software Design and Architectures Design methods: SSA/SD †  Stands for: Structured Systems Analysis / Structured Design.  Primary applicable notations:
CS646: Software Design and Architectures Design notations Dynamic  Data flow diagrams (DFDs).  State transition diagrams (STDs).  Statecharts.  Structure.
Chapter 8 Analysis Engineering
Elaboration Process Lecture-16.
DFD(Data Flow Diagram)
G063 - Data flow diagrams.
Dynamic Modeling of Banking System Case Study - I
UML Use Case Diagrams.
Chapter 8 Building the Analysis Model (2) Analysis Modeling
System Requirements Specification
Logic Modeling Logic and timing are not represented on data flow diagrams or entity-relationship diagrams Processes contain logic - what happens under.
Chapter 12 Analysis Modeling
Chapter 4: documenting information systems
Presentation transcript:

Intro to Software System Modeling

Model vs Design Model Design may be used in the SRS used by the software designers may be useful as an overview for the programmers may be used for validation with the customer Design what the programmers are told to build

What info is modeled? Relationships between Data Process Flow Data Transformation Control Flow within the source code Format of the Database Timing constraints (real-time systems) User Interface Flow etc…

Major Modeling and Design Diagrams UML Data Flow Diagrams State Transition Diagrams Structure Charts Entity Relationship Diagrams Use Cases

Data Flow Diagrams Illustrate how processes transform data Very good for modeling a system at a high level, e.g. for the SRS Poor at conveying design of software, except a few cases such as distributed systems process external entity data flow data file

DFD Syntax Rules a model is composed of a series of diagrams that present more and more detail the top-level diagram is the "context" level and contains only one process (our software) data cannot just appear or disappear, i.e. inputs and outputs must match between levels process numbers indicate both family and level of detail all data flows are defined in a Data Dictionary

DFD Example Display Panel display Control data Keypad commands Alarm Alarm System alarm type Alarm sensor status Sensors number tones and recorded msgs Phone Line

DFD Example commands Configure config config data System request 2 Configure System config data config request 1 User Interface config info config data on,off 4 Activate/ Deactivate passwd on/off msg 5 Generate Display display data 3 Check Password valid id msg sensor data alarm type 6 Sensor Monitor sensor status number tones and recorded msgs

State Transition Diagrams Illustrates events and their effects on the system's state or status Good for design of user interfaces real-time and event-based systems system state transition

STD Example checking off valid passwd password start activate invalid de-activate working idle valid passwd problem valid passwd alerting via alarm alerting via phone not acknowledged invalid passwd

Petri Nets - similar to STDs http://www.ppgia.pucpr.br/~maziero/diversos/petri/net.png

Structure Charts Illustrates Control Flow Very good for conveying the design of source code Very inappropriate for modeling a system in a SRS module

SC Syntax Rules one single tree for entire system tree has one node at the top nodes are individual code units / modules nodes call nodes below them nodes are called left to right leaf nodes are usually utility modules may show data flow may show conditionals and loops

SC Example main get_cmd check_sensors Is this correct? turn_off change_ phone_num activate_ alarm send_ phone_msg check_passwd

SC Example main get_cmd check_sensors turn_off change_ phone activate_ alarm send_ phone_msg check_passwd

Entity Relationship Diagrams Illustrates connections between data objects Excellent for design of a database Good for modeling or specifying what data a system should handle Cardinality = max number of objects that can participate in the relationship Modality = is the relationship required

ER Example security sensor system monitors enables/disables tests programs is programmed by

Use Cases Illustrates activities performed by the user. Excellent for modeling a system helps identify data, processes, features Not directly a design spec, but shows programmers the context of their code. system components an action done by an actor actor

Example Use Case Alarm System smoke detector access sensor status via internet motion detector configure the sensor ranges home owner turn on and off Other Use Cases: other homeowner activities security guard burglar

Use Cases for System Modeling

Example Modeling Problem System Req : every employee has a home office Does "home office" mean they have a spare bedroom at home with a computer, or that everyone is assigned to a regional main office? employee home office employee home office

Example Modeling Problem Any user can delete a regular file, but deleting a reserved file must require a password confirmation. Unclear : can any user delete a "reserved file"? How do we show that Requirement in the SRS? How do we show that in the Design?

Summary Good for Modeling: Good for Design: Use Cases DFDs ERs what the user wants to do DFDs process / how the data is transformed ERs structure and nature of the data Good for Design: Structure Charts