Chapter 8 Analysis Engineering (分析工程) Software Engineering: A Practitioner’s Approach by Roger S. Pressman Software Engineering: A Practitioner’s Approach.

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.
Chapter 8 Analysis Engineering Software Engineering: A Practitioner’s Approach by Roger S. Pressman.
System Sequence Diagrams (SSD). Recap Concepts of Action, Pins and Activity Description of activity nodes and activity edges New notations – Activity.
Software Requirements Engineering Elaboration Process Lecture-13.
Chapter 5 Understanding Requirements
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
1 SWE Introduction to Software Engineering Lecture 16 – System Modeling An Example.
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
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
Cardinality and Modality (ERD)
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. Class-Based Modeling Identify analysis classes by examining the problem statement Use a “grammatical parse” to isolate potential classes.
Chapter 8 Analysis Modeling
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
Architectural Design.
Computing and SE II Chapter 5: Requirements Analysis
Understanding Requirements. Requirements Engineering
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
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.
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.
Architectural Design Based on Chapter 11 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8t h Ed., Addison-Wesley, 2006 and on the Ch11 PowerPoint.
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
Analysis Modelling Approaches - Structured Analysis Considers data and the process that transforms the data into separate entities –Data objects Modelled.
Chapter 8 요구사항 이해 Understanding Requirements
CS /31 Illinois Institute of Technology CS487 Software Engineering OOA with UML David Lash.
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.
Class-based Modeling.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 24. Review ANALYSIS Level Class Diagram – Identifying Entities – Identifying Attributes – Identifying Operations.
1.  A customer walks into your office, sits down, looks you straight in the eye and says, “I know you think you understand what I said, but what you.
Object Oriented Analysis
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.
1 Chapter 5 Lecture 5: Understanding Requirements Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides.
Software Engineering OO Analysis (Object-Behaviour Models)
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 18 Analysis Modeling for WebApps Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
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. Recap Flow Based Modeling DFDs CFDs Processing narratives Class-based Model How to select classes? How to find attributes and.
Chapter 10 요구사항 모델링 : 클래스 기반 방법론 Requirements Modeling: Class-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for.
Software Requirements Engineering Elaboration Process Lecture-14.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Building analysis model  Analysis modeling uses a combination of text and diagrammatic forms to depict requirements for data function and behavior in.
Software Engineering Unit II : Requirement Engineering Requirement Engineering : Initiating the Process, Eliciting Requirements, Building the Requirements.
Architectural Complexity  A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components.
CS646: Software Design and Architectures Design methods: SSA/SD †  Stands for: Structured Systems Analysis / Structured Design.  Primary applicable notations:
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.
Software Engineering Object-Oriented Analysis (CRC Cards) James Gain
Chapter 8 Analysis Engineering
Elaboration Process Lecture-16.
Chapter 8 Building the Analysis Model (2) Analysis Modeling
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Object-Oriented Analysis
Chapter 9 Requirements Modeling: Scenario-Based Methods
Chapter 10 Requirements Modeling: Class-Based Methods
Presentation transcript:

Chapter 8 Analysis Engineering (分析工程) Software Engineering: A Practitioner’s Approach by Roger S. Pressman Software Engineering: A Practitioner’s Approach by Roger S. Pressman

Analysis Model Elements of the analysis model

Scenario-Based Modeling (基于场景的建模) docs/user-guide(en)/toc.html docs/user-guide(en)/toc.html Scenario-Based Modeling (基于场景的建模) docs/user-guide(en)/toc.html docs/user-guide(en)/toc.html

Use-case Diagram Use-case diagram for surveillance (监视) function

Alternative Actions Can the actor take some other action at this point? Is it possible that the actor will encounter some error condition at this point? Is it possible that the actor will encounter behavior invoked by some event outside the actor’s control? Can the actor take some other action at this point? Is it possible that the actor will encounter some error condition at this point? Is it possible that the actor will encounter behavior invoked by some event outside the actor’s control?

Activity diagram for Access camera surveillance— display camera views function

Swimlane diagram

Flow-Oriented Modeling (面向流的建模)

Guidelines Depict (描绘) the system as single bubble in level 0. Carefully note primary (主要的) input and output. Refine by isolating candidate (候选的) processes and their associated data objects and data stores. Label all elements with meaningful (有意义的) names. Maintain information conformity (一致性) between levels. Refine one bubble at a time. Depict (描绘) the system as single bubble in level 0. Carefully note primary (主要的) input and output. Refine by isolating candidate (候选的) processes and their associated data objects and data stores. Label all elements with meaningful (有意义的) names. Maintain information conformity (一致性) between levels. Refine one bubble at a time.

Data Flow Diagram Context-level DFD for SafeHome security function

Grammatical Parse The SafeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs. When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained. The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form … The SafeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs. When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained. The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form …

Level 2 DFD that refines the monitor sensors process

Control Flow Diagram State diagram for SafeHome security function

Class-Based Modeling (基于类的建模)

Identifying Analysis Classes External entities that produce or consume information Things that are part of the information domain Occurrences or events Roles played by people who interact with the system Organizational units Places that establish context Structures that define a class of objects External entities that produce or consume information Things that are part of the information domain Occurrences or events Roles played by people who interact with the system Organizational units Places that establish context Structures that define a class of objects

Class Selection Criteria 1.Retained (保留) information 2.Needed services (必须的服务) 3.Multiple attributes (多个属性) 4.Common attributes (公共属性) 5.Common operations (公共操作) 6.Essential requirements (必须的需求) 1.Retained (保留) information 2.Needed services (必须的服务) 3.Multiple attributes (多个属性) 4.Common attributes (公共属性) 5.Common operations (公共操作) 6.Essential requirements (必须的需求)

Identifying Classes Potential classClassificationAccept / Reject homeownerrole; external entityreject: 1, 2 fail sensorexternal entityaccept control panelexternal entityaccept installationoccurrencereject (security) systemthingaccept number, typenot objects, attributesreject: 3 fails master passwordthingreject: 3 fails telephone numberthingreject: 3 fails sensor eventoccurrenceaccept audible alarmexternal entityaccept: 1 fails monitoring serviceorganizational unit; eereject: 1, 2 fail

Class Diagram Class diagram for the system class

Class Diagram Class diagram for FloorPlan

CRC Modeling A CRC model index card for FloorPlan class

Class Responsibilities Distribute system intelligence across classes. (分散) State each responsibility as generally as possible. (普遍性) Put information and the behavior related to it in the same class. (封装) Localize information about one thing rather than distributing it across multiple classes. (内敛) Share responsibilities among related classes, when appropriate. (关联) Distribute system intelligence across classes. (分散) State each responsibility as generally as possible. (普遍性) Put information and the behavior related to it in the same class. (封装) Localize information about one thing rather than distributing it across multiple classes. (内敛) Share responsibilities among related classes, when appropriate. (关联)

Class Collaborations Relationships between classes: is-part-of (部分关系) — used when classes are part of an aggregate class. has-knowledge-of (知识关系) — used when one class must acquire information from another class. depends-on (依赖关系) — used in all other cases. Relationships between classes: is-part-of (部分关系) — used when classes are part of an aggregate class. has-knowledge-of (知识关系) — used when one class must acquire information from another class. depends-on (依赖关系) — used in all other cases.

Class Diagrams Top: Multiplicity Bottom: Dependencies

Behavioral Modeling (行为模型)

Identifying Events A use-case is examined for points of information exchange. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. A use-case is examined for points of information exchange. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

State Diagram State diagram for the ControlPanel class

Sequence Diagram Sequence diagram (partial) for the SafeHome security function