1 Chapter 18 Analysis Modeling for WebApps Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.

Slides:



Advertisements
Similar presentations
Unit Testing in the OO Context(Chapter 19-Roger P)
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Requirements Modeling Strategies
Chapter 19 Design Model for WebApps
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 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
1 R&D SDM 1 Software Project Management Requirements Analysis 2010 Theo Schouten.
Object-Oriented Analysis and Design
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.
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.
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 Concepts and Principles
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
© Copyright Eliyahu Brutman Programming Techniques Course.
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 Chapter 16 Web Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
USE Case Model.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Chapter 10 Architectural Design
Chapter 4 Requirements Engineering
1 Object-Oriented Testing CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
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.
An Introduction to Software Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
3231 Software Engineering By Germaine Cheung Hong Kong Computer Institute Lecture 12.
Web Engineering Web engineering is the process used to create high quality WebApps. Web engineering is not a perfect clone of software engineering. But.
Organizing the Requirements Information 1. Need for Organizing Requirements  Many stakeholders are involved in most projects.  They must reach agreement.
High-Level Design With Sequence Diagrams COMP314 (based on original slides by Mark Hall)
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.
Chapter 13 Architectural Design
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Developed by Reneta Barneva, SUNY Fredonia for CSIT 425 Requirements Modeling.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
3231 Software Engineering By Germaine Cheung Hong Kong Computer Institute Lecture 11.
1 Structuring Systems Requirements Use Case Description and Diagrams.
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.
CMPS 435 F08 These slides are designed to accompany Web Engineering: A Practitioner’s Approach (McGraw-Hill 2008) by Roger Pressman and David Lowe, copyright.
CMPS 435 F08 These slides are designed to accompany Web Engineering: A Practitioner’s Approach (McGraw-Hill 2008) 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.
Analysis Modeling CpSc 372: Introduction to Software Engineering
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
Chapter 10 요구사항 모델링 : 클래스 기반 방법론 Requirements Modeling: Class-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for.
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 Web Engineering “Web development is an adolescent … Like most adolescents, it wants to be accepted as an adult as it tries to pull away from its parents.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
Chapter 8 Analysis Engineering
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
UML Modeling Sequence diagram
Unified Modeling Language
Requirements Modeling: Flow, Behavior, Patterns, and WebApps
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Object-Oriented Analysis
Chapter 9 Requirements Modeling: Scenario-Based Methods
Chapter 11 Requirements Modeling: Behavior, Patterns, and Web/Mobile Apps Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e by.
Chapter 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApps
More Requirements Models
CIS 376 Bruce R. Maxim UM-Dearborn
Presentation transcript:

1 Chapter 18 Analysis Modeling for WebApps Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman

2 Analysis  Content Analysis. The full spectrum of content to be provided by the WebApp is identified, including text, graphics and images, video, and audio data. Data modeling can be used to identify and describe each of the data objects.  Interaction Analysis. The manner in which the user interacts with the WebApp is described in detail. Use-cases can be developed to provide detailed descriptions of this interaction.  Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis define the operations that will be applied to WebApp content and imply other processing functions. All operations and functions are described in detail.  Configuration Analysis. The environment and infrastructure in which the WebApp resides are described in detail.  Content Analysis. The full spectrum of content to be provided by the WebApp is identified, including text, graphics and images, video, and audio data. Data modeling can be used to identify and describe each of the data objects.  Interaction Analysis. The manner in which the user interacts with the WebApp is described in detail. Use-cases can be developed to provide detailed descriptions of this interaction.  Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis define the operations that will be applied to WebApp content and imply other processing functions. All operations and functions are described in detail.  Configuration Analysis. The environment and infrastructure in which the WebApp resides are described in detail.

3 When Do We Perform Analysis?  In some WebE situations, analysis and design merge. However, an explicit analysis activity occurs when …  the WebApp to be built is large and/or complex  the number of stakeholders is large  the number of Web engineers and other contributors is large  the goals and objectives (determined during formulation) for the WebApp will effect the business’ bottom line  the success of the WebApp will have a strong bearing on the success of the business  In some WebE situations, analysis and design merge. However, an explicit analysis activity occurs when …  the WebApp to be built is large and/or complex  the number of stakeholders is large  the number of Web engineers and other contributors is large  the goals and objectives (determined during formulation) for the WebApp will effect the business’ bottom line  the success of the WebApp will have a strong bearing on the success of the business

4 The User Hierarchy

5 Use-Case Diagram

6 Refining the Use-Case Model  Use-cases are organized into functional packages  Each package is assessed [CON00] to ensure that it is:  Comprehensible—all stakeholders understand the purpose of the package  Cohesive—the package addresses functions that are closely related to one another  Loosely coupled—functions or classes within the package collaborate with one another, but collaboration outside the package are kept to a minimum.  Hierarchically shallow—deep functional hierarchies are difficult to navigate and hard for end-users to understand; therefore, the number of levels within a use-case hierarchy should be minimized whenever possible.  Use-cases are organized into functional packages  Each package is assessed [CON00] to ensure that it is:  Comprehensible—all stakeholders understand the purpose of the package  Cohesive—the package addresses functions that are closely related to one another  Loosely coupled—functions or classes within the package collaborate with one another, but collaboration outside the package are kept to a minimum.  Hierarchically shallow—deep functional hierarchies are difficult to navigate and hard for end-users to understand; therefore, the number of levels within a use-case hierarchy should be minimized whenever possible.

7 The Content Model  Content objects are extracted from use-cases  examine the scenario description for direct and indirect references to content  Attributes of each content object are identified  The relationships among content objects and/or the hierarchy of content maintained by a WebApp  Relationships—entity-relationship diagram or UML  Hierarchy—data tree or UML  Content objects are extracted from use-cases  examine the scenario description for direct and indirect references to content  Attributes of each content object are identified  The relationships among content objects and/or the hierarchy of content maintained by a WebApp  Relationships—entity-relationship diagram or UML  Hierarchy—data tree or UML

8 Data Tree

9 Analysis Classes  Analysis classes are derived by examining each use-case  A grammatical parse is used to identify candidate classes  A UML class diagram is developed for each analysis class  Analysis classes are derived by examining each use-case  A grammatical parse is used to identify candidate classes  A UML class diagram is developed for each analysis class

10 Analysis Class Example

11 The Interaction Model  Composed of four elements:  use-cases  sequence diagrams  state diagrams  a user interface prototype  Each of these is an important UML notation  Composed of four elements:  use-cases  sequence diagrams  state diagrams  a user interface prototype  Each of these is an important UML notation

12 Sequence Diagram

13 State Diagram

14 The Functional Model  The functional model addresses two processing elements of the WebApp  user observable functionality that is delivered by the WebApp to end-users  the operations contained within analysis classes that implement behaviors associated with the class.  An activity diagram can be used to represent processing flow  The functional model addresses two processing elements of the WebApp  user observable functionality that is delivered by the WebApp to end-users  the operations contained within analysis classes that implement behaviors associated with the class.  An activity diagram can be used to represent processing flow

15 Activity Diagram

16 The Configuration Model  Server-side  Server hardware and operating system environment must be specified  Interoperability considerations on the server-side must be considered  Appropriate interfaces, communication protocols and related collaborative information must be specified  Client-side  Browser configuration issues must be identified  Testing requirements should be defined  Server-side  Server hardware and operating system environment must be specified  Interoperability considerations on the server-side must be considered  Appropriate interfaces, communication protocols and related collaborative information must be specified  Client-side  Browser configuration issues must be identified  Testing requirements should be defined

17 Relationship-Navigation Analysis  Relationship-navigation analysis (RNA) identifies relationships among the elements uncovered as part of the creation of the analysis model  Steps:  Stakeholder analysis—identifies the various user categories and establishes an appropriate stakeholder hierarchy  Element analysis—identifies the content objects and functional elements that are of interest to end users  Relationship analysis—describes the relationships that exist among the WebApp elements  Navigation analysis—examines how users might access individual elements or groups of elements  Evaluation analysis—considers pragmatic issues (e.g., cost/benefit) associated with implementing the relationships defined earlier  Relationship-navigation analysis (RNA) identifies relationships among the elements uncovered as part of the creation of the analysis model  Steps:  Stakeholder analysis—identifies the various user categories and establishes an appropriate stakeholder hierarchy  Element analysis—identifies the content objects and functional elements that are of interest to end users  Relationship analysis—describes the relationships that exist among the WebApp elements  Navigation analysis—examines how users might access individual elements or groups of elements  Evaluation analysis—considers pragmatic issues (e.g., cost/benefit) associated with implementing the relationships defined earlier

18 Navigation Analysis-I  Should certain elements be easier to reach (require fewer navigation steps) than others? What is the priority for presentation?  Should certain elements be emphasized to force users to navigate in their direction?  How should navigation errors be handled?  Should navigation to related groups of elements be given priority over navigation to a specific element.  Should navigation be accomplished via links, via search-based access, or by some other means?  Should certain elements be presented to users based on the context of previous navigation actions?  Should a navigation log be maintained for users?  Should certain elements be easier to reach (require fewer navigation steps) than others? What is the priority for presentation?  Should certain elements be emphasized to force users to navigate in their direction?  How should navigation errors be handled?  Should navigation to related groups of elements be given priority over navigation to a specific element.  Should navigation be accomplished via links, via search-based access, or by some other means?  Should certain elements be presented to users based on the context of previous navigation actions?  Should a navigation log be maintained for users?

19 Navigation Analysis-II  Should a full navigation map or menu (as opposed to a single “back” link or directed pointer) be available at every point in a user’s interaction?  Should navigation design be driven by the most commonly expected user behaviors or by the perceived importance of the defined WebApp elements?  Can a user “store” his previous navigation through the WebApp to expedite future usage?  For which user category should optimal navigation be designed?  How should links external to the WebApp be handled? overlaying the existing browser window? as a new browser window? as a separate frame?  Should a full navigation map or menu (as opposed to a single “back” link or directed pointer) be available at every point in a user’s interaction?  Should navigation design be driven by the most commonly expected user behaviors or by the perceived importance of the defined WebApp elements?  Can a user “store” his previous navigation through the WebApp to expedite future usage?  For which user category should optimal navigation be designed?  How should links external to the WebApp be handled? overlaying the existing browser window? as a new browser window? as a separate frame?