1 / 20

Requirements Analysis Visual Modeling] Lab 02

Requirements Analysis Visual Modeling] Lab 02. Visual Modeling (from Visual Modeling with Rational Rose and UML). A way of thinking about problems using models organized around real-world ideas We can visualize them in our head

dtaylor
Télécharger la présentation

Requirements Analysis Visual Modeling] Lab 02

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Analysis Visual Modeling] Lab 02

  2. Visual Modeling(from Visual Modeling with Rational Rose and UML) • A way of thinking about problems using models organized around real-world ideas • We can visualize them in our head • To promote a better understanding of requirements, cleaner designs, and more maintainable systems • We build models because we cannot comprehend such systems in their entirety • Focus on the big picture of how a project’s components interact • Without getting bogged down in the specific details of each component

  3. The Triangle for Success Notation: Unified Modeling Language (UML) Process Rational Objectory Process Tool: Rational Rose

  4. INTRODUCTION TO UML

  5. The Value of the UML • Is an open standard • Supports the entire software development lifecycle • Supports diverse applications areas • Is based on experience and needs of the user community • Supported by many tools

  6. What is the UML? • The UML is a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system • Process and implementation independent • It can be used with a large number of processes, throughout the development life cycle, and across OO implementation technologies • The UML combines • Data Modeling concepts (Entity Relationship Diagrams) • Business Modeling (work flow) • Object Modeling • Component Modeling • The standard for OO systems

  7. The UML Usages • Define the boundaries of a system & its major functions • use cases and actors • Illustrate use cases • interaction diagrams • Define the static structure of a system • class diagrams • Model the behavior of objects • state transition diagrams • Document the physical implementation architecture • component & deployment diagrams • Provide for growth • stereotypes

  8. DiagramsThe foundation of UML • Use Case Diagrams • Requirements • Activity Diagrams • Generally what, not who - good to detect parallelism • Interaction Diagrams • Sequence Diagrams (timeline) • Collaboration Diagrams (object centered) • Static Structure Diagrams • Objects/Classes/Packages • State Chart Diagrams • States of objects with interesting lifecycles • Implementation Diagrams • Component Diagrams • Deployment Diagrams

  9. Use case Model

  10. External System Behavior: Use Case Model • Complete course of events in the system, from the user’sperspective • Use Cases Model: Illustrates • (use cases) the system’s intended functions • (actors) surroundings – external to the system • (use case diagrams) relationships between use cases and actors • Use Case Model is an important communication vehicle between customers (they can understand it!) and developers • The collection of all use cases is everything that can be done to/with the system

  11. Actors • Are NOT part of the system – they represent anyone or anything that must interact with the system • Only input information to the system • Only receive information from the system • Both input to and receive information from the system • Represented in UML as a stickman

  12. Questions to Discover Actors? • Who is interested in a certain requirement? • Where in the organization is the system used? • Who will benefit from the use of the system? • Who will supply the system with this information, use this information, and remove this information? • Who will support and maintain the system? • Does the system use an external resource? • Does one person play several different roles? • Does several people play the same role? • Does the system interact with the legacy system?

  13. A Case Study: Eastern State University (ESU) Registration Problem: Background • After professors decide which courses they will teach, the Registrar enters in info in the computer • A course catalog is printed and distributed to students • Students fill out form with their choices – usually 4 courses • Registrar enters this info into computer • A batch job is run overnight to assign students to courses • In cases of conflict where the students cannot take the classes they had selected, the registrar contacts the students directly to obtain additional choices. • Once all students have successfully assigned to courses, a hardcopy of the schedule is sent to the student. • Professors obtain student rosters for their classes.

  14. Eastern State University (ESU) Registration Problem: Problem Statement • Professors indicate which courses they will teach on-line. • A course catalog is printed • Allow students to select on-line four courses (and two additional choices) for upcoming semester. • No course may have more than 10 students or less than 3 students. • When the registration is completed, the system sends information to the billing system. • Professors can obtain course rosters on-line. • Students can add or drop classes on-line.

  15. Who are the Actors? • Students • Professors • Registrar • Billing System

  16. Use Case • A sequence of transactions performed by a system that yields a measurable result of values for a particular actor • What are the tasks of each actor? • Will any actor create, store, change, remove or read information in the system? • What use cases will create, store, change, remove or read this information? • Will any actor need to inform the system about sudden, external changes? • Does any actor need to be informed about certain occurrences in the system? • What use cases will support and maintain the system? • Can all functional requirements be preformed by the use cases? • A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor.

  17. What are the Main Use Cases • Register for courses • Select Courses to Teach • Request course roster • Maintain course information • Maintain professor information • Maintain student information • Create course catalog

  18. Use Case Relationships • Between Actor and Use Case • Association / Communication • Arrow can be in either or both directions • Arrow indicates who initiates communication

  19. Use Case Relationships • Between Use Cases (Generalization): • Uses • Where multiple use cases sharepieces of same functionality • Extends • Optional behavior • Behavior only run under certainconditions (such as alarm) • Several different flows run base onuser selection

  20. Main Use Case Diagram

More Related