Customizing

1. Customizing custom

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

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

4. Docked Browser

5. Floating Browser

6. Docked Documentation Window

7. Floating Documentation Window

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

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

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

11. Component and Deployment Diagrams

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

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

14. Main Component Diagram Example

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

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

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

18. Deployment Diagram Example

19. Database DBProcess 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

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

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

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

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

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

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

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