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

        <P>1. Identifying the classes and relationships to be implemented.<BR>2. 
        Completing the design for the selected classes and relationships: 
      </P></BLOCKQUOTE>
      <UL type=square>
        <UL type=square>
          <LI>Data types for attributes. 
          <LI>Operation signatures. 
          <LI>Addition of other operations (for example, access, management, 
          helping operations). 
          <LI>Addition of implementation level classes (for example, container 
          and controller classes). 
          <LI>Specification of association/aggregation design decisions (for 
          example, navigation and containment decisions). 
          <LI>Specification of inheritance design decisions (for example, 
          abstract classes and virtual inheritance). </LI></UL></UL>
      <BLOCKQUOTE>
        <P>3. Creating the code for the iteration.<BR>4. Creating/updating the 
        documentation for the iteration.<BR>5. Testing the iteration: 
      </P></BLOCKQUOTE>
      <UL type=square>
        <UL type=square>
          <LI>Does it perform the functionality specified in the use cases 
          implemented in the iteration? </LI></UL></UL>
      <BLOCKQUOTE>
        <P>6. Integrating and testing the iteration with any previous 
        iterations. </P></BLOCKQUOTE>
      <P><BR>The process of building iterations continues until the software 
      product is complete. 
      <H2><A name=Transition></A><B>Transition</B></H2>
      <H3><A name="Transition Phase"></A><B>The Transition Phase 
      Activities</B></H3>
      <P>The purpose of the Transition Phase is to deploy the software product 
      into the user community and train the users. This phase typically starts 
      with a <I>beta</I> release of the software product to selected users. 
      Typically problems are discovered in the beta release and corrected in 
      subsequent beta releases. After the beta period is complete, the product 
      is released to the community.</P>
      <P><A name=1Booch_OMT></A><SUP>1</SUP> Rational Software Corporation and 
      Lockheed Martin. <I>Succeeding With the Booch and OMT Methods. </I>Redwood 
      City, Cal<I>i</I>f.: Addison-Wesley, 1996.<BR><A 
      name=2Objectory></A><SUP>2</SUP> Rational Software Corporation. <I>The 
      Objectory Process - Introduction.</I> 1996.<BR><A 
      name=3OOSoftware></A><SUP>3</SUP> Jacobson, Ivar. <I>Object-oriented 
      Software Engineering.</I> Redwood City, Calif.: Addison-Wesley, 
      1992.<BR><A name=4ObjectSolutions></A><SUP>4</SUP> Booch, Grady. <I>Object 
      Solutions</I>. Redwood City, Calif.: Addison-Wesley, 1995.<BR><A 
      name=5Ibid></A><SUP>5</SUP> Ibid.<BR><A 
      name=6SoftwareArchitecture></A><SUP>6</SUP> Kruchten, Philippe. Software 
      Architecture and Iterative Process. Santa Clara, Calif.: Rational Software 
      Corporation, 1994.<BR><A name=7ObjectSolutions></A><SUP>7</SUP> Booch, 
      Grady. <I>Object Solutions</I>. Redwood City, Calif.: Addison-Wesley, 
      1995<BR><A name=8Ibid></A><SUP>8</SUP> Ibid.<BR><A 
      name=9Succeeding></A><SUP>9</SUP> Rational Software Corporation and 
      Lockheed Martin. <I>Succeeding With the Booch and OMT Methods. </I>Redwood 
      City, Calif.: Addison-Wesley, 1996.</P></FONT><BR>
      <P><FONT size=-1>
      <P>
      <H2 align=center><A name=chap3>Chapter 3</A></H2>
      <H2 align=center>Case Study<BR></H2>
      <BLOCKQUOTE>
        <P><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Case Study"><B>Case 
        Study Background</B></A><B><BR></B><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Course Registration"><B>Course 
        Registration System Problem Statement</B></A><B><BR></B><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Role Tools"><B>The 
        Role of Tools</B></A><B><BR></B><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Project Summary"><B>Project 
        Summary</B></A><B><BR></B><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Inception Phase2"><B>The 
        Inception Phase</B></A></P>
        <BLOCKQUOTE>
          <P><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Business Goals">Business 
          Goals and Needs</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Definition Actors">Definition 
          of Actors</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Definition Use Cases">Definition 
          of Use Cases</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Drawing Use Case">Drawing 
          a Use Case Diagram in Rational Rose</A></P></BLOCKQUOTE>
        <P><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Elaboration Phase2"><B>The 
        Elaboration Phase</B></A></P>
        <BLOCKQUOTE>
          <P><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Development Scenarios">Development 
          of Scenarios</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Creating Real World">Creating 
          "Real World" or "Business" Classes</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Software Architecture">Software 
          Architecture</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Iteration Planning">Iteration 
          Planning</A></P></BLOCKQUOTE>
        <P><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Construction Phase"><B>The 
        Construction Phase</B></A></P>
        <BLOCKQUOTE>
          <P><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Construction Activities">Construction 
          Activities</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Building Iteration2">Building 
          an Iteration</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Transition Phase2">The 
          Transition Phase</A><BR></P></BLOCKQUOTE></BLOCKQUOTE>
      <H2></H2>
      <H3><A name="Case Study"></A><B>Case Study Background</B></H3>
      <P>Course registration at the local university is currently done by hand. 
      Students fill out forms that contain their course selections and return 
      the forms to the registrar. Clerks then enter the selections into a 
      database and a process is executed to create student schedules. The 
      registration process takes from one to two weeks to complete.</P>
      <P>The university decided to investigate the use of an online registration 
      system. This system would be used by professors to indicate the courses 
      they would teach, by students to select courses, and by the registrar to 
      complete the registration process. 
      <H2><A name="Course Registration"></A><B>Course Registration System 
      Problem Statement</B></H2>
      <P>At the beginning of each semester students may request a course 
      catalogue containing a list of course offerings for the semester. 
      Information about each course, such as professor, department, and 
      prerequisites will be included to help students make informed 
      decisions.</P>
      <P>The new on-line registration system will allow students to select four 
      course offerings for the coming semester. In addition, each student will 
      indicate two alternative choices in case a course offering becomes filled 
      or canceled. No course offering will have more than ten students. No 
      course offering will have fewer than three students. A course offering 
      with fewer than three students will be canceled. Once the registration 
      process is completed for a student, the registration system sends 
      information to the billing system, so the student can be billed for the 
      semester.</P>
      <P>Professors must be able to access the on-line system to indicate which 
      courses they will be teaching. They will also need to see which students 
      signed up for their course offering.</P>
      <P>For each semester, there is a period of time that students can change 
      their schedules. Students must be able to access the on-line system during 
      this time to add or drop courses. The billing system will credit all 
      students for courses dropped during this period of time. 
      <H2><A name="Role Tools"></A><B>The Role of Tools</B></H2>
      <P>Any software development method is best supported by a tool. This book 
      uses the tool Rational Rose 4.0. Rational Rose is organized around the 
      architectural views - use case, logical, component and deployment. This 
      case study will map the steps of the process into the views contained in 
      the tool. 
      <H2><A name="Project Summary"></A><B>Project Summary</B></H2>
      <P>This system will have a short inception phase during which prototyping 
      is used to select the database. The use case diagram is started in the 
      inception phase and matured in the elaboration phase. By the end of the 
      elaboration phase, an architectural iteration is complete. The system is 
      evolved in the construction phase in two iterations. The process 
      components of requirements analysis, design, implementation and test are 
      used in all phases of the project lifecycle. 
      <H2><A name="Inception Phase2"></A><B>The Inception Phase</B></H2>
      <H3><A name="Business Goals"></A><B>Business Goals and Needs</B></H3>
      <P>The first question to address is the need for a new registration 
      system. Does the University have the resources needed to design and 
      implement the new system? In addition to the assessment of need for the 
      system, the risks posed by the new system are elaborated. In the case of 
      an on-line registration system, one of the major risks is the ability to 
      store the information in a manner that is easily and quickly accessible by 
      all.</P>
      <P>For the purposes of this case study it was decided that the new system 
      should be built. Prototypes were completed to address the database risks. 
      <H3><A name="Definition Actors"></A><B>Definition of Actors</B></H3>
      <P>The following actors were defined for the problem:</P>
      <UL type=square>
        <LI>Student--someone who is registered to take courses at the 
        University. 
        <LI>Professor--someone who is licensed to teach at the University. 
        <LI>Registrar--someone who is responsible for the maintenance of the 
        Registration System. 
        <LI>Billing System--external system that bills students each semester. 
        </LI></UL>
      <H3><A name="Definition Use Cases"></A><B>Definition of Use Cases</B></H3>
      <P>The following use cases were elaborated for each actor:</P>
      <UL type=square>
        <LI>Student 
        <UL type=square>
          <LI>Register for courses. </LI></UL>
        <LI>Professor 
        <UL type=square>
          <LI>Select courses to teach. 
          <LI>Request course offering roster. </LI></UL>
        <LI>Registrar 
        <UL type=square>
          <LI>Generate course catalogue. 
          <LI>Maintain professor information. 
          <LI>Maintain student information.