whitepapers - a rational approach to software development using rational rose 4_0.htm

dmbs project which we did in our cs class which creates a simple database

          <LI>Maintain curriculum. </LI></UL></LI></UL>
      <H3><A name="Drawing Use Case"></A><B>Drawing a Use Case Diagram in 
      Rational Rose</B></H3>
      <P>The use case diagram is contained within a class diagram in the use 
      case view of the tool. Actors are shown as stickmen and use cases are 
      shown as ovals. The use case diagram is shown in Figure 5.</P>
      <P align=center><IMG height=227 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig5.gif" 
      width=432 align=bottom border=0></P>
      <P align=center><B><I>Figure 5 Use Case Diagram</I></B></P>
      <P>A brief description is created for each use case. The brief description 
      is entered in the Documentation field of the use case specification in the 
      tool. The brief description of each use case follows:</P>
      <UL type=square>
        <LI>Register for courses 
        <UL type=square>
          <LI>The use case is started by the student. It provides the capability 
          to create, review, modify, and delete a course schedule for a 
          specified semester. All pertinent billing information is sent to the 
          Billing System. </LI></UL>
        <LI>Request class roster 
        <UL type=square>
          <LI>This use case is started by the professor. It provides the 
          capability to request a printed list of all students assigned to a 
          specified course offering. </LI></UL>
        <LI>Select courses to teach 
        <UL type=square>
          <LI>This use case is started by the professor. It provides the 
          capability to select, review, modify, and delete a list of courses to 
          teach for a specified semester. </LI></UL>
        <LI>Maintain professor information 
        <UL type=square>
          <LI>This use case is started by the registrar. It provides the 
          capability to create, review, modify, and delete professor 
          information. </LI></UL>
        <LI>Maintain student information 
        <UL type=square>
          <LI>This use case is started by the registrar. It provides the 
          capability to create, review, modify, and delete student information. 
          </LI></UL>
        <LI>Maintain curriculum 
        <UL type=square>
          <LI>This use case is started by the registrar. It provides the 
          capability to create, review, modify, and delete a list of course 
          offerings for a given semester. </LI></UL>
        <LI>Generate catalogue 
        <UL type=square>
          <LI>This use case is started by the registrar. It provides the 
          capability to generate a catalogue containing a list of course 
          offerings for a specified semester. </LI></UL></LI></UL>
      <P>During Inception, the flow of events (including any identified 
      alternate flows) for the most important use cases is documented.</P>
      <P>In Rose 4.0, the flow of events is entered via a link to an external 
      document. The flow of events for the Register for Courses use case is 
      shown below.</P>
      <P><B>Flow of Events: Register for Courses Use Case</B></P>
      <P>This use case begins when the student enters the student id number. The 
      system verifies that the student id number is valid and prompts the 
      student to select the current semester or a future semester. The student 
      enters the desired semester. The system prompts the student to select the 
      desired activity:</P>
      <UL type=square>
        <LI>Create a schedule. 
        <LI>Review a schedule. 
        <LI>Change a schedule: 
        <UL type=square>
          <LI>Delete a course. 
          <LI>Add a course. </LI></UL></LI></UL>
      <P>The student indicates that the activity is complete. The system will 
      print the student schedule and notify the student that registration is 
      complete. The system sends billing information for the student to the 
      billing system for processing.</P>
      <P><B>Alternate flow</B></P>
      <P>If an invalid id number is entered, the system will not allow access to 
      the registration system.</P>
      <P>If an attempt is made to create a schedule for a semester where a 
      schedule already exists, the system will prompt for another choice to be 
      made.</P>
      <P><B>Create a Schedule</B></P>
      <P>The student enters 4 primary course offering numbers and 2 alternate 
      course offering numbers. The student then submits the request for courses. 
      The system then:</P>
      <OL>
        <LI>Checks that prerequisites are satisfied for the requested course. 
        <LI>Adds the student to the course offering if the course offering is 
        open. </LI></OL>
      <P><B>Alternate flow</B></P>
      <P>If a primary course offering is not available, the system will 
      substitute an alternate course offering.</P>
      <P><B>Review a Schedule</B></P>
      <P>The student requests information on all course offerings in which the 
      student is registered for a given semester. The system displays all 
      courses for which the student is registered including course name, course 
      number, course offering number, days of the week, time, location, and 
      number of credit hours.</P>
      <P><B>Change Schedule - Delete a Course</B></P>
      <P>The student indicates which course offerings to delete. The system 
      checks that the final date for changes has not been exceeded. The system 
      deletes the student from the course offering. The system notifies the 
      student that the request has been processed.</P>
      <P><B>Change Schedule - Add a Course</B></P>
      <P>The student indicates which course offerings to add. The system checks 
      that the final date for changes has not been exceeded. The system 
then:</P>
      <OL>
        <LI>Verifies that the maximum course load for the student has not been 
        exceeded. 
        <LI>Checks that prerequisites are satisfied for the requested course. 
        <LI>Adds the student to the course offering if the course offering is 
        open. </LI></OL>
      <H2><A name="Elaboration Phase2"></A><B>The Elaboration Phase</B></H2>
      <P>During Elaboration, some of the most important and critical use cases 
      are implemented. During this phase, the focus is good class structure and 
      architecture. 
      <H3><A name="Development Scenarios"></A><B>Development of 
      Scenarios</B></H3>
      <P>Each use case is a web of scenarios. Scenarios are documented using 
      Sequence Diagrams. Objects are represented as vertical lines and messages 
      between objects are shown as directed horizontal lines. Sequence diagrams 
      are drawn in the Use Case View of the tool. The Sequence Diagram for the 
      Add a Course scenario is shown in Figure 6.</P>
      <P align=center><IMG height=278 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig6.gif" 
      width=432 align=bottom border=0></P>
      <P align=center><B><I>Figure 6 Sequence Diagram for the Add a Course 
      Scenario</I></B> 
      <H3><A name="Creating Real World"></A><B>Creating "Real World" or 
      "Business" Classes</B></H3>
      <P>Objects are discovered by examining the use cases and scenarios and 
      grouped into classes. Each class should have a definition which states the 
      purpose of the class. Packages are created to hold logical groups of 
      classes. Classes and packages are drawn in the Logical View of the tool. 
      The following packages and classes have been created for the registration 
      system:</P>
      <UL type=square>
        <LI>People 
        <UL type=square>
          <LI>StudentInfo--Information about the student actor needed by the 
          registration system (for example, name, address, phone, idNumber, 
          major, gradDate). 
          <LI>ProfessorInfo--Information about the professor actor needed by the 
          registration system (for example, name, address, phone, idNumber, 
          tenureStatus). </LI></UL>
        <LI>UniversityArtifacts 
        <UL type=square>
          <LI>Course--General information about selections for a semester (for 
          example, name, description, creditHours). 
          <LI>CourseOffering--Specific information about selections for a 
          semester (for example, daysOffered, timeOfDay, location). 
          <LI>StudentSchedule--Output report containing the list of registered 
          course offerings generated when a student registers for a course. 
          <LI>CourseRoster--Output report containing the list of registered 
          students for a specific course offering generated for a professor. 
          </LI></UL>
        <LI>Interfaces 
        <UL type=square>
          <LI>RegistrationForm--Form which provides the capability for a student 
          to select registration options. 
          <LI>Add/DropForm--Form which provides the capability for a student to 
          modify a course schedule. 
          <LI>CourseSelectionForm--Form which provides the capability for a 
          professor to add/drop courses to teach. 
          <LI>StudentMaintenanceForm--Form which provides the capability for the 
          registrar to add/delete/modify student information. 
          <LI>ProfessorMaintenanceForm--Form which provides the capability for 
          the registrar to add/delete/modify professor information. 
          <LI>CourseMaintenanceForm--Form which provides the capability for the 
          registrar to add/delete/modify course and course offering information. 
          </LI></UL></LI></UL>
      <P>Class diagrams are created to graphically depict the packages and 
      classes in the model. The Main class diagram typically contains only 
      packages. Each package contains its own class diagrams. The Main class 
      diagram for a package contains the public classes of the package (classes 
      that communicate with classes in other packages). Other class diagrams are 
      created as needed. Class diagrams are contained in the Logical View of the 
      tool.</P>
      <P>Use cases and scenarios are examined to determine the relationships 
      needed by the system. Relationships between classes are created and 
      displayed on selected class diagrams.</P>
      <P>Attributes (structure) and operations (behavior) are added to the 
      classes to carry out the functionality specified in the use cases.</P>
      <P>Sequence diagrams are updated to show the allocation of objects to 
      classes and the replacement of messages with operations.</P>
      <P>Some class diagrams for the Registration System are shown in Figures 7 
      through 11. An updated sequence diagram is shown in Figure 12.</P>
      <P align=center><IMG height=265 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig7.gif" 
      width=432 align=bottom border=0></P>
      <P align=center>