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><A name=Construction_Activities></A><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> 
          <LI><A name=Building_Iteration></A><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> 
          <LI><A name=Transition_Phase></A><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></LI></UL></LI></UL></FONT><BR>
      <P><FONT size=-1>
      <P>
      <H2 align=center><A name=chap1>Chapter 1</A></H2>
      <H2 align=center>Introduction<BR></H2>
      <P><A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Why Process"><B>Why 
      Process Is Needed</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 Notation"><B>The 
      Role of Notation</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#History UML"><B>The 
      History of the Unified Modeling Language</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#Iterative Development"><B>Iterative 
      and Incremental Development</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#Rational Process"><B>The 
      Rational Process</B></A></P>
      <H2><BR><A name="Why Process"></A><B>Why Process Is Needed</B></H2>
      <P>A successful development project satisfies or exceeds the customer's 
      expectations, is developed in a timely and economical fashion, and is 
      resilient to change and adaptation. The development lifecycle must promote 
      creativity and innovation. At the same time, the development process must 
      be controlled and measured to ensure that the project is indeed completed. 
      "Creativity is essential to the crafting of all well-structured 
      object-oriented architectures, but developers allowed completely 
      unrestrained creativity tend to never reach closure. Similarly, discipline 
      is required when organizing the efforts of a team of developers, but too 
      much discipline gives birth to an ugly bureaucracy that kills all attempts 
      at innovation." <A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#1Booch"><SUP>1</SUP></A> 
      A well-managed iterative and incremental lifecycle provides the necessary 
      control without affecting creativity. 
      <H2><A name="Role Notation"></A><B>The Role of Notation</B></H2>
      <P>Notation plays an important part in any methodology - it is the glue 
      that holds the process together. <A 
      href="http://www.augustana.ca/uml/">The Unified Modeling Language 
      (UML)</A> provides a very robust notation, which grows from analysis into 
      design. Certain elements of the notation (for example, classes, 
      associations, aggregations, inheritance) are introduced during analysis. 
      Other elements of the notation (for example, containment indicators and 
      properties) are introduced during design. "Notation has three roles:</P>
      <UL type=square>
        <LI>It serves as the language for communicating decisions that are not 
        obvious or cannot be inferred from the code itself. 
        <LI>It provides semantics that are rich enough to capture all important 
        strategic and tactical decisions. 
        <LI>It offers a form concrete enough for humans to reason and for tools 
        to manipulate." <A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#2Ibid"><SUP>2</SUP></A> 
        </LI></UL>
      <H2><A name="History UML"></A><B>The History of the Unified Modeling 
      Language</B></H2>
      <P>"UML is a language used to specify, visualize, and document the 
      artifacts of an object-oriented system under development. It represents 
      the unification of the Booch, OMT, and Objectory notations, as well as the 
      best ideas from a number of other methodologists as shown in Figure 1. By 
      unifying the notations used by these object-oriented methods, the Unified 
      Modeling Language provides the basis for a <I>defacto</I> standard in the 
      domain of object-oriented analysis and design founded on a wide base of 
      user experience."<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#3Unified"><SUP>3</SUP></A></P>
      <P>The <A href="http://www.augustana.ca/uml/">UML</A> is an attempt to 
      standardize the artifacts of analysis and design: semantic models, 
      syntactic notation, and diagrams. The first public draft (version 0.8) was 
      introduced in October, 1995. Feedback from the public and Ivar Jacobson's 
      input were included in the next two versions (.9 in July, 1996 and .91 in 
      October, 1996). Version 1.0 will be presented to the Object Management 
      Group (OMG) for standardization in January, 1997.</P>
      <P align=center><IMG height=288 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig1.gif" 
      width=432 align=bottom border=0><BR><BR><B><I>Figure 1 The Unified 
      Modeling Language</I></B> 
      <H2><A name="Iterative Development"></A><B>Iterative and Incremental 
      Development</B></H2>
      <P>In an iterative and incremental lifecycle (Figure 2), development 
      proceeds as a series of iterations that evolve into the final system. Each 
      iteration consists of the following process components: requirements 
      analysis, analysis, design, implementation, and test. The developers do 
      not assume that all requirements are known at the beginning of the 
      lifecycle; indeed change is anticipated throughout all phases.</P>
      <P>This type of lifecycle is a risk mitigation driven process. Technical 
      risks are assessed and prioritized early in the lifecycle and are revised 
      during the development of each iteration. Risks are attached to each 
      iteration so that successful completion of the iteration mitigates the 
      risks attached to it. The releases are scheduled to ensure that the 
      highest risks are tackled first.</P>
      <P>Building the system in this fashion exposes and mitigates the risks of 
      the system early in the lifecycle. The result of this type of lifecycle is 
      less risk coupled with minimal investment.<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#4Iterative"><SUP>4</SUP></A></P>
      <P align=center><IMG height=191 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig2.gif" 
      width=432 align=bottom border=0></P>
      <P align=center><A name=Figure2></A><B><I>Figure 2 Iterative and 
      Incremental Development</I></B></P>
      <P>
      <H2><A name="Rational Process"></A><B>The Rational Process</B></H2>
      <P>Control for an iterative and incremental lifecycle is provided in the 
      Rational Objectory Process--an extensive set of guidelines that address 
      the technical and organizational aspects of software development focusing 
      on requirements analysis and design.<A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#5Objectory"><SUP>5</SUP></A> 
      The process used in this book is a simplified version of the Rational 
      Unified Process.</P>
      <P>The Rational process is structured along two dimensions:</P>
      <UL type=square>
        <LI>Time--division of the lifecycle into phases and iterations. 
        <LI>Process components--production of a specific set of artifacts with 
        well-defined activities. </LI></UL>
      <P>Both dimensions must be taken into account for a project to 
succeed.</P>
      <P>Structuring a project along the time dimension involves the adoption of 
      the following time based phases:</P>
      <UL type=square>
        <LI>Inception--the specification of the project vision. 
        <LI>Elaboration--planning the necessary activities and required 
        resources; specifying the features and designing the architecture. 
        <LI>Construction--building the product as a series of incremental 
        iterations. 
        <LI>Transition--supplying the product to the user community 
        (manufacturing, delivering, and training). </LI></UL>
      <P>Structuring the project along the process component dimension includes 
      the following activities:</P>
      <UL type=square>
        <LI>Requirements analysis--description of what the system should do. 
        <LI>Design--how the system will be realized in the implementation phase. 

        <LI>Implementation--the production of the code that will result in an 
        executable system. 
        <LI>Test--the verification of the entire system. </LI></UL>
      <P>Each activity of the process component dimension is applied to the each 
      phase of the time based dimension. Figure 3 shows how the process 
      components are applied to each time based phase.</P>
      <P align=center><A 
      href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/ratapr_fig3.gif"><IMG 
      height=215 alt="" 
      src="Whitepapers - A Rational Approach to Software Development Using Rational Rose 4_0_files/ratapr_fig3s.gif" 
      width=432 align=bottom border=2></A></P>
      <P align=center><B><I>Figure 3 The Development Process</I></B></P>
      <P><A name=1Booch></A><SUP>1</SUP> Booch, Grady. <I>Object Solutions. 
      </I>Redwood City, Calif.: Addison-Wesley, 1995.<BR><A 
      name=2Ibid></A><SUP>2</SUP> Ibid.<BR><A 
      name=3Unified></A><SUP>3</SUP><I>The Unified Method,</I> Draft Edition 
      (0.8), Rational Software Corporation, October 1995.<BR><A 
      name=4Iterative></A><SUP>4</SUP> More information on the application of an 
      iterative and incremental approach to software development may be found in 
      the article "A Rational Development Process" by Philippe Kruchten, 
      CrossTalk, 9(7), July 1996, pp. 11-16. <BR><A 
      name=5Objectory></A><SUP>5</SUP> Rational Software Corporation. <I>The 
      Objectory Process--Introduction</I>, 1996. This introduction may be found 
      on the Rational Rose CD-ROM.</P></FONT><BR>
      <P><FONT size=-1>
      <P>
      <H2 align=center><A name=chap2>Chapter 2</A></H2>
      <H2 align=center>Software Lifeycle Phases<BR></H2>
      <BLOCKQUOTE>
        <P><A 
        href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Inception"><B>Inception</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#Inception Phase">The 
          Inception Phase Activities</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Defining Problem">Defining 
          the Problem</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Identifying Actors">Identifying 
          Actors</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Identifying Use Cases">Identifying 
          Use Cases</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"><B>Elaboration</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#Elaboration Phase">The 
          Elaboration Phase Activities</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Analyzing Problem">Analyzing 
          the Problem Domain</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Architectural Foundation">Establishing 
          the Architectural Foundation</A><BR><A 
          href="http://www.augustana.ca/~mohrj/courses/2003.fall/csc220/papers/rational_approach_to_software_development/rational_approach.html#Developing Project">Developing 
          the Project Plan</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"><B>Construction</B></A></P>