1 Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - - Jochen.

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

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 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Chapter 8 Analysis Engineering Software Engineering: A Practitioner’s Approach by Roger S. Pressman.
Software Requirements Engineering Elaboration Process Lecture-13.
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.
Introduction To System Analysis and Design
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 6 Requirements Modeling: Scenarios, Information, and Analysis Classes Slide Set to accompany Software Engineering: A Practitioner’s Approach,
1 Lecture 3 Requirement Analysis System Analysis Concepts Modeling Techniques.
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.
Chapter 8 Analysis Modeling
CS451 - Lecture 6 1 CS451 Topic 6: DFD Tutorial Yugi Lee STB #555 (816)
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
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 (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides.
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.
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
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.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
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.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 Object-oriented and Structured System Models.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
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.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
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 Chapter 6-7 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - - Jochen.
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.
Analysis Modeling CpSc 372: Introduction to Software Engineering
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.
Systems Analysis and Design in a Changing World, Fourth Edition
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
SE-3910 Real-time Systems Week 9, Classes 1 and 2 – Announcement* (regexp style) – Significance Testing – Failure statistics – Structured Analysis & Design.
Building analysis model  Analysis modeling uses a combination of text and diagrammatic forms to depict requirements for data function and behavior in.
Data Flow Diagrams Slide 1. Key Definitions Data flow diagramming shows business processes and the data that flows between them Slide 2.
1 Functional Modeling Lecture # Recap We had talked about object-oriented static modeling in quite detail We had developed a OO static model of.
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 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
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
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
Presentation transcript:

1 Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides Jochen Rick’s slides from GA Institute of Technology - Extra_Examples/DFD_Example_1/ - System Analysis and Design slides edited by Yale Braunsteinhttp://

2 Requirements Analysis Requirements analysis specifies software’s operational characteristics indicates software's interface with other system elements establishes constraints that software must meet Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier requirement engineering tasks build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.

3 Analysis Phase: What is it? Three objectives: To describe what the customer requires To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built Three objectives: To describe what the customer requires To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built

4 Analysis Modeling Approaches Structural analysis: The data: The model defines their attributes and relationships. The processes that transform the data: The model shows how they transform the data objects as they flow through the system. Object-oriented analysis: Focus: Classes and their inter-relationships UML is predominantly object-oriented But don’t be to dogmatic!

5 Elements of the Analysis Model Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Scenario-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Class-based elements Data-flow diagrams Control flow diagrams Processing narratives Flow-oriented elements State diagrams Sequence diagrams Behavioral elements Analysis Model

6 Data Modeling examines data objects independently of processing focuses attention on the data domain creates a model at the customer’s level of abstraction indicates how data objects relate to one another

7 What is a Data Object? Object —something that is described by a set of attributes (data items) and that will be manipulated within the software (system) eachinstance of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items What are some typical data objects?

8 Typical Data Objects external entities (printer, user, sensor) things (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) (e.g., division, team) places (e.g., manufacturing floor) (e.g., manufacturing floor) structures (e.g., employee record)

9 Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object object: automobile attributes: make make model model body type body type price price options code options code How do data objects differ from OO classes or do they?

10 What is a Relationship? relationship —indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically several instances of a relationship can exist objects can be related in many different ways

11 ERD Notation (0, m) (1, 1) object object relationship 1 2 One common form: (0, m) (1, 1) object 1 object 2 relationship Another common form: attribute See for a tutorial on how to draw entity relationship diagrams.

12 The ERD: An Example (1,1) (1,m) places Customer request for service generates (1,n) (1,1) workorder worktasks materials consistsof lists (1,1) (1,w) (1,1) (1,i) selectedfrom standard task table (1,w) (1,1)

13 The Flow Model Every computer-based system is an information transform.... computerbasedsystem input output

14 Flow Modeling Notation external entity process data flow data store

15 External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something

16 Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

17 Data Flow Data flows through a system, beginning as input and be transformed into output. computetrianglearea base height area

18 Data Stores Data is often stored for later use. look-upsensordata sensor # report required sensor #, type, location, age sensor data sensor number type, location, age

19 Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic

20 Constructing a DFD—I review the data model to isolate data objects and use a grammatical parse to determine “operations” determine external entities (producers and consumers of data) create a level 0 DFD

21 Level 0 DFD Examples user processingrequest videosource NTSC video signal digitalvideoprocessor requestedvideosignal monitor

22 Constructing a DFD—II write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio

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

24 Example DFD: Level 1

25 DFD: A practical example Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000 the review board blamed the navigation error on a communications foul-up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin.

26 Flow Modeling Notes each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

27 Activity Diagram Supplements the use-case by providing a diagrammatic representation of procedural flow How might we make this better?

28 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

29 Activity Diagram Example - To show concurrent activity, activity diagrams allow branches and joins. - You can also reference or include other activity diagrams

30 Lets Try It Lets create a swimlane activity diagram for opening a Lemonade stand.

31 Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Scenario-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Class-based elements Data-flow diagrams Control flow diagrams Processing narratives Flow-oriented elements State diagrams Sequence diagrams Behavioral elements Analysis Model Elements of the Analysis Model Onward to data flow diagrams!

32 Flow-Oriented Modeling Represents how data objects are transformed at they move through the system A data flow diagram (DFD) is the diagrammatic form that is used 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

33 Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Scenario-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Class-based elements Data-flow diagrams Control flow diagrams Processing narratives Flow-oriented elements State diagrams Sequence diagrams Behavioral elements Analysis Model Elements of the Analysis Model Oh behave!

34 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: 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. Create a sequence for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency.

35 State Representations In the context of behavioral modeling, two different characterizations of states must be considered: the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function The state of a class takes on both passive and active characteristics [CHA93]. A passive state is simply the current status of all of an object’s attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.

36 State Diagram for the ControlPanel Class

37 The States of a System state—a set of observable circumstances that characterizes the behavior of a system at a given time state transition —the movement from one state to another event —an occurrence that causes the system to exhibit some predictable form of behavior action —process that occurs as a consequence of making a transition

38 Behavioral Modeling 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 event indicate action draw a state diagram or a sequence diagram

39 State Diagram - Lets Try It! You are designing a traffic light system for this intersection. Draw a state diagram showing the different states and how they transition. North South East West

40 Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Scenario-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Class-based elements Data-flow diagrams Control flow diagrams Processing narratives Flow-oriented elements State diagrams Sequence diagrams Behavioral elements Analysis Model Elements of the Analysis Model Onward to Class-based elements!

41 Object Oriented Analysis (OOA) The intent of OOA is to define all classes (and the relationships and behavior associated with them) that are relevant to the problem to be solved. For that, a number of tasks must occur: 1. Classes must be identified (i.e., attributes and methods) 2. A class hierarchy is defined 3. Object-to-object relationships should be represented 4. Object behavior must be modeled 5. Tasks 1 through 4 are reapplied iteratively

42 Object-Oriented Concepts What are the basic object oriented concepts?

43 Object-Oriented Concepts What are the basic object oriented concepts? Classes and objects Attributes and operations Encapsulation and instantiation Inheritance

44 Encapsulation/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

45 Scenario Based Modeling: Use-Cases a scenario that describes a “thread of usage” for a system actors represent roles people or devices play as the system functions users can play a number of different roles for a given scenario “[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

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

47 Domain Analysis Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain... What is object oriented domain analysis then?

48 Domain Analysis Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain... Object-oriented domain analysis is the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks... Donald Firesmith

49 Grammatical Parsing Write an informal description of the problem. The customer requirements document is one such description. Underline all nouns in the description Decide which of these are really objects which the project requires and organize them in related clusters

50 Grammatical Parsing University Bank will be opening in Oxford, Mississippi, in January, We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM

51 Grammatical Parsing University Bank will be opening in Oxford, Mississippi, in January, We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM

52 Typical Classes (a reminder) External entities - printer, user, sensor Things - reports, displays, signals Occurrences or events (e.g., interrupt, alarm) Roles (e.g., manager, engineer, salesperson) Organizational units (e.g., division, team) Places (e.g., manufacturing floor or loading dock) Structures (e.g., sensors, four-wheeled vehicles, or computers) But, how do we select classes?

53 Selecting Classes—Criteria needed services multiple attributes common attributes common operations essential requirements retained information

54 CRC Modeling See specific CRC slides

55 Rules of Thumb The model 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. Delay consideration of infrastructure and other non- functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be.

56 Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down!

57 Specification Guidelines

58 Specification Guidelines

59 Specification Guidelines