Presentation is loading. Please wait.

Presentation is loading. Please wait.

RATIONAL ROSE. 2  ROSE = Rational Object Oriented Software Engineering  Rational Rose is a set of visual modeling tools for development of object oriented.

Similar presentations


Presentation on theme: "RATIONAL ROSE. 2  ROSE = Rational Object Oriented Software Engineering  Rational Rose is a set of visual modeling tools for development of object oriented."— Presentation transcript:

1 RATIONAL ROSE

2 2  ROSE = Rational Object Oriented Software Engineering  Rational Rose is a set of visual modeling tools for development of object oriented software.  Rose uses the UML to provide graphical methods for non- programmers wanting to model business processes as well as programmers modeling application logic.  facilitates use of the Unified Modeling Language (UML), Component Object Modeling (COM), Object Modeling Technique (OMT), and Booch ‘93 method for visual modeling. History

3 3  Modeling can be useful at any point in the application development process.  Initial Design Work (Requirement Analysis and Definition) Use Cases Class Diagrams Sequence Diagram Generality is Good in early design. When to use Rational ROSE

4 4  Refinement of Early Models (System & Software Design)  Introduced in Middle of Project Rational Rose includes tools for reverse engineering as well as forward engineering of classes and component architectures. You can gain valuable insights to your actual constructed architecture and pinpoint deviations from the original design. Rose offers a fast way for clients and new employees to become familiar with system internals When to use Rational ROSE

5 5 Rational Rose Environment Diagram Toolbar Status Bar Diagram Window Standard Toolbar Browser Documentation Window

6 6 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

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

8 8 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...

9 9 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 + -

10 10 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 ViewTarget Audience Use-Case ViewEnd User Logical ViewAnalyst/Designer Process ViewSystem Integrator Deployment ViewSystem Engineer Implementation View Programmer in Rose: Component View

11 11 4 Views + 1 Architectural View

12 12 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

13 13 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

14 14 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

15 15 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

16 16 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

17 17 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.

18 18 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

19 19 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

20 20 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

21 Rational Rose Use Cases Diagram

22 22 Example: Course Registration System  Registrar maintains in the system the list of valid courses, students, and professors, and the course schedule.  Professors indicate the courses they will teach.  Students register for the open registration period.  When a student registers, the billing system is updated.  Professors can request a course roster.

23 23 Open Rational Rose  Open Rational Rose from your start menu.  Click Close on the Create New Model dialog.

24 24 Process of Requirements Use-Case Modeling  Objective is to elicit and analyze enough requirements information to prepare a model that: Communicates what is required from a user perspective. Is free of specific details about how the system will be built or implemented.  To effectively estimate and schedule project, may need to include preliminary “system implementation assumptions.”  Steps 1. Identify business actors. 2. Identify business use cases. 3. Construct use-case model diagram. 4. Documents business requirements use-case narratives.

25 25 Select Use Case View

26 26 Create an Actor – e.g., Student Actor  Right-click on Use Case View icon to open the context sensitive menu and select New  Actor  Change Actor name to Student

27 27 4 Types of Actors  Primary business actor The stakeholder that primarily benefits from the execution of the use case. e.g. the employee receiving the paycheck  Primary system actor The stakeholder that directly interfaces with the system to initiate or trigger the business or system event. e.g. the bank teller entering deposit information  External server actor The stakeholder that responds to a request from the use case. e.g. the credit bureau authorizing a credit card charge  External receiver actor The stakeholder that is not the primary actor but receives something of value from the use case. e.g. the warehouse receiving a packing slip

28 28 Add Actor Specifications  Right-click on Actor and select Open Specification.  Enter Documentation for the Actor.

29 29 Add Other Actors (see below) Actor Actor Description Documentation Student A person who is registered to take classes at the University. Professor a person who is certified to teach classes at the University Registrar the person who is responsible for the maintenance of the Registration system Billing System the external system responsible for the student billing system.

30 30 Identify Business Requirements Use Cases  During requirements analysis, document only the most important use cases, often called essential use cases.  When looking for use cases, ask the following questions: What are the main tasks of the actor? What information does the actor need form the system? What information does the actor provide to the system? Does the system need to inform the actor of any changes or events that have occurred? Does the actor need to inform the system of any changes or events that have occurred?

31 31 Create a Use Case  Right-click on Use Case View icon to open the context sensitive menu and select New  Use Case  Change use case name to Register for Courses

32 32 Add Use Case Documentation  Right-click the use case; open it's specification; Add Documentation.  E.g.: This use case is initiated by the Student. It provides the capability to create, modify, and/or review a student schedule for a specified semester.

33 33 What makes a good Use Case?  What level of detail should be included? How big or little should they be?  For example: Registration includes: Student selects courses Student selections update the course-offering Student's fee charges are assessed  Is that 1 use case, or 3 use cases ? ? ?

34 34 What makes a good Use Case?  Terry Quatrani's Guideline: 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.  In the registration example, all three functions belong in one use case.

35 35 Add Use Case Glossary to Model Use-Case Glossary Use-Case NameUse-Case Description Participating Actors and Roles Register for coursesAllows student to create, update, review, delete schedule entries. Student, Registrar Maintain Course Information Allows Registrar to create, update, review, delete course information in the catalog and schedule of classes. Registrar Maintain Professor Information Allows Registrar to create, update, review, delete professor information. Registrar Maintain Student Information Allows Registrar to create, update, review, delete student information. Registrar, Student Create Course CatalogAllows Registrar to create a course schedule from the catalog for a semester, with input from professors. Registrar, Professor Select courses to teachAllows Professors to indicate which courses they will teach in a semester. Professor, Registrar Request course rosterProfessors can request and get a roster for the courses they teach. Professor

36 36 Create a Use Case Narrative  Use the Use Case Templates in MS Word (from Templates)  Copy to model use case sub-directory and rename.  Link it to the Use Case.

37 37 Link Model Use Case to Narrative

38 38 Use Case Relationships Association – a relationship between an actor and a use case in which an interaction occurs between them. Association modeled as a solid line connecting the actor and the use case. Association with an arrowhead touching the use case indicates that the use case was initiated by the actor. Association lacking arrowhead indicates a receiver actor. Associations may be bidirectional or unidirectional.

39 39 Extension Use Case Extension use case – a use case consisting of steps extracted from a more complex use case in order to simplify the original case and thus extend its functionality. Relationship between the extension use case and the use case it is extending is called an extends relationship. Represented as an arrowheaded line beginning at the extension use case and point to the use case it is extending. Each extends relationship line is labeled “ >.”

40 40 Use Case Includes a use case Abstract use case – a use case that reduces redundancy among two or more other use cases by combining the common steps found in those cases. An abstract case is available for use by any other use case that requires its functionality. Relationship between the abstract use case and the use case that uses it is called a uses (or includes) relationship. Depicted as an arrowheaded line beginning at the original use case and pointing to the use case it is using. Each uses relationship line is labeled “ >.”

41 41 Creating the Main Use Case Diagram in Rational Rose 1. Double-click on the Main diagram in the Use Case view to open the diagram [blank]. 2. Click to select an actor in the browser and drag the actor onto the diagram. 3. Repeat step 2 for each additional actor. 4. Click to select a use case in the browser and drag the use case onto the diagram. 5. Repeat step 4 as necessary.

42 42 Adding Relationships/Associations  You may need to customize the Rational Rose tool bar to see all relationship icons. Right-click on tool bar to customize it.

43 43 Adding Relationships/Associations 1. Click to select the Association icon or the Unidirectional Association icon on the tool bar 2. Click on an actor initiating a communication and drag the association line to the desired use case. (See next slide for example diagram.) Unidirectional Association Association Dependency Association

44 44 Associations / Relationships

45 45 Other Relationship Types Include Use Case  Click to select the Dependency Icon from the toolbar.  Click on the base use case and drag the dependency icon to the target use case.   Double-click on the dependency arrow to open the specification.  In the Stereotype field, select include, and close the specification. Extends Use Case 1. Click to select the Dependency Icon from the toolbar. 2. Click on the extending use case and drag the dependency icon to the base use case.  3. Double-click on the dependency arrow to open the specification. 4. In the Stereotype field, select extend, and close the specification.

46 46 Activity Diagrams  Represent the Dynamics or Flow a the system.  They are like Flow Charts.  Represents flow across Use Cases, or  Represents flow within a Use Case

47 47 UML Notation for an Activity Diagram  Activity  Transition  Decision  Synchronization bars

48 48 Creating Activity Diagrams in Rational Rose  Right-Click on the Use Case View in the Model Browser to open the context menu.  Select New  Activity Diagram. Give the diagram a name.  Double click it to open it up.

49 49 Place Activities on the Diagram  Select the Activity Icon from the toolbar, and place it on the diagram  Name the the activity.

50 50 Add Flows and Decision Points 1.Draw Flow lines between activities. 2.Add a decision point (diamond).; and name it. 3.Create a "guarded transition" by right clicking the transition, opening the specification; selecting the Detail tab; and fill in the Guard Condition. 4.You can straighten the lines out by selecting the line and clicking: Format  Line Stype  Rectilinear

51 51 Add Syncronization Bars, And Activities Note: Swim-lanes can be added to show responsibilities, but I have not had good luck with them in Rose.

52 52 Use Case Modeling Tips  Association between actors and use cases indicate the need for interfaces. Actor – User : Screens/Forms or Reports Actor – System: data file transfer or a real- time data update.  Write use cases under the assumption that you can exit at any time without worry. Assume that some how the system will handle it.

53 53 Use Case Modeling Tips  Do not over use re-use or get hung- up on > and Guidelines: Do not try to do functional decomposition in a use case. Purpose is to describe a series of actions that offer value to the actors. If a use case is 1 sentence, level of detail too low.

54 54 Use Case Modeling Tips  Write use cases from the point of view of the actor in the active voice. Point is to understand how the users will use your system.  Write scenario text, not functional requirements. There are other models for defining functional requirements.

55 55 Use Case Modeling Tips  A Use Case is neither a Class specification nor a Data specification. Use a Class Model or a Data Model for that  Create a Use Case Template Customized for your company and your development process.

56 56 Use Case Modeling Tips  Organize Use Case Diagrams Consistently Common practice to draw inheritance and extend relationships vertically. Include relationships are typically drawn horizontally.  System should respond to actions of actors. Receiver actors? (the exception)

57 57 Use Case Modeling Tips  Alternative courses of action are important. Start with the “happy path” – the basic course of action. Alternate courses are introduced to describe potential usage errors, as well as business logic errors and/or exceptions.  Use Cases drive User Documentation – which describes how to work with the system. Use cases are a great starting point.

58 58 Use Case Modeling Tips  Use Cases drive Presentations Part of software development is communicating your work efforts with project stakeholders. Because use cases are written from the point of view of your users, they contain valuable insight to how they interact with the system.

59 59 Summary  Use Cases are a great tool for recording the requirements of a system  Clients / End-users find them easy to understand.  Use case pictures give a good overview of the system and use case narratives provide more details about a specific use case.  Activity Diagrams are useful for noting the flow between and within use cases.

60 60 Create a Class Diagram  Browser: Logical View  Right Button Menu  New  Class Diagram  Menu : Browse  Class Diagram

61 Rational Rose Class Diagram

62 62 Creating more Diagrams  Select in Browser  Right Button Menu  New   Browse Menu 

63 63 Toolbar for Class Diagrams  Any element of a diagram can be created by placing the mouse pointer over a Tool in the Toolbar Drag&Drop over the diagram canvas text class interface asociation Association class package Note Anchor dependency or instantiation Note generalization realization Pointer

64 64 Create a Class  Place mouse pointer on Class Tool Toolbar : Click Class button Icon Menu: Tools  Create  Class   Click on Diagram Window OR  Browser : Sel. Logic View  right button menu  New Class (Sel. Clase  Drag &Drop over Diagram Window)

65 65 Create a Class

66 66 Create a Class

67 67 Create Diagram Elements  Place Mouse Pointer Click on Toolbar button Sel. Diagram in Browser  right button  New Menu  Tools  Create   Click on diagram

68 68 Specify Class Name  Directely in the diagram  Double click on the class  “Class Specification for NewClass”

69 69 Specify Diagram Elements  Specification Window Allows you to specify a model element (diagrams, classes, packages, relationship...)  The attributes or sub-elements to be specified depend on the selected element In each TabWindow attributes and sub-elements would be specified

70 70 Specify Diagram Elements  Open Specification Window Double Click on element via Browser or Diagram Window Sel. element (Browser,Diagram Window)  Mouse right button menu  Open Specification Sel. elemento  Browse menu  Open Specification  Shorcuts of TabWindows, Properties, WIndow Specification Menus Sel. Element (Browser,Diagram Window)  right button Menu  new ( attribute, operation...) OR OR

71 71 Class Graphic Synchronized An element Can be in multiple diagrams Only one instance in the Browser

72 72 Delete an Element  Shallow Delete Edit Delete Select element in diagram  key DEL  Deep Delete Select element in Browser  click right button  Delete Select element in diagram  Click CTRL+D It is not deleted from the MODEL!! (only from the diagram, not from Browser) It is deleted from the MODEL!! (It will disapear from the diagram and from the Browser)

73 73 Create an Operation  Diagram: Select class  Mouse right button menu  New Operation  Browser: Select class  Mouse right button menu  New Operation

74 74 Create an Operation

75 75 Specify an Operation  Directly: write the signature of the method > nameOperation( param: Typo,...) : Return Type  Indirectly: Class Specifcation  tab Operations  right button menu  Insert (operation) Double click on method  Operation Specification Name  Details  right button menu  Insert (parameter)

76 76 Specify an Operation  Name  Parameter Name,Type  Return Type  Accesibility Public, Protected, Private  Abstract o Concrete (checkbox Abstract in Details TabWindow)

77 77 Create an Attribute  Diagram: Select class  Mouse right button menu  New Attribute  Browser: Select class  Mouse right button menu  New Attribute Browser: would be updated in Diagram Window

78 78 Specify Attribute  Directly: write the signature of the attribute > nameAttribute : Type  Indirectly: Class Specification  tab Attributes  right button menu  Insert ( attribute) Double click on attribute  Attribute Specification Name  Type

79 79 Specify Attributes  Name  Type  Accesibility Public, Protected,Private  Class Abstract or Concrete (checkbox Abstract in Details TabWindow)

80 80 Class Relationships  UML Relationships in Rational Rose Generalization Association  Aggregation Composition Dependency

81 81 UML Relationships in Rational Rose AB Association Generalization (Inheritance) AB AB 1..n roleA roleB multiplicity Navegability from B to A

82 82 Relaciones UML en Rose Aggregation Dependency or Instantiation AB AB AB Composition

83 83 Create Generalization  Place Mouse Pointer over Tool Click on button Toolbar Menu  Tools  Create Generalization   Click on Diagram Window  Connect element B to A

84 84 Specify Generalization  Like the rest of the elements: Double click on element Sel. element  right button menu  Open Specification or Shortcut of TabWindow/Property Sel. Sel element  Browse menu  Specification (note: it does appear on the Browser)

85 85 Create an Association  Place mouse pointer over Tool Click on Toolbar button Menu  Tools  Create Generalization   Click on Diagram Window  Connect element B to A

86 86 Specify Association  Like the rest of Elements: Double click, Sel (Browser Diagram Window) + Right Button Menu, Browse menu) It will appear as another element else in the Browser

87 87 Specify Association  Specify Navegability Accesibility  public (+), protected (#), private (-) Multiplicity (1..n, 0..n, etc...) Aggregation Role names Association names Content Type:  Reference, Value, no specify

88 Rational Rose Sequence Diagram

89 89 New Sequence diagram Browse Interaction Diagram In the Standard toolbar click the Browse Interaction Diagram icon. Select use-case view. Select a new interaction diagram. Select a Sequence Diagram.

90 90 Insert Classes Select the classes in the browser and drag-and-drop them to the Sequence Diagram Window.

91 91 Draw The Messages Draw the messages between the objects selecting the adequate icons in the diagram toolbox.

92 Rational Rose Collaboration Diagram

93 93 New Collaboration Diagram 1.In the Standard toolbar click the Browse Interaction Diagram icon. 2.Select use-case view. Select a new interaction diagram. 3.Select a Collaboration Diagram. Select the classes in the browser and drag-and-drop them to the Collaboration Diagram Window.

94 94 Create Links & Messages Create a link between two classes clicking the object link icon. Create a link messages selecting the adequate icon in the diagram toolbox and clicking in the diagram window when the pointer is placed at the link line.

95 95 Create Links & Messages (Cont.) Using the right mouse button over the message element a menu is pulled-down  select OPEN SPECIFICATION. The message specification window is displayed.


Download ppt "RATIONAL ROSE. 2  ROSE = Rational Object Oriented Software Engineering  Rational Rose is a set of visual modeling tools for development of object oriented."

Similar presentations


Ads by Google