Customizing custom

Creating documents in Rose Reports Show usage Show instances Show Participants in Use Case Documentation Report Show access violations Tools: Check Model

User interface changes Tools:Option updates the .rose.ini file so the settings you create are used for every model you open Fonts Diagram options Toolbars Window menu changes only the current session tiles, cascade, arrange icons View: Notation to change notation for this session only Edit: Change line style to change lines for this session only Change icons displayed on drawing palette At bottom of icon bar, use right mouse button, and select Customize

Docked Browser

Floating Browser

Docked Documentation Window

Floating Documentation Window

Adding to the menus In the .rose.ini file, add to the menus path a pointer to your menu file See the sample cm integration menu file for an example You can add to the Tools menu and the File:Units menu

The .rose.ini file This stores information particular to one user Code generator and analyzer Menu customizations Virtual path maps These things are generally updated through the menus in Rose We will see an example of editing the .rose.ini file in the multi-user section of the course

Rose scripts Rose comes delivered with an API that allows read and write access to Rose models The API is accessed through scripts written in Summit Basic Use Tools:Open Scripts or Tools: New Script to bring up a script editor Sample scripts are delivered with Rose Scripts can be run from the editor window (interpret mode) Scripts can also be compiled into executables This is how they can be called from other scripts or from menus The compiler is not delivered as an executable Run the interpreter on the compiler to compile itself into an executable

Component and Deployment Diagrams

Moving From Logical Modeling to Physical Modeling Physical views Component View Depicts packages, components, and their relationships There can be any number of component diagrams in a Rose model Deployment View Shows the relationship between nodes There can only be one deployment diagram in a Rose model

The Main Component Diagram The component model initially contains one component diagram This diagram is called Main The main component diagram is a view of the high level packages in the logical model Each package is a collection of components Dependencies between packages are shown using the dependency relationship Packages in the component diagrams roughly correspond to directories in a file system (or subsystems in Apex) Components roughly correspond to files in a file system

Main Component Diagram Example

Additional Component Diagrams Each package in the main Component Diagram will contain one or more component diagrams Elements of the component diagrams Application (EXE, a.out) Application extension (DLL, .so) Module (header file) Module body (cpp, C file)

Assigning Logical Elements to Components Packages in the logical view are mapped to packages in the component view Classes in the logical view are mapped to components in the component view Hint: Use drag and drop in the browser to make the assignments

The Deployment Model The deployment view shows The available communication paths between the nodes in the system The allocation of processes to nodes The deployment view contains ONE diagram

Deployment Diagram Example

Processes A process is the execution of one thread of control A large system can be broken into multiple processes or threads of control A process executes on a node Process names may be displayed on the Deployment Diagram Database DBProcess

Scheduling The type of process scheduling used by a processor may be specified in a Process Diagram Preemptive (default) - high priority processes can preempt lower-priority processes that are currently executing Nonpreemptive -- current process continues to execute until it relinquishes control Cyclic -- control passes from one process to another Executive -- an algorithm controls process scheduling Manual -- processes are scheduled by the user outside of the system

Exercise<skip>: Additional Logical Packages Add the following packages to the logical view Database, Foundations, and Error Handling The Error Handling and Foundations packages are global packages Add the following dependencies Database depends upon University Artifacts Database depends upon People

Exercise <skip>: Interaction with Architecture Classes Update the 揅reate a Course?Scenario to show the interaction of the classes with the new database classes as shown on the following page

Exercise <skip>: Component Packages Create the following component packages User Interface, Registration System, Database, Foundation Classes, and Errors Create the following dependencies on the Main Component Diagram User Interface depends upon Registration System User Interface depends upon Database Database depends upon Registration System User Interface, Registration System and Error depend upon Foundation Classes User Interface, Registration System and Database depend upon Errors

Exercise <delay>: Mapping Logical Packages to Component Packages Map the logical packages to component packages as shown: Logical Package Component Package People People University Artifacts University Interfaces User Interface Foundations Foundation Classes Database Database Error Handling Errors

Exercise <skip/delay>: Mapping Classes to Components Map the following classes to components registrationUser -> regusr student ->stud

Exercise <skip>: Deployment Diagram Create the Deployment Diagram Nodes Main Computer, Dorm, Library, Main Building, Database Connections Main Computer to Dorm Main Computer to Library Main Computer to Main Building Main Computer to Database