© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

Slides:



Advertisements
Similar presentations
Systems Analysis and Design, 7e Kendall & Kendall
Advertisements

Appendix Object-Oriented Analysis and Design: Use Cases Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Chapter 4 Enterprise Modeling.
Object-Oriented Analysis and Design
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Systems Analysis and Design 9th Edition
© 2005 Prentice Hall6-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Chapter 18 Object-Oriented Systems Analysis and Design Using UML
© 2005 Prentice Hall7-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Systems Analysis and Design in a Changing World, Fourth Edition
Process Modeling Chapter 6. Key Definitions A process model is a formal way of representing how a business operates Data flow diagramming shows business.
© 2005 Prentice Hall12-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Systems Analysis & Design Sixth Edition Systems Analysis & Design Sixth Edition Toolkit Part 5.
Use Case Modeling.
Chapter 4.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Chapter 7: The Object-Oriented Approach to Requirements
Traditional Approach to Requirements Data Flow Diagram (DFD)
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
USE Case Model.
Chapter 5: Modeling Systems Requirements: Events and Things
Modeling Systems Requirements: Events and Things.
Systems Analysis and Design in a Changing World, Fifth Edition
Modeling System Requirements:Events and Things
Chapter 6 The Traditional Approach to Requirements
CMIS 470 Structured Systems Design
Systems Analysis and Design in a Changing World, Fifth Edition
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 3 Use Cases.
Phase 2: Systems Analysis
5 Systems Analysis and Design in a Changing World, Fourth Edition.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 7 Appendix A Object-Oriented Analysis and Design: Use Cases Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George.
© 2005 Prentice Hall9-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
1 6 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 6 The Traditional Approach to Requirements.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
5 Systems Analysis and Design in a Changing World, Fifth Edition.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 3 Use Cases.
Drawing System Sequence Diagrams
Chapter 7 The Object-Oriented Approach to Requirements.
COMP-350 Object-Oriented Analysis and Design Drawing System Sequence Diagrams Reference: Larman, Chapter 9.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
1 Chapter 5 Modeling System Requirements Finding the Use Cases Page
System sequence diagrams
Chapter 4 enterprise modeling
Software Engineering Software Engineering - Mr. Ahmad Al-Ghoul.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 5 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN: AN AGILE, ITERATIVE APPROACH CHAPTER.
© 2005 Prentice Hall1-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Systems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design 8th Edition
Software Engineering Issues Software Engineering Concepts System Specifications Procedural Design Object-Oriented Design System Testing.
Systems Analysis and Design 8th Edition
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Appendix Object-Oriented Analysis and Design: Use Cases and Sequence Diagrams Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
Application Analysis. Application Interaction Model The purpose of analysis is to understand the problem so.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
 Sequence Diagrams Introduction.  Sequence Diagrams  Review Schedule Sheridan.
Systems Analysis and Design in a Changing World, Fourth Edition
System sequence diagrams
Requirements: Use Case Models and Narratives
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Presentation transcript:

© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

© 2005 Prentice Hall3-2 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

© 2005 Prentice Hall3-3 Learning Objectives State and discuss the goals of systems analysis. Characterize a statement of system requirements as well as the process of systems analysis. Define the term event and understand the implications of this definition.

© 2005 Prentice Hall3-4 Learning Objectives (continued) Explain the difference between a temporal event and an external event. Give appropriate names to events and recognize whether or not an event is named appropriately. Carry out a business event analysis for a system and present the results in an event table.

© 2005 Prentice Hall3-5 Overview The principal goal of information systems analysis is to state accurately users’ requirements for a new information processing system. Chapter 3 introduces a six-step process for object-oriented analysis. Together, these six steps produce an event model, a use case model, system sequence diagrams, a model of the problem domain, and system operation contracts.

© 2005 Prentice Hall3-6 Overview (continued) The initial step is business event analysis, which results in an event model, presented as an event table. Event analysis treats the system as a black box and views it from a stimulus-response perspective.

© 2005 Prentice Hall3-7 Overview (continued) An event is an occurrence which takes place at a specific time and triggers a predetermined response from the system. Because events occur independently of each other, event analysis is a powerful technique for breaking up a large or complex system into small, manageable, cohesive, independent parts.

© 2005 Prentice Hall3-8 Overview (continued) Event analysis identifies the events to which the system is expected to respond, names the inputs and outputs, and identifies the actors – those who interact with the system by providing inputs and receiving outputs.

© 2005 Prentice Hall3-9 Goals of Systems Analysis Primary Goal: To state accurately the users’ requirements for a new information processing system.

© 2005 Prentice Hall3-10 Goals of Systems Analysis (continued) Secondary Goals: 1.To understand the users’ requirements. 2.To communicate the current understanding of the proposed system. 3.To prevent expensive mistakes 4.To state a design problem. 5.To state the conditions for system acceptance.

© 2005 Prentice Hall3-11 Characteristics of a Statement of System Requirements Graphic: Uses diagrams Partitioned: Organizes the system description into comprehensible parts Non-redundant: A change can be made in a single place Accurate: Rigorous, precise, clear, consistent, and complete Minimal: Eliminates non-essentials, while including all critical details

© 2005 Prentice Hall3-12 Procedure for Object-Oriented Systems Analysis Step 1. Identify the business events and make an event table. Step 2. Identify the use cases and produce a use case diagram for the system. Step 3. Write a use case narrative describing the system’s response to each business event.

© 2005 Prentice Hall3-13 Procedure for Object-Oriented Systems Analysis (continued) Step 4. Draw a system sequence diagram for each use case scenario. Step 5. Produce a domain model showing the concepts, attributes, and associations in the problem domain of the system. Step 6. Write a contract for each system operation.

© 2005 Prentice Hall3-14 Models for Object-Oriented Systems Analysis.

© 2005 Prentice Hall3-15 Typical Models – Event List Event list for the university registration system

© 2005 Prentice Hall3-16 Typical Models – Use Case Diagram

© 2005 Prentice Hall3-17 Typical Models – Use Case Narrative.

© 2005 Prentice Hall3-18 Typical Models – System Sequence Diagram

© 2005 Prentice Hall3-19 Typical Models – Domain Model

© 2005 Prentice Hall3-20 Typical Models – System Operation Contract

© 2005 Prentice Hall3-21 Event-Driven Systems Event analysis takes a stimulus-response perspective: The system does nothing until it is triggered by an event. When an event occurs, the system responds as completely as possible. After the response is complete, the system waits until another event occurs.

© 2005 Prentice Hall3-22 Events An event is an occurrence which takes place at a specific time and initiates or triggers a predetermined response from the system. An external event is an event which occurs outside the system boundary. An internal event is an event which occurs inside the system boundary. A temporal event is an event which occurs at a prespecified time.

© 2005 Prentice Hall3-23 Event Analysis Event analysis creates a system description by identifying: 1.The events to which the system is expected to respond 2.The incoming message (event flow or data flow) associated with each event 3.The desired response 4.The actions or behaviors required to generate the response for each stimulus

© 2005 Prentice Hall3-24 Event Analysis (continued) (Insert Figure 3.4)

© 2005 Prentice Hall3-25 Identify the Business Events Event List for the Public University Registration System External1. Department submits class schedule Temporal2. Time to produce university class schedule External 3. Student registers for classes Temporal 4. Time to produce class roster

© 2005 Prentice Hall3-26 Identify the Actors, Inputs, and Outputs Who supplies system inputs? Department submits a Department Class Schedule. Student supplies a list of desired classes (a Registration Request).

© 2005 Prentice Hall3-27 Identify the Actors, Inputs, and Outputs (continued) Who receives system outputs? Departments, Professors, and Students receive the University Class Schedule. Student receives a Class List. Professors receive Class Rosters.

© 2005 Prentice Hall3-28 Event Table.

© 2005 Prentice Hall3-29 Hints About Event Analysis Ignore the technology of implementation – build an essential event model. Model the system’s complete response – don’t split a single event into fragments. Isolate individual events – don’t combine events if the system must wait in between them.

© 2005 Prentice Hall3-30 Summary The goal of systems analysis is to state users’ requirements for a new information system correctly. The initial step in object-oriented systems analysis is event analysis. Event analysis identifies external and temporal events and the system’s expected responses.