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

        <BLOCKQUOTE>
          <P><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Construction Phase">The 
          Construction Phase Activities</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Building Iteration">Building 
          an Iteration</A></P></BLOCKQUOTE>
        <P><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Transition"><B>Transition</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#Transition Phase">The 
          Transition Phase Activities</A> </P></BLOCKQUOTE></BLOCKQUOTE>
      <H2><BR><A name=Inception></A><B>Inception</B></H2>
      <H3><A name="Inception Phase"></A><B>The Inception Phase 
      Activities</B></H3>
      <P>The purposes of the Inception Phase are to establish the business case 
      for the system and to specify the project scope. In order to accomplish 
      this, all external entities with which the system will interact (actors) 
      are identified and the nature of this interaction is defined at a high 
      level (use cases). The business case includes success criteria, risk 
      assessment, an estimate of the resources required and a phase plan. Some 
      projects will also develop a prototype during this phase.<BR><BR>At the 
      end of the inception phase, the lifecycle objectives of the project are 
      examined and a decision as to whether or not to proceed with the project 
      is made. 
      <H3><A name="Defining Problem"></A><B>Defining the Problem</B></H3>
      <P>"The most important question to ask when developing a system is neither 
      a methodological nor a technical question. It is a most simple question: 
      "Is this the right system to make?" Unfortunately, this question is often 
      neither asked nor answered."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#1Booch_OMT"><SUP>1</SUP></A></P>
      <P>During the inception phase of the development process, the appropriate 
      questions are asked and research is performed to answer the questions. 
      Often, a "proof of concept" prototype is created to help answer the tough 
      development questions. The end result of this phase is a set of system 
      requirements for the system to be developed. 
      <H3><A name="Identifying Actors"></A><B>Identifying Actors</B></H3>
      <P>"To fully understand the purpose of a system we have to know who the 
      system is for, that is, who will use it."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#2Objectory"><SUP>2</SUP></A> 
      An actor is a role played by a physical person or system when interacting 
      with the system. Actors are discovered by examining:</P>
      <UL type=square>
        <LI>Who directly uses the system. 
        <LI>Who is responsible for maintaining the system. 
        <LI>External hardware used by the system. 
        <LI>Other systems interacting with the system. </LI></UL>
      <H3><A name="Identifying Use Cases"></A><B>Identifying Use Cases</B></H3>
      <P>A use case is a specific way of using a system--some functionality is 
      performed by the system in response to a stimulus from an actor. Use cases 
      model a dialogue between an actor and the system. Use cases provide a 
      vehicle to:</P>
      <UL type=square>
        <LI>Capture the requirements about the system. 
        <LI>Communicate with the end users and domain experts. 
        <LI>Test the system. </LI></UL>
      <P>"The description of a use case defines what happens in the system when 
      the use case is performed; it corresponds to a sequence of transactions 
      performed by the system, which yields a measurable result of value to a 
      particular actor."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#3OOSoftware"><SUP>3</SUP></A> 

      <H2><A name=Elaboration></A><B>Elaboration</B></H2>
      <H3><A name="Elaboration Phase"></A><B>The Elaboration Phase 
      Activities</B></H3>
      <P>The purposes of the elaboration phase are to analyze the problem 
      domain, establish an architectural foundation, develop the project plan, 
      and to eliminate the highest risk elements of the project. 
      <H3><A name="Analyzing Problem"></A><B>Analyzing the Problem 
      Domain</B></H3>
      <P>During this phase of development scenario and class diagrams are 
      created and matured. The diagrams initially contain "real world" or 
      "business" classes--classes that represent the "what" not the "how".</P>
      <P>Objects and classes are discovered by examining the use cases developed 
      during the inception phase. Scenarios (instances of a use case) are 
      developed and graphically depicted in Sequence Diagrams. Objects in the 
      scenarios are identified and grouped into classes. Classes are then 
      grouped into packages.</P>
      <P>Relationships between classes are established to allow communication 
      between the objects in the scenarios. The relationships are either 
      associations or aggregations.</P>
      <P>An association is a bi-directional relationship between classes which 
      defines a static or dynamic relationship between objects in the associated 
      classes. A static relationship between objects shows the structure of the 
      model in terms of which objects are aware of others. A dynamic 
      relationship between objects shows how objects interact.</P>
      <P>An aggregation is a stronger form of association--it is a relationship 
      between a whole and its parts.</P>
      <P>Attributes (structure) and operations (behavior) are added to the 
      classes to allow the functionality of the scenarios to be accomplished. 
      Superclasses are created to hold common structure, behavior and/or 
      relationships. 
      <H3><A name="Architectural Foundation"></A><B>Establishing the 
      Architectural Foundation</B></H3>
      <P>"Establishing a sound architectural foundation is absolutely essential 
      to the success of an object-oriented project. Some teams try to ignore 
      this phase, either because they are in such a rush to get a product out 
      quickly they feel they don't have time to architect, or because they don't 
      believe that architecting provides them any real value. Either way, the 
      resulting head-long rush to code is always disastrous: fail to carry out 
      this step properly, and your project will likely experience software 
      meltdown." <A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#4ObjectSolutions"><SUP>4</SUP></A></P>
      <P>The architecture of an object-oriented system is organized in terms of 
      distinct layers. Each layer represents a coherent abstraction and contains 
      a well-defined and controlled interface. Additionally, each layer of the 
      system is built upon well-defined and controlled facilities at lower 
      levels of abstraction.</P>
      <P>The architecture establishes the basic structure of the system. 
      Executable prototypes of the architecture are built to verify that the 
      design decisions are correct. "Building something executable is absolutely 
      essential, because it forces the development team to validate their design 
      assumptions in the harsh light of reality."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#5Ibid"><SUP>5</SUP></A></P>
      <P>Software architecture is not a one-dimensional thing - it is made up of 
      concurrent multiple views. Figure 4 shows the "4+1" views of 
      architecture.<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#6SoftwareArchitecture"><SUP>6</SUP></A></P>
      <P>The <I>use case view</I> describes the system as sets of transactions 
      from the point of view of external actors. This view is initially created 
      in the inception phase of the lifecycle and drives the rest of the 
      process.</P>
      <P>The <I>logical view</I> contains the collection of packages, classes, 
      and relationships. This view is initially created in the elaboration phase 
      and matured in the construction phase.</P>
      <P>The <I>process view</I> contains processes, threads, inter-process 
      communication and synchronization mechanisms. This view is initially 
      created in the elaboration phase and matured in the construction 
phase.</P>
      <P>The <I>implementation view</I> contains modules and subsystems. This 
      view is initially created in the elaboration phase and matured in the 
      construction phase.</P>
      <P>The <I>deployment view</I> contains the physical nodes in the system 
      and the connections between the nodes. This view is created in the 
      elaboration phase of the process.</P>
      <P align=center><IMG height=204 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig4.gif" 
      width=357 align=bottom border=0></P>
      <P align=center><B><I>Figure 4 The "4+1" View of Architecture</I></B></P>
      <P>
      <H3><A name="Developing Project"></A><B>Developing the Project 
      Plan</B></H3>
      <P>The project plan prescribes schedules for the iterations developed 
      during the construction phase of development. "Such a plan must identify a 
      controlled series of architectural releases, each growing in its 
      functionality and ultimately encompassing the requirements of the complete 
      production system."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#7ObjectSolutions"><SUP>7</SUP></A> 
      Use cases and scenarios developed in earlier phases are the main input to 
      this phase of design. "Scenarios should be grouped so that for each 
      release, they collectively provide a meaningful chunk of the system's 
      behavior and additionally require the development team to attack the 
      project's next highest risks."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#8Ibid"><SUP>8</SUP></A></P>
      <P>The project plan is developed by following the steps outlined 
below:</P>
      <OL>
        <LI>Identify and prioritize the major risks for the project. 
        <LI>Select a small number of scenarios that address the highest priority 
        risks. "Scenarios are examined and prioritized according to risk, 
        importance to the customer, and the need to develop certain basic 
        scenarios early."<A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#9Succeeding"><SUP>9</SUP></A> 

        <LI>Select the classes and relationships to be implemented by analyzing 
        the scenarios. 
        <LI>Implement the selected classes and relationships. 
        <LI>Develop test cases. 
        <LI>Test the classes and relationships to verify that the functionality 
        of the scenario is carried out. 
        <LI>Integrate and test with previous iterations. 
        <LI>Evaluate the iteration and assign any needed re-work to a future 
        iteration. 
        <LI>Remember, the main reason for using an iterative approach: not all 
        requirements are known in the beginning. It is not unusual for some 
        risks to not be eliminated as planned, for new risks to be discovered, 
        and for some code to be discarded due to the evaluation of an iteration. 
        </LI></OL>
      <H2><A name=Construction></A><B>Construction</B></H2>
      <H3><A name="Construction Phase"></A><B>The Construction Phase 
      Activities</B></H3>
      <P>The purpose of the Construction Phase is to develop a software product 
      which is ready to be introduced into the user community. The product is 
      evolved as a series of iterations. 
      <H3><A name="Building Iteration"></A><B>Building an Iteration</B></H3>
      <P>Each iteration addresses a set of risks identified in the elaboration 
      phase. An iteration is typically the implementation of one or more use 
      cases. The process of building an iteration involves:</P>
      <BLOCKQUOTE>