Rational Rose 4.0 Demo Walkthrough
This first part of this demo scenario walks you through the modeling capabilities of Rational Rose 4. The second part of the walkthrough covers C++ round-trip engineering.
|
Text |
Rational Rose 4.0 Action |
| Review the windows in the Rational Rose 4.0 Diagram, Browser, and Documentation windows | See the Browser and Documentation windows. Visibility of the windows is controlled by the View menu. |
| We are going to model a course registration system for a university. | Open the browser and see the views: use-case view, logical view, component view, and deployment view. |
| The first step is the identification of the actors. There are four actors: Professor, Student, Registrar, and the Billing System. | Create the actors in the use-case view of the browser. Enter their documentation using the Documentation window. |
| Next, use cases are developed for each of the actors. For this system, some of the use cases are: Maintain Curriculum, Register for Courses, and Select Courses to Teach. As analysis progresses, more use cases will be developed. | Create the use cases in the use-case view of the browser. |
| Each use case contains a description of the major flow of events and any alternate flow of events. The description should describe the functionality of the system that is performed when the use case is executed. | See how a use-case description is created. Select the Maintain Curriculum use case and enter a few lines of the description.
"This use case is initiated by the Registrar actor. It provides the capability to maintain the curriculum for the semester" |
| To further describe a use case, you can link in descriptions from external files, such as Microsoft Word document files. You can also link in other types of files, such as test scripts, GUI mock-ups, and so on. |
Double-click on a use case, and select the Files tab. Right-click and select "Insert file...". You can also drag-and-drop a file from your File Manager.
Double-click on this file and bring up the external document in its application. |
| It is often useful to create a use-case diagram. This diagram is a graphical picture of the use cases, the actors, and the interactions between them. | Open the Main diagram in the use-case view of the browser.
Select each actor and drag it onto the diagram. Select each use case and drag it onto the diagram. |
| Relationships are shown between the actor and the use cases that it interacts with. A use case can also interact with another use case. In our system, the Student interacts with the Register for Courses use case, which in turn sends information to the Billing System. The Professor interacts with the Request Courses to Teach use case and the Registrar interacts with the Maintain Curriculum use case. | Draw the relationships on the use-case diagram:
Student to Register for Courses Register for Courses to Billing System Registrar to Maintain Curriculum Professor to Select Courses to Teach |
| A scenario is an instance of a use case. It is often useful
to depict the flow of events for a use case graphically in a sequence diagram.
The diagram is made up of the objects in the scenario along with the messages
between the objects in the scenario.
One scenario for the Maintain Curriculum use case is the ability to create a new course. |
Create a new sequence diagram called Create a Course
in the use-case view.
Open the diagram by double-clicking on the diagram in the browser. |
| We are now going to graphically depict the scenario. This use case is started by the Registrar. | Drag the Registrar actor onto the sequence diagram. |
| The Registrar must ask the system to allow him to create a new course. This is done using a course form. The first step is to open the form. | Create a new object and call it Course Form.
Create a message between the Registrar and the form and call it open. |
| Next, the Registrar must enter the appropriate information on the form. | Create the set info message between the Registrar and the form. |
| The form is then submitted to the system for processing. | Create the Submit for Processing message between the Registrar and the form. |
| The next step is the creation of the new course. | Create a new object and give the object a name, Sales 101. Create the new course message between the form and the course object. |
| Once the course is created, it must be saved for future use. | Create the message Save between the form and the course object. |
| The use case is complete. | Create the message Course Created between the form and the Registrar. |
| This is only one scenario. There are many more. As analysis continues, the scenarios are created and optionally graphically displayed in a sequence diagram. | |
| The next step in the lifecycle involves the logical view of the model. Classes are created to hold the objects identified in the use-case view. Remember, a class is a collection of objects with the same structure, behavior, and relationships. | Create the following classes in the browser: StudentInfo, Course, ProfessorInfo, StudentSchedule, BillingInterface, and NewCourseForm |
| Each class should be defined. The definition should explain the purpose of the class in the system and not the structure of the class. | Use the Documentation window to describe the Course class.
"A course is an offering of the University for a given semester." |
| There are many classes in a system. It is often useful (and necessary) to group the classes into packages. A package is a logical collection of classes. We have identified the following packages for the university system: UniversityArtifacts and Interfaces. | Create the packages in the browser. |
| After the packages are created, classes are relocated to the appropriate package. | In the browser, drag each class to the appropriate package.
UniversityArtifacts: StudentInfo, ProfessorInfo, Course and StudentSchedule Interfaces: BillingInfo and NewCourseForm |
| A class diagram is a graphical representation of the packages and classes in the system. The Main class diagram typically contains the high-level packages in the system. | Open the Main diagram of the logical model.
Drag the packages to the diagram. |
| Each package also contains a Main diagram. This diagram usually shows the public classes of the model -- those classes that communicate with classes in other packages. | Double-click on the UniversityArtifacts package to create the Main diagram. Drag the StudentInfo, ProfessorInfo, Course and StudentSchedule classes onto the diagram. |
| Once the classes for a model are created, the sequence diagrams are updated to assign the objects to classes in the system. | Open the Create a Course sequence diagram. Assign classes to the objects in the diagram by dragging the classes onto the objects in the sequence diagram. |
| A class contains structure and behavior. The behavior of a class is shown by its set of operations. Operations are initially created using the sequence diagrams developed in the use-case view. | Create operations for each message between the NewCourseForm and the Course in the Create a Course scenario. |
| When operations are created using the sequence diagram, the operations are automatically added to the class. | Expand the Course class in the browser to show that the operations are added to the class. |
| Another class diagram can be created to show the detail of a class or a group of classes. | Create another class diagram called Schedule Details. Open the diagram and drag the StudentSchedule class onto it. |
| Operations can also be created independently of sequence diagrams. | Click-right to select the StudentSchedule class and insert a new operation called change(). |
| Rational Rose uses a model-view-controller architecture. There is one underlying component in the model and many views of the component. This is important, because you do not want to make changes to a component on every view that contains the component. | Go back to the Main diagram for the UniversityArtifacts package and see that the new operation for the StudentSchedule class is visible. |
| Attributes are properties or characteristics of a class. They typically do not contain any identity. They are discovered by examining the use cases, requirements, and class definitions, by interviewing users/customers, and applying domain knowledge. | Create the following attributes for the StudentSchedule class: dateUpdated, semester. See that the attributes are visible on the class diagrams.
Create the following attributes for the StudentInfo class: name, IDNumber, and major. Create the following attributes for the ProfessorInfo class: name, IDNumber, and tenureStatus. |
| In addition to attributes and operations, a class contains relationships to other classes. These relationships are discovered by examining the use cases and scenarios developed for the system. Relationships are created on class diagrams. The NewCourseForm "talks" to the Course class. This relationship is modeled as an association. | Go to the Main diagram for the UniversityArtifacts package. Drag the NewCourseForm class onto the diagram, and create an association between the NewCourseForm and the Course classes. |
| Another type of relationship is an aggregation. An aggregation is a stronger form of an association: It is a relationship between a whole and its parts. | Create a new class in the UniversityArtifacts package called Curriculum. Drag the class onto the diagram and create an aggregation between Curriculum (whole) and Course (part). |
| As relationships are added, multiplicity indicators are also added. Multiplicity tells how many objects participate in a relationship. | Add multiplicity to the relationships.
One NewCourseForm object creates exactly one Course object. One Course object is created by exactly one NewCourseForm object. One Curriculum object is made up of one or more Course objects. One Course object is part of exactly one Curriculum object. |
| Another type of relationship typically found during analysis is an inheritance relationship. Inheritance shows the relationship between a superclass and a subclass. The StudentInfo and ProfessorInfo classes both have attributes of name and IDNumber. A superclass can be created to hold this common information. | Open the Main diagram of the UniversityArtifacts package. Use the toolbar to create a new class called RegistrationUser. In the browser, select the name attribute of the StudentInfo class and drag it to the new class.
Select the IDNumber and drag it to the new class. In the ProfessorInfo class, delete the name and IDNumber attributes. Draw the inheritance relationship. |
| The process of finding objects, classes, attributes, operations, and relationships continues. You will reach the law of diminishing returns that says you can always find one more scenario but it does not provide any new classes, operations, or behavior. | |
| Next, we move into architectural design. Good object-oriented systems are made up of layers. The layers represent the architectural framework of the system. A package is created for each architectural component. For the course registration system, add the following architectural package: Database. | Create the package and add it to the Main class diagram of the logical view. |
| Classes are added to the architectural packages to carry out the functionality needed for this architectural solution. For example, one strategy for mapping classes to a relational database involves the use of a transaction manager and database classes for each class that contains persistent objects. | Open the Database package and add the following classes: TransactionManager, DBCourse, DBStudent, and DBProfessor. Add the following association relationships: TransactionManager to DBCourse, DBStudent, and DBProfessor. |
| Certain packages are global packages, classes in the package that are used by classes in all or most of the other packages. These packages are marked as global. | Make the Database package global. |
| Scenarios are updated to show the interaction of the domain classes with the classes added during this phase. | Open the Create a Course sequence diagram. Add
the TransactionManager class and the DBCourse class.
Delete the Save message between the form and the course. Add the following relationships and operations: Form to TransactionManager saveCourse() TransactionManager to DBCourse saveCourse() DBCourse to Course getInfo() |
| As the sequence diagrams are updated, it is sometimes necessary to update operations and relationships on the class diagram. | Delete the save() operation on the Course class. |
| During design, data types for attributes are assigned and operation signatures are finalized. | Select the StudentSchedule class. Assign a data type to each attribute and an operation signature to each operation. |
| Association and aggregation navigation is also determined at this time. During analysis, associations and aggregations are bi-directional relationships. During design, they may become uni-directional. | Make the association between NewCourseForm and Course uni-directional (NewCourseForm to Course) and make the aggregation between Curriculum and Course uni-directional (Curriculum to Course). |
| During design, the physical nature of the system is also developed. Physical packages (subsystems) are created and displayed in the component view of the model. | Using the browser, create the following component packages: RegistrationSystem and Database. |
| Each logical package is mapped to a physical package. | Using the browser, map the logical package to the physical
package by dragging the logical package onto the physical package.
UniversityArtifacts and Interfaces to RegistrationSystem Database to Database |
| Each class is mapped to a module. A module is considered to be a compilation unit. | Open the RegistrationSystem package and create a module called Course. Map the Course class to the Course module. |
| Finally, a deployment diagram containing the nodes and connections between the nodes in the system is created. | Open the Deployment diagram and create the following nodes:
Registration, Database, Dorm, Main Building, and Library.
Create the following connections: Registration to Database, Dorm, Main Building, and Library |
| The Rose model for the steps above can be found in the model demo1.mdl. | |
| This next part takes you through C++ round-trip engineering. Rational Rose uses a robust set of code generation properties that provide the capability for the user to specify how the code should be generated. Long file names are a property of the Project property set. The default is 8 characters. To change this, the property must be edited. | De-select all model elements. Select the Tools:Properties:Edit Properties menu choice. Select the cg tab. Select Project from the Type pull-down menu. Select the File Name Format property and click the Edit Value button. Enter 32 and click the End Edit button. Click the OK button to apply the change. To perform code generation, select the packages and classes for which you want to generate C++ code, and invoke the code generator. |
| Rational Rose finds a number of warnings that it logs indicating that there are pieces missing for generating correct C++ code. Rational Rose makes some assumptions to generate correct C++ code anyway. You can review these assumptions in the log file. | Open the Main diagram in the UniversityArtifacts package. Select the StudentSchedule class and invoke Tools:C++:Code Generation.
Press Ctrl+H to browse to the generated header file. Ctrl+K would take you to the body file. By default this brings up Notepad, but you can set your preference to the editor of your choice. |
| You can now edit your source code. Add a new member function status that returns status information on the StudentSchedule. | In your studentschedule.h file, add:
int status (); in the public section just before the private section starts |
| Start the C++ analyzer. The analyzer is used to analyze C++ code and export it to Rational Rose.
You can also set a number of options in the Analyzer. |
Invoke Tools:C++: Reverse Engineering.
Hold down the Shift key and select File:New. This will start a new project to anlayze with default settings. Select Directories and select the directory where you have generated the source code, such as: c:\program files\rational\rational rose c++ 4.0\RegistrationSystem Select Files, select studentschedule.h, and click OK. |
| You can now analyze the code to be able to bring it back into Rational Rose/C++. | Select the studentschedule.h file in the file list and invoke Action:Analyze.
Select Action:Analyze. This will parse the code and report any illegal C++ constructs or missing files. The warnings and errors can be viewed in the log. After the analysis, invoke Action:Export to Rose.... This will bring up a dialog to choose from a number of different options. Change the Option Set to Round Trip, because you have already generated code for this class and now want to update your model. Click OK. This will export a file called studentschedule.red. |
| Update your Rational Rose model. | Go back into Rational Rose and invoke File:Update.
Select the studentschedule.red file and start the update of your model. You will now see how your changes are merged into your model. This completes the C++ round-trip engineering portion of the demo. |
| The Rose model for the steps above can be found in the model demo2.mdl. | |