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.

Slides:



Advertisements
Similar presentations
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Advertisements

Software Engineering Fall 2005
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.
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.
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.
Chapter 8 Analysis Modeling
Chapter 21 Object-Oriented Analysis
Chapter 6 Requirements Modeling: Scenarios, Information, and Analysis Classes Slide Set to accompany Software Engineering: A Practitioner’s Approach,
Object-Oriented Analysis
1 Lecture 3 Requirement Analysis System Analysis Concepts Modeling Techniques.
Analysis Modeling Two primary methods today
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 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides Jochen.
Analysis Modeling. Class-Based Modeling Identify analysis classes by examining the problem statement Use a “grammatical parse” to isolate potential classes.
Lesson 3 ANALYSIS MODELLING.
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
CS451 Introduction to Software Engineering Behavioral Modeling.
SEC 308 Yazılım Mühendisliği SEC 308 Yazılım Mühendisliği Software Requirements 1.
1 Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - - Jochen.
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 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides Jochen.
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.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
1 Chapter 7 Requirement Modeling flow, behavior, patterns and Webapps.
1 Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - - Jochen.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
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.
Developed by Reneta Barneva, SUNY Fredonia for CSIT 425 Requirements Modeling.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Chapter 8 Analysis & Modeling. Data Modeling examines data objects independently of processing focuses attention on the data domain creates a model at.
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.
Modeling ECE 417/617: Elements of Software Engineering Stan Birchfield
1 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.
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.
Chapter 10 요구사항 모델링 : 클래스 기반 방법론 Requirements Modeling: Class-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/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.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
CS 4500: Software Development Mondays and Wednesdays 2:50-4: Snell Engineering Center.
Chapter 8 Analysis Engineering
Appendix 3 Object-Oriented Analysis and Design
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 Analysis & Modeling
Chapter 8 Building the Analysis Model (2) Analysis Modeling
Software Engineering: A Practitioner’s Approach, 6/e Chapter 8 Analysis Modeling copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Object-Oriented Analysis
Chapter 9 Requirements Modeling: Scenario-Based Methods
Overview of Software Requirements
CRC Modeling (class-relationship-collaborator)
Chapter 10 Requirements Modeling: Class-Based Methods
CS 8532: Advanced Software Engineering
Unit-3 Analysis Modeling
Software Engineering: A Practitioner’s Approach, 6/e Chapter 8 Analysis Modeling copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
Chapter 20 Object-Oriented Concepts and Principles
Presentation transcript:

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 level of abstraction should be relatively high. Models should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other non- functional models until design. Delay consideration of infrastructure and other non- functional models until design. Minimize coupling throughout the system. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be. Keep the model as simple as it can be.

2 8.3 Data Modeling examines data independently of processes examines data independently of processes indicates how data objects relate to one another indicates how data objects relate to one another Object – something that is described by a set of attributes and will be manipulated within the software (system) Object – something that is described by a set of attributes and will be manipulated within the software (system) Each instance of an object (e.g., a book) can be identified uniquely (e.g., ISBN#) Each instance of an object (e.g., a book) can be identified uniquely (e.g., ISBN#) Object (automobile) has attributes (make, model, body type, price, etc.) Object (automobile) has attributes (make, model, body type, price, etc.)

3 The ERD: An Example (1,1) (1,m) places Customer request generates (1,m) (1,1) workorder worktasks materials consistsof lists (1,1) (1,m) (1,1) (1,m) selectedfrom standard task table (1,m) (1,1)

4 8.4 Object-Oriented Analysis Must be understood to apply class-based elements of the analysis model Must be understood to apply class-based elements of the analysis model Key concepts: Key concepts: Classes and objects Classes and objects Attributes and operations Attributes and operations Encapsulation and instantiation Encapsulation and instantiation Inheritance Inheritance

5 What is a Class? external entities things occurrences roles organizational units places structures class name attributes: operations:

6Encapsulation/Hiding The object encapsulates both data and the logical procedures required to manipulate the data Achieves “information hiding” method # 1 data method # 2 method # 4 method # 5 method # 6 method # 3

7 Class Hierarchy Chair Table Desk”Chable" instances of Chair PieceOfFurniture (superclass) subclasses of the

8 Methods (a.k.a. Operations, Services) An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. A method is invoked via message passing.

9 8.5 Scenario-Based Modeling “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” Ivar Jacobson What are the main tasks or functions that are performed by the actor? What system information will the the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

10 Use-Case Diagram

11 Activity Diagram Supplements the use-case by providing a diagrammatic representation of procedural flow

12 Swimlane Diagrams Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle.Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle.

Flow-Oriented Modeling external entity process data flow data store Represents how data objects are transformed at they move through the system Data flow diagram (DFD) Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements

14 Level 0 DFD Example user processingrequest videosource NTSC video signal digitalvideoprocessor requestedvideosignal monitor

15 The Data Flow Hierarchy P a b xy p1 p2 p3 p4 5 a b c d e f g level 0 level 1

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

17 Control Flow Diagrams the control flow diagram is "superimposed" on the DFD and shows events that control the processes noted in the DFD 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 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 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 entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition 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 a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the processes—this is done via the CSPEC control flows do not physically activate/deactivate the processes—this is done via the CSPEC

18 Control Flow Diagram read operator input create user displays perform problem diagnosis reload process manage copying beeper on/off start copies done display panel enabled full problem light empty jammed

Class-Based Modeling Identify analysis classes by examining the problem statement Identify analysis classes by examining the problem statement Use a “grammatical parse” to isolate potential classes Use a “grammatical parse” to isolate potential classes Identify the attributes of each class Identify the attributes of each class Identify operations that manipulate the attributes Identify operations that manipulate the attributes

20 Class Diagram Class name attributes operations

21 Class Diagram

CRC Modeling

23 Reviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index cards. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. The review leader reads the use-case deliberately. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards.

Behavioral Modeling The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: Evaluate all use-cases to fully understand the sequence of interaction within the system. Evaluate all use-cases to fully understand the sequence of interaction within the system. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Create a sequence for each use-case. Create a sequence for each use-case. Build a state diagram for the system. Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency. Review the behavioral model to verify accuracy and consistency.

25 Behavioral Modeling make a list of the different states of a system (How does the system behave?) make a list of the different states of a system (How does the system behave?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate event indicate action indicate action draw a state diagram or a sequence diagram draw a state diagram or a sequence diagram

26 State Diagram for the ControlPanel Class

27 Sequence Diagram