UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie

UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie
Reproduction of these notes requires prior consent of the author. © Dr. Maria M. Larrondo Petrie, 2001

Objectives To become familiar with the Unified Modeling Language (UML) notation To create UML diagrams To review and critique UML models To use the Rational Unified Process to do object-oriented software development To use Rational Rose as a tool to develop UML documents, models, diagrams © Dr. Maria M. Larrondo Petrie, 2001

Requirements Introductory knowledge of object-oriented terminology and concepts Have used some techniques for finding classes, attributes, and associations (e.g., CRC, Shlaer-Mellor, Coad-Yourdon) © Dr. Maria M. Larrondo Petrie, 2001

Organization Introduction Unified Modeling Language
Requirements Gatherings Approaches Traditional Deliverables Unified Modeling Language Rational Unified Process 4+1 Architectural Views and their Deliverables Use Case Model Logical View Process View Deployment View Implementation View (Component View in Rose) Using Rational Rose Case Study and Exercises © Dr. Maria M. Larrondo Petrie, 2001

Introduction Requirements Gatherings Traditional Deliverables
Goals and Challenges Standard Approaches Example Requirements List Documenting Operational Requirements Traditional Deliverables Requirements Specification Documents Analysis Diagrams: Context Diagram, Entity Relationship Diagram, Data/Control Flow Diagram Prototype © Dr. Maria M. Larrondo Petrie, 2001

Requirements Gathering
© Dr. Maria M. Larrondo Petrie, 2001

Goals of Requirements Gathering
Find out what the users need Document needs in a Requirements Specification Avoid premature design assumptions Resolve conflicting requirements Clarify ambiguous requirements Eliminate redundant requirements Discover incomplete or missing requirements Separate functional from nonfunctional requirements Ensure Requirements Traceability © Dr. Maria M. Larrondo Petrie, 2001

Requirement Specifications seldom clearly capture customer needs
What user wanted How customer described it How analyst specified it How designer implemented it © Dr. Maria M. Larrondo Petrie, 2001

Challenges in Requirements Gathering
Consider a scenario illustrating the normal state of flux: Often you are using new business procedures, and your job has changed to head development of a brand new application your company has announced, and you are scheduling training for you and your team to master a new computer environment and new software development techniques and new tools using a new programming language, how do you figure out and document how the new application is supposed to work in a way that is clearly understood by: end users, analysts, training staff customers, designers, support staff marketing staff, implementers, maintenance staff, managers, testers, ? © Dr. Maria M. Larrondo Petrie, 2001

Standard Approaches for Requirements Gathering
Elicit requirements through user interviews Gathering representatives of stakeholders: * executives developers maintenance users support staff ... in one room at during uninterrupted session(s) to decide on requirements under an experienced leader/consensus maker: Joint requirements planning (JRP) focus on what the system will do Joint application design (JAD) focus on how the system will work produce a document which includes a list of requirements Developing a Rapid Prototype © Dr. Maria M. Larrondo Petrie, 2001

Example Requirements List 1 (1 of 3)
Table of Requirements with review comments by Kulak & Guiney1 1 Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context, Addison-Wesley, New York, NY, 2000. Requirement Kulak and Guiney Comments The system will support client inquiries from 4 access points: in person, paper-based mail, voice communication, and electronic communication (Internet, dial-up, and LAN/WAN Four access points are how; we should focus on who needs access and from where The telephone system must be able to support an 800 number system Can't use 888 or 877? Missing who needs what kind of access from where The telephone system must be able to handle 97,000 calls/yr. and must allow for a 15% annual growth. It is estimated that 19% of these calls will be responded to in an automated manner and 81% will be routed to call center staff for response. 50% of calls can be processed without reference to the electronic copy of the paper file, and approximately 50% will require access to system files. Valuable statistics. This requirement is actually pretty good. For the calls that require access to system information, response times for the electronic files must be less than 20 seconds for the first image located on the optical disk, less than 3 seconds for electronic images on a server, and less than 1 second for data files. "optical disk" is a design assumption. Response times are good non-functional requirements if not linked to design assumptions (hardware device types). [KG00p16-18] © Dr. Maria M. Larrondo Petrie, 2001

Table of Requirements with review comments by Kulak & Guiney Requirement Kulak and Guiney Comments The telephone system must be able to support voice recognition of menu selections, touch-tone menu selections, and default to a human operator. The telephone menu will sequence caller choices in order of most frequently requested information to the least requested Pretty good one. Can you find anything wrong? The telephone system must be able to provide a voice response menu going from a general menu to a secondary menu. This seems to be trying to provide some pretty obvious advice to a dumb designer The system must allow for the caller to provide address information through a digital recording and to indicate whether it is permanent. "Through a digital recording"? This is a design assumption The system must allow for the caller to provide address information through voice recognition and to indicate whether it is permanent. Sound familiar? (It's redundant) The telephone system must be able to store and maintain processor IDs and personal identification numbers to identify callers and to route calls properly to the appropriate internal response telephone. Simplify it: "The system must be able to identify callers and route calls to the appropriate internal response telephone". The telephone system must be able to inform callers of the anticipated wait time based on the number of calls, average duration of calls, and the number of calls ahead of them. Great! [KG00p16-18] © Dr. Maria M. Larrondo Petrie, 2001

Table of Requirements with review comments by Kulak & Guiney Note: Each requirement should have a number to provide traceability. Requirement Kulak and Guiney Comments The journal will contain entries for key events that have occurred within the administration of an individual's account. The system will capture date, processor ID, and key event description. The system will store pointers to images that are associated with a journal entry as well as key data system screens that contain more information regarding the entry. This is a design for a journal. Why have it? What is its purpose? If an individual double-clicks on an event in a member's journal, the system will display the electronic information and the images associated with the event. Double-click is a user interface design assumption The system will restrict options on the information bar by processor function. When an icon is clicked, the screen represented by the icon will be displayed and the system will display appropriate participant information. This one has many user interface design assumptions. [KG00p16-18] © Dr. Maria M. Larrondo Petrie, 2001

Table of Requirements with review comments by Kulak & Guiney Requirement Kulak and Guiney Comments The system must provide the capability to capture all of the customer transactions for fiscal year Too vague. Implies fiscal year has some impact on how customer transactions are organized, but does not specify what that is. Implies some data entry, but needs to be stated more specifically. May be trying to make a statement about volume, meaning old transactions can't be archived until they are a year old? The system will provide restricted remote inquiry access (via dial-in) to view images and data separately or simultaneously Saying "restricted" is OK, but details about the restriction (who can, who can't) should be stated clearly in this context. Also vague is the reference to remote inquiry. How remote? Saying "remote access" when referring to mobile employees working in the field but still within a couple of miles of the office or worldwide access. Can have huge implications on system. The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned Makes several technical design assumptions. Barcoding is a solution, not a requirement. This system probably needs a way to identify each document uniquely, but it doesn't have to be barcodes. If all existing systems use document barcoding (not the case with this system), should write a nonfunctional requirements that states, "Unique identification of all documents will be done through barcoding". By specifying barcoding in the functional specifications, changing to glyphs, optical character recognition (OCR) will be more difficult. The reference to queues makes an assumption about a workflow-package-oriented system. Better to state: "At a minimum, the unique id will ensure routing to a specific worker in the organization when documents are returned." [KG00p3-7] © Dr. Maria M. Larrondo Petrie, 2001

Table of Requirements with review comments by Kulak & Guiney Requirement Kulak and Guiney Comments When a workflow is initiated, the system must be able to prefetch the documents that are in electronic image format by document type or grouping of documents by process Look at references to workflow. Requirements document has specified a workflow solution! This whole entry is suspicious. Seems to be saying that we must cache documents by two different criteria: by type or by process. Criteria are good requirements, but caching(prefetching) is a solution to address performance problems. The system must create an entry in the journal file whenever a letter is created Assumes presence of a journal file containing entries inserted when a letter is created. Seems focused on front end ("do this") instead of back end ("in order to get this"). Why put entries in a journal file? To create a list of all letters created, when and by whom? This would make a better, clearer requirement. System must maintain list of current, open work processes and identify work process to be executed and workflow queue for process. When documents are scanned, system determines whether there is a process open for that SSN. If there is, the system routes document to appropriate workflow queue, displays work process script, and highlight current work process. Seems to be focused on how rather than what. Instead of specifying the steps a system must go through, clearly document the end in mind. Example: "When a new document image is brought into the system, it should be routed to the worker who has the account open for the same SSN as the new document and should be made obvious to that worker. If no worker has an open account, the document should be made available to any worker." [KG00p3-7] © Dr. Maria M. Larrondo Petrie, 2001

Eliciting Operational Requirements
Problems with traditional ways of specifying problems: 1. customer may not adequately convey the needs of the user. 2. developer may not be an expert in the application domain, which inhibits communications. 3. users and customers may not understand the requirements produced by the developer developer's requirements specifications typically specifies system attributes such as functions, • performance factors, design constraints, • system interfaces and quality attributes, but typically contains little or no information concerning operational characteristics of the specified system. [FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA, 1997. © Dr. Maria M. Larrondo Petrie, 2001

Guidelines for Operational Concept Document
Operational Concept Document (OCD) describes the mission of the system, its operational and support environments, and the functions and characteristics of the computer system within an overall system. Several guidelines and standards exist to prepare an OCD: • Mil-Std 498 for Department of Defense SW development • IEEE Standard 1498 for commercial SW development, • AIAA OCD 1992 for the American Inst. of Aeronautics and Astronautics (for embedded real-time systems) • ConOps 1997 Concept of Operations Document Guidelines proposed by Fairley and Thayer [FT97] because they felt the above guidelines were systems-oriented and developer-oriented instead of user-oriented. [FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA, 1997. © Dr. Maria M. Larrondo Petrie, 2001

The Concept of Operations Document
Identifies • classes of users and • modes of operation • normal mode • emergency mode • maintenance mode • backup mode • degraded mode • diagnostic mode Users communicate • essential needs • desirable needs -- prioritized • optional needs -- prioritized Prioritized user needs provide the basis for • establishing an incremental development process, and • making trade-offs among operational needs, schedule and budget. [FT97] © Dr. Maria M. Larrondo Petrie, 2001

Concept Analysis Concept Analysis Team, include representatives from
• user organization • training • buyer organization • operational support • developer organization or development experts/consultants Results of concept analysis are recorded in the ConOps document written in narrative prose using users' language, and using visual forms (diagrams, illustrations, graphs, etc.) wherever possible. Each operational scenario needs a test scenario to validate the system in user's environment. Validate proposed system by walking thru all scenarios, include both normal and abnormal operations: • exception handling, • stress load handling, • handling incomplete data, • handling incorrect data. [FT97] © Dr. Maria M. Larrondo Petrie, 2001

Outline for a Concept of Operations Document
1 Scope 1.1 Identification 1.2 System Overview 1.3 Document Overview 2 Referenced Documents 3 The Current System or Situation 3.1 Background, Objectives, & Scope 3.2 Operational Policies & Constraints 3.3 Description 3.4 Modes of Operation 3.5 User Classes 3.5.1 Organizational Structure 3.5.2 Profiles of User Classes 3.5.3 Interactions 3.5.4 Other Involved Personnel 3.6 Support Environment 4 Justification for and Nature of Proposed Changes & New Features 4.1 Justification 4.2 Description 4.3 Priorities among Changes/ Features 4.4 Changes/Features Considered but Not Included 4.5 Assumptions and Constraints 5 Concepts of Operations for the New or Modified Proposed System 5.1 Background, Objectives & Scope 5.2 Operational Policies & Constraints 5.3 Description of Proposed System 5.4 Modes of Operation 5.5 User Classes 5.5.1 Organization Structures 5.5.2 Profiles of User Classes 5.5.3 Interactions among User Classes 5.6 Other Involved Personnel 5.7 Support Environment 6 Proposed Operational Scenarios 7 Summary of Impacts 7.1 Operational Impacts 7.2 Organizational Impacts 7.3 Impacts During Developments 8 Analysis of Proposed System 8.1 Summary of Improvements 8.2 Disadvantages & Limitations 8.3 Alternatives/Tradeoffs considered 9 Notes, Appendices, and Glossary [FT97] © Dr. Maria M. Larrondo Petrie, 2001

Rapid Prototype [ 2/24/2000] Having a prototype during requirements phase gives you something to work from when communicating with the users and client, and results in a user-centered GUI design © Dr. Maria M. Larrondo Petrie, 2001

Traditional Expressions of Functional Requirements
Requirements specifications Hard to read. Contract-like. Context Diagram Specifies users, software, hardware that interface with system Data-flow Diagrams (DFD) Useful for technical people but tend to confuse users Useful in design of non-object-oriented systems Entity-relationship diagrams (ERD) Critical to database design but are not easily understood by users Prototypes Good communication tool to elicit information from user. Great for proof-of-concept tasks. Useful in developing user interface designs. © Dr. Maria M. Larrondo Petrie, 2001

Unified Modeling Language (UML)

UML Diagrams Instead of the Context, Data-Flow and Entity-Relationship Diagrams used in Structured Analysis, UML produces 9 types of diagrams Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Class Diagram Object Diagram Component Diagram Deployment Diagram © Dr. Maria M. Larrondo Petrie, 2001

Use Cases © Dr. Maria M. Larrondo Petrie, 2001

History of Use Cases Ivar Jacobson and his team at Ericsson in Sweden introduced Use Cases in their book: I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press, 1992. Use Cases were included as part of their overall system development lifecycle methodology, called Objectory, which was sold to Rational Software. Now Use Cases are part of the Rational Unified Process, created by the "three amigos": I. Jacobson, G. Booch and J. Rumbaugh. The Unified Software Development Process, Addison-Wesley, 1999. © Dr. Maria M. Larrondo Petrie, 2001

What is a Use Case? The Use Cases describe the behavior of a system from a user's standpoint using actions and reactions. The Use Case Diagram defines the system's boundary, and the relationships between the system and the environment: different human users roles interact with our system other software systems/applications hardware systems/devices Use Cases support the specification phase by providing a means of capturing and documenting requirements © Dr. Maria M. Larrondo Petrie, 2001

Use Case Deliverables There are two parts to document a use case:
the use case diagram, provides visual overview of important interactions captures scope (identifies external entities) the use case itself documents in a textual form the details of the requirements, what the use case must do. A use case is actually a page or two of text representing each oval in the use case diagram A project should have a standard template for use cases. © Dr. Maria M. Larrondo Petrie, 2001

Use Case Diagram Real Estate System actor system Buyer Seller
Sell Property Advisor use case interaction © Dr. Maria M. Larrondo Petrie, 2001

Use Case Documentation Template
Use Case Number: A unique numeric identifier Use Case Name: A unique descriptive identifier Iteration: Facade (Outline and high-level description), Filled (Broader, deeper), Focused (Narrower, pruned), Finished Summary: Briefly state the purpose of the use case in one or two sentences to provide a high-level definition of the functionality provided by the use case. Basic Course of Events: Include the following: 4.1 What interaction the use case has with the actors 4.2 What data is needed by the use case 4.3 When and how the use case starts and ends 4.4 The normal sequence of events for the use case 4.5 The description of alternate or exceptional flows, what happens if ... 5. The description of each step grows in detail as analysis progresses This is a numbered list. The use case number is used togetherfor with this number to provide requirements traceability Write this as a flow of events describin what the system should do, not how the system should do it. Write it in the language of the domain, not technical jargon Alternative Paths: What happens if ... invalid information is entered, unusual types of processing occurs, or uncommon conditions occur, how is the flow completed? Exception Paths: What happens if... an error occurs, how is the flow affected? Extension Points: Describes an <<extend>> relationship, shows steps which are extended by optional steps in another case Trigger: Describe entry criteria for use case, may describe business need, may be time-related, or completion of other case Assumptions: Critical section for project manager. Things (out of scope of system) you assume to be true but might not be true Preconditions: List things that must be in place before interaction can occur. (Part of contract between use case & outside world. Postconditions: List things that will be satisfied if use case is completed successfully. Independent of alternative paths taken. Related Business Rules: Written and unwritten company business rules that relate to requirements presented in this use case Author: This is placed at the bottom, together with the date to allow critical information to be speed read Date: Facade, Filled, Focused, Finished dates [KG0042] © Dr. Maria M. Larrondo Petrie, 2001

Use Case Documentation Example
Use Case Number: Use Case Name: Sell Property Iteration: Filled (Four stages of iteration are Facade, Filled, Focused, and Finished) Summary: System Context Use Case. The seller lists the property, a buyer purchases the property, and the agent guides them through the process and offers advice, caution, and recommendations Basic Course of Events: 9. System responds by notifying seller and seller's agent 10. Seller responds to the offer with a counteroffer. 11. System responds by notifying buyer and buyer's agent. 12. Buyer and seller agree to terms 13. System responds by recording the agreement 14. Buyer indicates a loan is required 15. System responds by locating an appropriate loan provider 16. Buyer and loan provider agree to loan terms. 17. System responds by recording terms of loan 18. Buyer and seller close on property. 19. System responds by recording details of close. Seller selects an agent System responds by assigning an agent and notifying the seller's agent. Seller lists the property to sell. System responds by displaying this property in the property listing and linking it for searches Buyer selects an agent. Buyer reviews the property listings by entering search criteria System displays properties matching buyer's search criteria Buyer finds a property and makes an offer on it. Alternative Paths: N/A Exception Paths: N/A Extension Points: N/A Trigger: N/A Assumptions: N/A Preconditions: N/A Postconditions: N/A Related Business Rules: N/A Author: Rumpel Stilskin Date: March 10, 2001 – Facade; April 20, Filled [KG00p25-26] © Dr. Maria M. Larrondo Petrie, 2001

A Simpler Use Case Template
A simpler template for Use Case documentation is recommended by Terry Quatrani [TQ98] For each use case: X Flow of Events for the <name> Use Case X.1 Preconditions X.2 Main Flow X.3 Subflows (if applicable) X.4 Alternative Flows where X is a number from 1 to the number of the use case [TQ98] Terry Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, Reading, Mass., 1998. © Dr. Maria M. Larrondo Petrie, 2001

Associations in Use Case Diagram
Associations can exist between an actor and a use case, between use cases, and between actors Types of Use Case Associations Communicates between actor and use case named or unnamed relationship showing participation of actor in use case, use a solid line connecting actor to use case Generalization between actors Adornments = Stereotyped Associations between use cases <<extend>> indicates relationship between use cases in which a special use case (the non-arrow end) extends an original use case (the arrow end) <<include>> reuses steps in a use case instead of cut-and-pasting steps into multiple use case documents, by pulling out common steps into a new use case and specifying with an arrowed line the <<include>> association between this new use case and those use cases requiring the steps <<uses>> An instance of the source use case includes behavior described by the target Shows a stereotyped generalization relationship between use cases © Dr. Maria M. Larrondo Petrie, 2001

Example of Generalization between Use Case Actors
Service Representative Customer Service Representative Field Service Representative [KG00p40] © Dr. Maria M. Larrondo Petrie, 2001

Example of Communicates Use Case Relationship
Buyer Sell Property Buyer Triggers Sell Property © Dr. Maria M. Larrondo Petrie, 2001

Example <<uses>> and <<extends>> Use Case Relationships
Remote Customer Local Customer Transfer by computer <<extends>> Transfer <<uses>> Identification [PM97] Pierre-Alain Muller. Instant UML, Wrox Press, Birmingham, UK. [PM97p97] © Dr. Maria M. Larrondo Petrie, 2001

Example <<include>> and <<extends>> Use Case Relationships
Office Administrator Schedule Customer Appointment <<extends>> <<includes>> Schedule Recurring Customer Appointment Schedule Designer <<includes>> Enter Customer Order [KG00p41] © Dr. Maria M. Larrondo Petrie, 2001

Course Registration Exercise
Problem Statement: At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as professor, department and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Exercise: Create a Use Case Diagram and Use Case Documentation. [TQ98p17] © Dr. Maria M. Larrondo Petrie, 2001

Introduction to Rational Rose
Rational Rose 2000 (v6.5) 1 month trial version needs key © Dr. Maria M. Larrondo Petrie, 2001

Rational Rose Environment
Standard menu Standard toolbar Diagram toolbar (unique to each type of diagram) Browser window (used to organize and navigate) Diagram window Rational Rose Environment Can be hidden, docked or floating Status bar Documentation window © Dr. Maria M. Larrondo Petrie, 2001

The View Menu Allows you to control the desk top arrangement by hiding, or displaying: The Browser Window The Documentation Window The Status Bar The Standard Toolbar The Diagram Toolbox Right clicking on one of the above items (on one of the components in them) allow the item to be Docked Floating Hidden © Dr. Maria M. Larrondo Petrie, 2001

The Toolbars Right Clicking on a Toolbar/Toolbox button allows you to:
Dock the Toolbar Float the Toolbar Use Large Buttons Customize If the Toolbar/Toolbox is not visible, select it using the View  Toolbars menu © Dr. Maria M. Larrondo Petrie, 2001

The Tools Menu Under the Tools menu item, can: Generate Code in
Ada Java Oracle8 C++ XML_DTD Reverse Engineer Models from Code Add Version Control ... © Dr. Maria M. Larrondo Petrie, 2001

The Browser Window Used to navigate through the models and documentation using an textual outline Expand and contract using or in front of the View Select model/component Browser may be made visible or hidden by using the View menu, or right-clicking on an item in the Browser window. Browser may be docked or floating by right-clicking on one of the items in the Browser window. + - Views from the Browser window © Dr. Maria M. Larrondo Petrie, 2001

4+1 View of Software Architecture
Software architecture consists of 5 concurrent views [PK94] Rational Rose provides 5 different perspectives/views. Selecting a view allows users to focus only on what is architectural significant and meaningful to them View Target Audience: Use-Case View End User Logical View Analyst/Designer Process View System Integrator Deployment View System Engineer Implementation View Programmer in Rose: Component View [PK 94] Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation, Santa Clara, CA, April 1994. © Dr. Maria M. Larrondo Petrie, 2001

4 Views + 1 Architectural View
in Rose: Component View [RR00] © Dr. Maria M. Larrondo Petrie, 2001

The Use-Case View From end-users' perspective Concerned with
Understandability Communication Usability Use Case Model captures system's intended functions and interactions with environment use case diagrams use case flow of events supplemental documentation activity diagrams (optional) requirements specification. Use Case Model can serve as a contract between customer and developer instead of the traditional text requirement specification A Use Case Diagram [RR00] © Dr. Maria M. Larrondo Petrie, 2001

The Logical View Concerned with functional requirements of the systems
From analyst/designer perspective Includes use case realization diagrams class diagrams interaction diagrams statechart diagrams (optional) activity diagrams (optional) A Class Diagram [RR00] © Dr. Maria M. Larrondo Petrie, 2001

The Process View Presents a perspective for the System Integrators
Non-functional requirements Include: Performance Scalability Availability Fault Tolerance Throughput Concurrency and synchronization threads processes Note: Not necessarily a single processing environment © Dr. Maria M. Larrondo Petrie, 2001

The Deployment View For System Engineers
Used only for distributed systems Captures how executables and other run-time components are to be mapped to platforms or computer nodes Includes: Performance – Delivery Scalability – Installation Availability Fault Tolerance Deployment Diagram © Dr. Maria M. Larrondo Petrie, 2001

The Implementation View
Called Component View in Rational Rose Aimed at Programmers Captures organization of static software modules: packaging, layering, and configuration management source code files data files components executable, etc. Concerned with derived requirements: ease of development software management reuse constraints imposed by programming language and development tools sub-contracting off-the-shelf components © Dr. Maria M. Larrondo Petrie, 2001

The Documentation Window
Used to create, view and modify text documenting a selected item. May be visible or hidden; docked or floating can be changed by selecting using View menu or right clicking on an item in the Documentation Window The information added to the documentation window automatically updates the Documentation field in the appropriate specification. © Dr. Maria M. Larrondo Petrie, 2001

The Diagram Window Allows you to create, update, and modify graphical views of the current model. The Diagram Toolbox is unique to the diagram type, and changes automatically when you change types of diagrams. Select a diagram or add a diagram by selecting it from those listed under the appropriate view in the Browser Window © Dr. Maria M. Larrondo Petrie, 2001

The Specification Window
Textual representation of a model element that permits viewing and manipulating the element's model properties Open by right clicking on a View in the Browser Window © Dr. Maria M. Larrondo Petrie, 2001

The Log Window Reports progress results errors Right click in the Log Window to set available action Ctrl-tab from Log Windows returns to previous diagram © Dr. Maria M. Larrondo Petrie, 2001

Creating the 4+1 Views © Dr. Maria M. Larrondo Petrie, 2001

The Rational Unified Process
Inception Phase: establish business rationale for project decide project scope get go-ahead from project sponsor Inception Elaboration Construction Transition 1 2 3 ... Elaboration Phase: collect more detailed requirements do high-level analysis and design establish baseline architecture create construction plan Construction Phase: build, test and validate the project Transition Phase: beta-test tune performance train users © Dr. Maria M. Larrondo Petrie, 2001

Developing the Use Case View
In the Inception Phase Identify actors Identify principal use cases In the Elaboration Phase More detailed information is added associations stereotypes Additional use cases are added as needed © Dr. Maria M. Larrondo Petrie, 2001

Finding Actors Actors are NOT part of the system.
Actors represent anyone or anything that interacts with (input to or receive output from) the system Questions to help find actors [TQ98p21-22] Who is interested in a certain requirement? Where is the system used within the organization? Who will benefit from the use of the system? Who will supply the system with 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? Do several people play the same role? Does the system interact with a legacy system? © Dr. Maria M. Larrondo Petrie, 2001

Creating Actors in Rational Rose
Right-click on the Use Case View package in the browser to make the shortcut menu visible. Select the NewActor menu option. A new actor called New Class will appear in the browser under Use Case View The New Class actor to the desired name Move cursor to the Documentation Window and add the documentation. Repeat until all actors are added and documented © Dr. Maria M. Larrondo Petrie, 2001

Finding Use Cases Use case = a sequence of transactions performed by a system that yields a measurable result of values for a particular actor The use cases = all the ways the system may be used. Questions to help find use cases [TQ98p25] 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 or maintain the system? Can all functional requirements be performed by the use cases? © Dr. Maria M. Larrondo Petrie, 2001

Creating Use Cases in Rational Rose
Right-click on the Use Case View in the Browser to make shortcut menu visible. Select the NewUse Case menu option. With the unnamed use case selected, enter the desired name. Move cursor to documentation window and add a brief description. Repeat for each use case. © Dr. Maria M. Larrondo Petrie, 2001

Finding Flow of Events Flow of events document is typically created in the elaboration phase Each use case is documented with flow of events a description of events needed to accomplish required behavior written in terms of what the system should do, NOT how it should do it written in the domain language, not in terms of the implementation Flow of events should include When and how the use case starts and ends What interaction the use case has with the actors What data is needed by the use case The normal sequence of events for the use case The description of any alternate or exceptional flows Each project should use a standard template. See the previous slides in the requirements section for two suggested templates used to document in detail each requirement. © Dr. Maria M. Larrondo Petrie, 2001

The Use Case View for the Case Study: Course Registration System

The Actors In the Course Registration System, answering the questions suggested to find actors yields: Students want to register for courses Professors want to select courses to teach Registrar must create the curriculum and generate a catalog for the semester Registrar must maintain all the information about courses, professors, and students Billing System must receive billing information from the system Actors identified from above: Student – person registered/registering in classes at the University Professor – person certified to teach classes at the University Registrar – person who maintains the Course Registration System Billing System – external software system that does student billing © Dr. Maria M. Larrondo Petrie, 2001

The Use Cases Answering the questions to find use cases yields:
The Student actor needs to use the system to register for courses After the course selection process is completed, the Billing System must be supplied with billing information The Professor actor needs to use the system to select the courses to teach for a semester, and must be able to receive a course roster from the system The registrar is responsible for the generation of the course catalog for a semester, and for the maintenance of all information about the curriculum, the students, and the professors needed by the system Based on the needs, the following cases are identified: Register for courses Select courses to teach Request course roster Maintain course information Maintain professor information Maintain student information Create course catalog [TQ98p24-25] © Dr. Maria M. Larrondo Petrie, 2001

Add Use Cases to the System
Give a brief description of each use case i the Documentation window This is the summary description for Register for courses [TQ98p28-29] © Dr. Maria M. Larrondo Petrie, 2001

The Flow of Events Exercise: Form a team and agree on a standard template to use for documenting flow of events for the use cases. Look at Quatrani's recommended template [TQ98] and The following flow of event for the Select Courses to Teach use case follows Quatrani's recommended template [TQ98] For each use case: X Flow of Events for the <name> Use Case X.1 Preconditions X.2 Main Flow X.3 Subflows (if applicable) X.4 Alternative Flows where X is a number from 1 to the number of the use case © Dr. Maria M. Larrondo Petrie, 2001

The Flow of Events (1 of 4) [TQ98p30]

The Flow of Events (2 of 4) [TQ98p31]

The Flow of Events (3 of 4) [TQ98p31-2]

Use Case Diagram (1 of 2) [TQ98p38]

Use Case Diagram (2 of 2) [TQ98p31]

Exercises Individually create a Problem Statement and Use Case Diagram for one of the following Vending Machines: Hot Drink Vending Machine that mixes and dispenses two sizes of hot drinks (coffee, tea, hot chocolate) with/without cream and sugar/sweetener. Ice Cream Vending Machine that dispenses prepackaged ice cream (individual cups, bars, cones, sandwiches – pre-wrapped) Carousel Vending Machine that dispenses a variety of food (many with expiration date) on a stack of see-thru carousels containing a number of individual food compartments. Each carousel has a door. The customer turns the carousels until the item is positioned in front of a door.. The action of sliding open the door, selects and dispenses the food. Meet in a team of 3-4, discuss each Problem Statement and Use Case Diagram, features (such as sensors, credit cards payment) that would enhance the marketing of the product. Produce a group Problem Statement and Use Case Diagram. Turn in all the statements/diagrams with the author's name, clearly mark the group approved ones with all the team members' names and initials. Select one team member and an alternate that will walkthrough the statement and diagram for the class to review. © Dr. Maria M. Larrondo Petrie, 2001

The Logical View Develop Class Diagrams Develop Interaction Diagrams
Develop State Diagrams Develop Activity Diagrams © Dr. Maria M. Larrondo Petrie, 2001

Developing the Logical View
One of the main diagram produced in the logical view is the Class Diagram. The Rational Unified Process suggests using a model-view-controller perspective to partition the system by separating the view from the domain from the control needed by the system. Typical Class Stereotypes: Entity Classes (or Domain Classes) may reflect real-world entity or may perform tasks internal to the system. may be used in multiple applications; are surrounding independent Boundary Classes model system interfaces between the actors and the application are surrounding dependent Control Classes coordinate events needed to realize one or more use cases typically are application-dependent © Dr. Maria M. Larrondo Petrie, 2001

Top-Down or Buttom-Up? Top-Down – Identify Packages first, then Classes Right click on Logical View in the Browser, select NewPackage, or drag-drop toolbox icon into the Class Diagram, name the package and fill documentation. More details are added using Specification Window. To insert new classes into the package: Right click on the package in the Browser, and select NewClass, name the class and fill documentation description To insert existing classes into the package: In the Logical View in the Browser, click on class and drag into package. Buttom-Up – Identify classes first, then group Right click on Logical View in the Browser, select NewClass, name the class and fill documentation. Repeat until most classes are identified. Organize classes into groups by creating packages Insert the classes into the appropriate package: In the Logical View in the Browser, click on class and drag into package © Dr. Maria M. Larrondo Petrie, 2001

Select a Use Case and SubFlow
Look at a use case: Select Courses to Teach Select a subflow: Add a Course Offering Although the flow is written sequentially, in the real world many steps may occur concurrently The professor logs onto the Registration System and enters password. The system verifies the password is valid (E1) and prompts the professor to select the current semester or a future semester (E2). The professor enters the desired semester. The system prompts the professor to select the desired activity: ADD, DELETE, REVIEW, PRINT, or QUIT. The professor chooses ADD, the S-1: Add a Course Offering subflow is selected. S-1 Add a Course Offering The system displays the course screen containing a field for a course name and number. The professor enters the name and number of a course (E-3). The system displays the course offerings for the entered course (E-4). The professor selects a course offering. The system links the professor to the selected course offering (E-5). The use case then begins again. E-3: An invalid course name/number is entered. The user can re-enter a valid name/number combination or terminate the use case E-4: Course offerings cannot be displayed. The user is informed that this option is not available at the current time. The use case begins again. E-5: A link between the professor and the course offering cannot be created. The information is saved and the system will create the link at a later time. The use case continues © Dr. Maria M. Larrondo Petrie, 2001

What is a Scenario? What is a scenario?
A use case is a class, not an instance; it describes the functionality as a whole and includes possible alternatives, exceptions and errors that are possible during the execution of the use case. A scenario is an instantiation of a use case or a collaboration. It represents an actual usage of the system -- a specific execution path through the flow of events. Example from [EP98]: Use Case: Signing Insurance Scenario: "John Doe contacts the system by telephone and signs for car insurance for his new Toyota Corolla" © Dr. Maria M. Larrondo Petrie, 2001

Scenarios Scenarios are used to complement (not replace) and clarify a use case description in terms a user can understand A set of scenarios are used to illustrate the use case or collaboration. Make sure to select scenarios that illustrate normal and abnormal (using exceptions and alternate flows). When a scenario is viewed as a use case, describe only the external behavior toward the actors When a scenario is viewed as an instance of a collaboration, describe the internal implementation of the involved classes, their operations and communications A scenario is presented as a numbered sequence of steps. © Dr. Maria M. Larrondo Petrie, 2001

Identify Classes and Create Packages
Identify Boundary Classes Identify Entity Classes Identify Control Classes Create Packages © Dr. Maria M. Larrondo Petrie, 2001

Identify Boundary Classes
With what actors does the use case interact? Professor What information do we need to keep track of? what options is the professor allowed to use add, modify, delete, review, print course offering ProfessorCourseOptions What information do we Class to take care of use case subflow: AddACourseOffering What general flows do we need to support? © Dr. Maria M. Larrondo Petrie, 2001

Identify Entity Classes
Domain Classes identified: Course CourseOffering ProfessorInformation keeps track of professor's course assignment © Dr. Maria M. Larrondo Petrie, 2001

Identify Control Classes
Add control classes to handle the flow of events for the use case: ProfessorCourseManager © Dr. Maria M. Larrondo Petrie, 2001

Create Packages Classes identified: Group classes into packages:
Boundary Classes ProfessorCourseOptions AddACourseOffering Entity Classes Course CourseOffering ProfessorInformation Control Classes ProfessorCourseManager Group classes into packages: Three Logical Groups: Interfaces UniversityArtifacts People © Dr. Maria M. Larrondo Petrie, 2001

References References used:
[EP ] Hans-Erik Eriksson and Magnus Penker. UML Toolkit, John Wiley & Sons, New York, NY, ISBN [MF97] Martin Fowler with Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading, Mass, ISBN [KG00] Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context, Addison-Wesley, New York, NY, ISBN [PK 94] Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation, Santa Clara, CA, April 1994. [PM97] Pierre-Alain Mueller. Instant UML, WROX Press, Chicago, IL [TQ98] Terry Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, Birmingham, UK, ISBN © Dr. Maria M. Larrondo Petrie, 2001

UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie

Similar presentations

Presentation on theme: "UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie

Similar presentations

Presentation on theme: "UML and Rational Rose Notes Dr. Maria M. Larrondo Petrie"— Presentation transcript:

Similar presentations

About project

Feedback