1 / 24

Rose Basics

Rose Basics. What is Visual Modeling. Helps organize, visualize, and understand complexity . Is the mapping of real processes of a system to a graphical representation . Is a proven and accepted engineering technique. Has a common vocabulary, the Unified Modeling Language (UML). Models.

elias
Download Presentation

Rose Basics

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. Rose Basics 13 of 24

  2. What is Visual Modeling • Helps organize, visualize, and understand complexity. • Is the mapping of real processes of a system to a graphical representation. • Is a proven and accepted engineering technique. • Has a common vocabulary, the Unified Modeling Language (UML). 13 of 24

  3. Models • Models themselves are constructed using different viewsand diagrams to accurately depict different stakeholder perspectives and the system’s building blocks, respectively. • Models are complete representations of the system. • Views allow different stakeholders to see the system from their own perspectives • Views contain Models… • Models contain diagrams – some of these terms are ‘used’ interchangeably… • Diagrams: means by which we view of the system. • Different building blocks (model elements) for different types. classes, interfaces, collaborations, components, nodes, dependencies, generalizations, and associations. • The 4 + 1 Architectural Views: how they work in Rose. 13 of 24

  4. End-user Functionality System integrators Performance Scalability Throughput LogicalView Implementation View Analysts/Designers Structure / Behaviors Programmers Software management Use-Case View Process View Deployment View System engineering System topology Delivery, installation communication Very Important: 4 + 1 Architectural View 13 of 24

  5. 4+1 Architectural View Use Case View - represents the system’s intended functions and environment as seen by its end users. • Serves as a contract between customer and developer. • Is essential to analysis, design and test activities. •  Includes use case diagrams, use case flow of events, and supplemental documentation. •  It can also include activity diagrams. • Is the heart of and drives all other views. • Used for requirements capture and analysis…and much, much more 13 of 24

  6. 4+1 Architectural View Logical View • Supports modeling the functional requirements of the system, meaning the services the system should provide its end users. • Includes analysis class modeling, use case realizations, and interaction diagrams. • It can also include state-chart and activity diagrams. – discuss. • Much analysis and design involve elements in this view. • In fact, ‘most’ analysis and design in done here… • Much of this work is done in Elaboration and some in Construction 13 of 24

  7. 4+1 Architectural View = Rose Implementation View (Component View in Rose) • Describes organization of static software modules (source code,data files, components, executables, and such) in terms of packaging and layering and configuration management. • Addresses issues of ease of development, management ofsoftware assets, reuse, sub-contracting, and off-the-shelf components. • Used in programming and testing. • Most (almost all) of this work is done during Construction phase. (Some done – clean up, rework… in Transition…) 13 of 24

  8. 4+1 Architectural View Process View • Includes the threads and processes that form the system’s concurrency and synchronization mechanisms. • Addresses the performance, scalability, and throughput of the system. • (Several of the ‘non-functional’ requirements are often addressed here.) • Is not necessary for single processing environment. Deployment View • This ‘View’ is used for distributed systems only. • Shows how the various executables and other runtime components are mapped to the underlying platforms or computing nodes. • Do not confuse the Deployment View with ‘deployment’ and deployment artifacts as found in the Transition phase…. • This here is an architectural View not a development Phase! 13 of 24

  9. State Chart Diagrams •  State Diagrams specify the sequences of states that an object can be in; • events and conditions that cause transition from one state to another; • and actions that take place when the next state is reached; • Can be attached to use cases to model a scenario. • Model the dynamic aspects of the system. • Particularly useful in modeling complex interactions that may be difficult to capture in a Use Case – or to supplement the textual Use Case Description. 13 of 24

  10. State Chart Diagrams Should be created only when needed to represent state-controlled class behavior. • Statechart diagrams model the behavior of a single object over its lifetime. • Statechart diagrams model the flow of control from event to event. 13 of 24

  11. Activity Diagrams • Model the workflow of a business process or a class operation. • Sometimes considered a visual description of a use case…. • Often accompany a Use Case description. • Some Modelers prefer Activity Diagrams… • Are similar to a flowchart because you can model a workflow from to activity or from activity to state. Really, model is much more… • Are considered a special case of a state machine where most of the states are activities and most the transitions are implicitlytriggered by completion of the actions in the source activities. • Models the dynamic aspects of the system. Key elements • • Start and end states • Synchronization • States Decisions • • Transitions • Activities • Swimlanes 13 of 24

  12. Component View Component Diagrams: Sometimes called the Implementation View Contains: source code (.cpp, …) .dlls .exes .h files .java files Typically configured into packages of source code modules, data base entities, tables, files, etc. 13 of 24

  13. Deployment View Deployment diagrams • Are modeled in the Deployment View. • Show the allocation of processes to processors in the physical design of a system. • Represent all or part of the process architecture of a system. • Deployment diagrams are required for distributed systems only. • Show the physical aspects of the system. • Key elements • • Processors • Connections • Devices • Specifications 13 of 24

  14. Use of Rational Rose … Do the following on your own – in conjunction with the Visual Modeling Text. This text steps you through your diagramming efforts step by step. 13 of 24

  15. The Rational Rose 2000 Interface • Browser: (see next slide) • Think of the browser as Rose’s Windows Explorer. • Displays the elements that you’ve modeled. • If an element doesn’t appear in the browser, it is not a part of your modeled system. • May be visible or hidden; docked or floating. • Documentation window • Used to create, view, or modify text explaining a selected item. • May visible or hidden; docked or floating. • Note that information added to the documentation window is automatically added to the Documentation field for the the appropriate specification selected in the main window. 13 of 24

  16. 13 of 24

  17. The Rational Rose 2000 Interface • Diagram window • Allows you to create, update, and model graphical views of the current model. • Diagram toolbar (show) • Is unique to each diagram type and can be customized. • Is active only when a diagram is displayed. • May be visible or hidden; docked or floating. 13 of 24

  18. The Rational Rose 2000 Interface The Specification window – (right click on Use Case Package; Open Specification…) • Is a textual representation of a model element that allows you to view and manipulate the element's model properties. • Note that information added to the documentation window is automatically added to the documentation field in the specification window. The Log window – (down at very bottom) • Reports progress, results, and errors • Right-click on Log window to see available actions. 13 of 24

  19. The Rational Rose 2000 Interface The Options window (Select: view, toolbar, configure) • Allows you to customize Rose to suit your needs. • For specific topic information, click ? in the upper right corner, then click the field. • Selections made in Options are your defaults. • Make sure they are set up to your liking before you model • Changing this information after a model is created does not alter existing information. For example, changing the default fill color applies to future additions. You would have to change existing elements manually. • General Can customize fonts, use of backup files, save setting. • Browser - Can show stereotypes in the browser • Notation – Can customize the notation and select a default language. • Diagram - Can customize features specific to display of Rose diagrams. • Let’s talk about the Stereotype display of this tab. 13 of 24

  20. Rational Rose 2000 Interface • The Stereotype display • Click on Use Case View; Main; (2C) • Actor from toolbar; • Put into diagram; • Select <<actor>>; • right click for Open Specification… • This option lets you select how you want stereotypes to appear on your diagrams. 13 of 24

  21. Rational Rose 2000 Diagrams • Diagrams- • the means to view the system’s building blocks: classes, interfaces, collaborations, components, nodes, dependencies, generalizations, and associations. • Eight diagrams can be modeled in Rose. • Will use four for Requirements Gathering, Analysis and Design. • We will be dealing with these quite a bit. • Use Case • Collaboration • Sequence • Class • We will briefly discuss the other remaining four on the following slides. 13 of 24

  22. Basic Tool Techniques Add Model Elements • Either the browser or diagram toolbar. • Browser: Right click on Use Case Diagram; Select New; Select Model element. • Toolbar: Double Click element; Place on diagram window; document…(See browser) • Elements added from the toolbar are automatically added to the browser. • Elements added to the browser must be dragged and dropped on to the diagram. • You can also drag and drop existing elements from the browser to other diagrams. 13 of 24

  23. Basic Tool TechniquesDelete Model Elements • Deleting from a diagram • Removes the selected icon from the current diagram BUT does not change the model unless: • Deleted icon is unnamed, or • Icon appears once in the current diagram and in no other diagram. • Note that all relationships associated with the deleted element are also deleted. • Delete from a diagram • Click the element in the diagram, then press Delete on your keyboard. • Click the element in the diagram. From the Edit menu, click Delete. • Delete from the browser • Removes the selected element from the model. • Removes all icons representing the element from all diagrams on which they appear. • Other ways too. 13 of 24

  24. Basic Tool TechniquesRight Clicking – Short Cut Menu • The right-click feature • Displays actions that can be taken on the selection. • Is the alternative to selecting from the standard menu bar. • Can be used for all toolbars, diagram elements, browser and browser elements, and documentation window 13 of 24

More Related