Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.

Slides:



Advertisements
Similar presentations
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Advertisements

Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Analysis and Design with UML
2008/03/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Object-Oriented Analysis and Design
Introduction To System Analysis and Design
Use-case Modeling.
Software Engineering Recitation 3 Suhit Gupta. Review CVS problems XML problems – XML/XSD/DTD/SCHEMAS.
Documenting Requirements using Use Case Diagrams
CREATING THE DESIGN: THE LOGICAL VIEW The Class Diagram.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
© Copyright Eliyahu Brutman Programming Techniques Course.
1 Business Models Modeling. 2 Why Model the Business Business modeling is a technique to help answer critical questions, such as: What do the workers.
Page 1 R Copyright © 1997 by Rational Software Corporation Analysis and Design with UML.
Unified Modeling Language
2005/05/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Page 1 What is the UML? UML stands for Unified Modeling Language The UML combines the best of the best from – Data Modeling concepts (Entity Relationship.
CS4510: Software Engineering Laurie Williams Graduate Student.
Use Case modelling 1. Objectives  Document user requirements with a model  Describe the purpose of an actor and a use case  Construct a use case model.
Prepared by Afra`a Sayah. Introduction. Weekly Tasks. Plane Phase. Analysis Phase. Design Phase. Report Rules. Conclusion. 2.
1 SYS366 Lecture Visual Modeling and Business Use Case Diagrams.
Lecture 3: Visual Modeling & UML 1. 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship via “ Modeling.
Introduction To System Analysis and Design
Solid Palette Gradient Palette I Gradient Palette II APPLYING THESE COLORS Click on the desired color Click on the paintbrush tool located.
Page 1  Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship via “ Modeling captures essential parts of.
Page 1 R Copyright © 1998 by Rational Software Corporation Visual Modeling and the UML.
Faculty of Computer & Information Software Engineering Third year
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
System Analysis System Analysis - Mr. Ahmad Al-Ghoul System Analysis and Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
COP43311 Copyright © 1997 by Rational Software Corporation Unified Modeling Language (UML) Based on slides and papers from Rational’s UML website
Use Case Model Use case diagram.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
1 The Unified Modeling Language. 2 The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
1/26 On-demand Learning Series Software Engineering of Web Application - Object-Oriented Development & UML Hunan University, Software School.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
Page 1 R Copyright © 1997 by Rational Software Corporation Analysis and Design with UML Presentation was downloaded (and is available for free) from Rational.
Essentials of Visual Modeling w/ UML Instructor Notes
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
UML (Unified Modeling Language)
UML - Development Process 1 Software Development Process Using UML.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
Fall 2007 Week 9: UML Overview MSIS 670: Object-Oriented Software Engineering.
1 BTS330 Visual Modeling. What is Visual Modeling? 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship.
1 SYS366 Week 2 - Lecture 2 Visual Modeling & UML.
Page 1  Copyright © 1997 by Rational Software Corporation Putting the UML to Work The ESU University wants to computerize their registration system –
1 IS 0020 Program Design and Software Tools Unified Modeling Language Lecture 13 April 13, 2005.
1 IS 0020 Program Design and Software Tools Unified Modeling Language Lecture 13 November 30, 2004.
Object-Oriented Analysis and Design
Unified Modeling Language
Business Models Modeling.
Use Case Model Use case diagram.
The Unified Modeling Language
Unified Modeling Language
Software Design Lecture : 15.
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Presentation transcript:

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 A way of thinking about problems using models organized around real-world ideas We can visualize them in our head We can visualize them in our head To promote a better understanding of requirements, cleaner designs, and more maintainable systems 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 We build models because we cannot comprehend such systems in their entirety Focus on the big picture of how a project’s components interact Focus on the big picture of how a project’s components interact Without getting bogged down in the specific details of each component Without getting bogged down in the specific details of each component

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

INTRODUCTION TO UML

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

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

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

Diagrams The 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

Use case Model

External System Behavior: Use Case Model Complete course of events in the system, from the user’s perspective Complete course of events in the system, from the user’s perspective Use Cases Model: Illustrates Use Cases Model: Illustrates (use cases) the system’s intended functions (use cases) the system’s intended functions (actors) surroundings – external to the system (actors) surroundings – external to the system (use case diagrams) relationships between use cases and actors (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 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

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

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

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 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 A course catalog is printed and distributed to students Students fill out form with their choices – usually 4 courses Students fill out form with their choices – usually 4 courses Registrar enters this info into computer Registrar enters this info into computer A batch job is run overnight to assign students to courses 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. 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. 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. Professors obtain student rosters for their classes.

Eastern State University (ESU) Registration Problem: Problem Statement Professors indicate which courses they will teach on- line. Professors indicate which courses they will teach on- line. A course catalog is printed A course catalog is printed Allow students to select on-line four courses (and two additional choices) for upcoming semester. 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. 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. When the registration is completed, the system sends information to the billing system. Professors can obtain course rosters on-line. Professors can obtain course rosters on-line. Students can add or drop classes on-line. Students can add or drop classes on-line.

Who are the Actors? Students Students Professors Professors Registrar Registrar Billing System Billing System

Use Case A sequence of transactions performed by a system that yields a measurable result of values for a particular actor 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? What are the tasks of each actor? Will any actor create, store, change, remove or read information in the system? 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? What use cases will create, store, change, remove or read this information? Will any actor need to inform the system about sudden, external changes? 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? Does any actor need to be informed about certain occurrences in the system? What use cases will support and maintain the system? What use cases will support and maintain the system? Can all functional requirements be preformed by the use cases? 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. 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.

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

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

Between Use Cases (Generalization): Between Use Cases (Generalization): Uses Uses Where multiple use cases share pieces of same functionality Where multiple use cases share pieces of same functionality Extends Extends Optional behavior Optional behavior Behavior only run under certain conditions (such as alarm) Behavior only run under certain conditions (such as alarm) Several different flows run base on user selection Several different flows run base on user selection Use Case Relationships

Main Use Case Diagram