1
Rational Rose Basics
Visual Modeling Textbook – Chapter 3
Original Notes from Rational Software
Corporation – modified considerably
for instructional purposes
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.
Rose uses a common vocabulary, the Unified
Modeling Language (UML).
3
Models
Models themselves are constructed using different views and 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…
E.g. Logical View contains analysis model, business object model, design model (Sometimes models can contain ‘views’ too…)
–
Models generally contain a number of diagrams – some of these terms are
‘used’ interchangeably…
E.g. Design model contains class diagrams, sequence diagrams, and a number of others….
Diagrams: means by which we view of the system.
–
Different building blocks (model elements) for different types.
–
E.g.: classes, interfaces, collaborations, components, nodes, dependencies, generalizations, and associations.
The 4 + 1 Architectural Views: how they work in Rose.
4
Process View Deployment View Logical View
Use-Case View
Implementation View
End-user Functionality
Programmers Software management
Performance Scalability Throughput
System integrators
System topology Delivery, installation communication System engineering Analysts/Designers
Structure / Behaviors
Very Important: 4 + 1 Architectural View
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. Central!!
Used for requirements capture and analysis…and much,
much more
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 and more.
It can also include state-chart and activity diagrams. – discuss.
Much analysis and design involve packages and models in this view.
–
In fact, ‘most’ analysis and design in done here…
–
Most requirements done in Use Case View
Much of this work is done during the Elaboration Phase
and some in the Construction Phase.
7
4+1 Architectural View = in 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 of
software 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…)
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.
(Sometimes the ‘non-functional’ requirements are 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 is an architectural View not a development Phase!
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.
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.
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.
I like these because you can normally show ALL the paths in a use case with a single Activity Diagram.
Some Modelers prefer Activity Diagrams to some of the others…
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 implicitly triggered 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
12
Component View
Component Diagrams:
Sometimes called the Implementation View Contain:
source code (e.g., .cpp, …) .dlls
.exes .h files .java files . others….
Typically configured into packages of source
code modules, data base entities, tables,
files, etc.
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
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.
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 appropriate specification selected in the main
diagram (modeling) window.
16
Your model is Really in HERE!
Diagram Window
Documentation Window Browser Window
Diagram Toolbar
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.
18
The Rational Rose 2000 Interface
The Specification window – (right click on Use Case View 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. (See next slide)
The Log window – (down at very bottom)
Reports progress, results, and errors
Right-click on Log window to see available actions.
(See two slides down)
19
20
21
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 set up our toolbar for whatever models we wish to develop.
22
Customizing Individual Toolbars for Modeling Use Cases…(1 of 2)
Getting the Use Case toolbar set up:
1. View, Configure, Toolbars
2. Select ‘Use Case Diagram’ (down near the bottom)
1.
Produces another window – ‘Customize Toolbar’
2.
Select the Add button for Use Case Diagrams
1.
This adds the Browse Use Case Diagram icon on menu bar.
2.
This also enables the Use Case Diagram toolbar to become active when you want to model use cases (by selecting the Browse Use Case Diagram button on menu bar.
3.
Can return later via view, configure, toolbars, Use Case
diagram, to add toolbar buttons into the current toolbar options
for this (or any other) type of model.
23
Customizing Individual Toolbars for Modeling Use Cases…2 of 2
Select Browse (Select) Use Case Diagram from icon on Menu Bar
–
Tool Bar is made active.
Select use case model entities
–
1. Select model element from toolbar
Click to select model element (get crosshairs)
Place in diagram window by clicking at desired location
Label it (use case) immediately or the use case icon later by replacing the use case name in Name space with the desired name of the use case in Use Case specification window. Click off. OR
–
2. Right click on Use Case View, New, Use Case
This adds a Use Case in your Browser (hence in your model).
Name it right away or,
– Double click this in your browser and name the use case via the Name space in the specification window (same process as above).
Select and drag the Use Case icon in the Browser onto the diagram window.
NB: deleting a model element from the diagram window DOES NOT remove the element from the model! You must go to the Browser to remove the model element.
Restrictions are discussed in slides ahead. BE CAREFUL!
24
Rational Rose 2000 Diagrams
To build any model, ensure you select the Browse icon in the menu bar or Select the Browse menu and select the type of model you wish to develop.
Clicking ok to the desired model choice activates the toolbar for ‘that’ model. -
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.
25
Basic Tool Techniques Add Model Elements
Either the browser or model diagram toolbar (assuming appropriate toolbar is activited).
–
Browser: Right click on Use Case Diagram; Select New; Select Model element.
–
Toolbar: Double Click element; Place on diagram window; document…
(See browser)
–
Name the model element, like Administrator for an Actor.
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.
26
Basic Tool Techniques Delete Model Elements
Deleting from a model 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.
– Note: model element is STILL in the browser (hence, the model)
Delete from the browser
– Right click model element; get short-cut menu; press delete with left click
– Removes the selected element from the model.
– Removes all icons representing the element from all diagrams on which they appear.
– Other ways too.
