Cardinality and Modality (ERD)

Slides:



Advertisements
Similar presentations
Alternative Approach to Systems Analysis Structured analysis
Advertisements

Chapter 7 Structuring System Process Requirements
Analysis Concepts, Principles, and Modeling
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.
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.
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.
Data Flow Diagramming. Data Flow Diagrams Data Flow Diagrams are a means to represent data transformation processes within an information system.
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
1 Lecture 3 Requirement Analysis System Analysis Concepts Modeling Techniques.
Requirements Modeling
Analysis Modeling Two primary methods today
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.
Chapter 10 Architectural Design
Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides.
Data and Process Modeling
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.
Business Process 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.
Phase 2: Systems Analysis
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.
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.
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 Entity-Relationship Diagram. 2 Components of ERD: –Entity –Relationship –Cardinality –Attributes.
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.
Database Design – Lecture 4 Conceptual Data 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.
CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 8 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily.
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
Software Engineering Lecture 11: System Analysis.
Chapter 12 Analysis Modeling. Analysis Modeling ä Two primary methods today ä Structured Analysis ä Object-oriented analysis ä Some important considerations.
Systems Analysis and Design 8th Edition
Software Analysis and Design Software Analysis Concepts and Principles Software Analysis Modeling Software Design Concepts and Principles Software Design.
CS223: Software Engineering
Data Flow Diagram, Data Dictionary, and Process Specification PART I
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b:
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.
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.
Structured Analysis Methods and Tools
Chapter 8 Analysis Engineering
Software Engineering: A Practitioner’s Approach, 6/e Chapter 8 Analysis Modeling copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Problem Solving How do we attack a large problem?
Requirements Modeling: Flow, Behavior, Patterns, and WebApps
Lecture 9- Design Concepts and Principles
Chapter 8 Building the Analysis Model (2) Analysis Modeling
Requirements Engineering
Data Dictionaries ER Diagram.
تحلیل سیستم‌ها مدل‌سازی پردازشی.
ANALYSIS MODELING.
CS 8532: Advanced Software Engineering
Lecture 9- Design Concepts and Principles
Chapter 12 Analysis Modeling
Requirement Analysis using
Presentation transcript:

Cardinality and Modality (ERD) Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N) Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship

Cardinality: Implies that a single customer repair action (s) Cardinality: Implies that here may be repair action (s) COUSTER REPAIR ACTION Is provided with Modality: Mandatory Implies that in order to have a repair action (s), we must have a customer Modality: Operational Implies that here may be a situation in which a repair action is not nessary

Functional Modeling and Information Flow (DFD) Shows the relationships of external entities, process or transforms, data items, and data stores DFD's cannot show procedural detail (e.g. conditionals or loops) only the flow of data through the software

Data store Output data External entity Intermediate data Input data Transform#1 Transform#2 Transform#3 Transform#4 Data store Intermediate data Input data Data store output Data store input

Functional Modeling and Information Flow (DFD) (continue) Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds) To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e.g. Ward and Mellor or Hately and Pirbhai)

Monitor and adjust temperature level Monitored temperature Temperature set point Input “Continuous” Output “Continuous”

Behavioral Modeling (STD) State transition diagrams represent the system states and events that trigger state transitions STD's indicate actions (e.g. process activation) taken as a consequence of a particular event A state is any observable mode of behavior Hatley and Pirbhai control flow diagrams (CFD) can also be used for behavioral modeling

Creating Entity Relationship Diagrams The following steps are required to build an ERD. Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities Analyst and customer define connections between the objects One or more object-relationship pairs is created for each connection The cardinality and modality are determined for an object-relationship pair Attributes of each entity are defined The entity diagram is reviewed and refined

Creating Data Flow Diagram Useful guideline for creating DFDs Level 0 data flow diagram should depict the system as a single bubble Primary input and output should be carefully noted Refinement should begin by consolidating candidate processes, data objects, and data stores to be represented at the next level Label all arrows with meaningful names Information flow must be maintained from one level to level Refine one bubble at a time Write a PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD

Creating Control Flow Diagrams To select potential candidate control ,the following guidelines are suggested List all sensors that are "read" by the software. List all interrupt conditions. List all "switches" that are actuated by an operator. List all data conditions. Recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs. Describe the behavior of a system by identifying its states; identify how each state is reached; and define the transitions between states. Focus on possible omissions-a very common error in specifying control; for example, ask: "Is there any other way I can get to this state or exit from it?"

F

Data Dictionary Contents Name - primary name for each data or control item, data store, or external entity Alias - alternate names for each data object Where-used/how-used - a listing of processes that use the data or control item and how it is used (e.g. input to process, output from process, as a store, as an external entity) Content description - notation for representing content Supplementary information - other data type information, preset values, restrictions, limitations, etc.