{"id":58,"date":"2019-03-28T11:26:05","date_gmt":"2019-03-28T15:26:05","guid":{"rendered":"https:\/\/sites.bu.edu\/braude\/?page_id=58"},"modified":"2019-03-28T11:40:41","modified_gmt":"2019-03-28T15:40:41","slug":"met-cs-770-object-oriented-analysis-design","status":"publish","type":"page","link":"https:\/\/sites.bu.edu\/braude\/courses\/met-cs-770-object-oriented-analysis-design\/","title":{"rendered":"MET CS 770 Object-Oriented Analysis & Design"},"content":{"rendered":"

Last updated: November 13, 2002 Recent updates are often in red.<\/p>\n\n\n\n\n\n\n\n
Contacting Eric Braude changed if this is red<\/td>\nMaterials changed if this is red<\/td>\n<\/tr>\n
Forums changed if this is red<\/td>\nOverview changed if this is red<\/td>\n<\/tr>\n
Grading changed if this is red<\/td>\nProject Organization changed if this is red<\/td>\n<\/tr>\n
Homework and Due Dates changed if this is red \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Phase 3<\/td>\nRequired Background changed if this is red<\/td>\n<\/tr>\n
Learning Objectives changed if this is red<\/td>\nSyllabus and Dates for Classes changed if this is red<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Overview<\/h2>\n

A major engineering problem today is the predictable development of reliable software-intensive systems. The object-oriented paradigm is an important part of such development.<\/p>\n

Object-oriented methods can be divided into languages<\/em>, distribution<\/em>, and analysis and design<\/em>. There change in the language<\/em> category, particularly Java and C#. Distribution<\/em> includes the use of vendor libraries of classes and also distributed objects as specified by the Object Management Group etc.\u00a0 Basic to the entire enterprise, however, are analysis and design<\/em>, which has remained remarkable stable for years. Object-Oriented Analysis and Design <\/em>includes the overall goals of the object paradigm, the selection of classes, the relationships among them, and their utilization to implement systems.<\/p>\n

Required Background<\/h2>\n

A knowledge of C++ or Java (MET CS 565) and software engineering methods (MET CS 673) are required.\u00a0\u00a0 It is preferable to have taken Design Patterns (MET CS 665).<\/p>\n

Materials and references<\/h2>\n

The recommended textbook is “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, and the Unified Process ” by Larman (Prentice Hall) 2nd edition, Published July 2001, 627 pages, ISBN 0130925691.\u00a0 This is the first time that this instructor has used this book, and it is not clear how much the book will be used.<\/p>\n

The instructor will provide notes for all classes.<\/p>\n

Other references:<\/span><\/p>\n

    \n
  • The Unified Modeling Language User Guide<\/em> by Booch et al (Prentice Hall) ISBN0-201-57168-4<\/li>\n
  • The Unified Modeling Language Reference Manual <\/em>James Rumbaugh, Ivar Jacobson, Grady Booch Addison-Wesley Pub Co; ISBN: 020130998X<\/li>\n
  • Design Patterns <\/em>by Gamma et al<\/li>\n
  • Object-Oriented Software Engineering<\/em> by I Jacobson<\/li>\n
  • Object-Oriented Analysis & Design <\/em>by G. Booch<\/li>\n
  • Modeling the world in data<\/em> by S. Schlaer and S. Mellor<\/li>\n
  • Modeling the world in states<\/em> by S. Schlaer and S. Mellor<\/li>\n
  • The Unified Method<\/em> draft www.rational.com<\/li>\n
  • Object-oriented Analysis<\/em> by P. Coad and E. Yourdon<\/li>\n
  • Object-oriented Design<\/em> by P. Coad and E. Yourdon<\/li>\n
  • Object-oriented Programming<\/em> by P. Coad and A Nicola<\/li>\n
  • Software Engineering: An Object-Oriented Perspective <\/em> by Eric Braude<\/li>\n<\/ul>\n

    Learning Objectives<\/h2>\n

    Students will be able to …<\/p>\n

      \n
    • … analyze problems from an object perspective<\/li>\n
    • … create OO designs which are ready for coding<\/li>\n
    • … implement a pilot OO project<\/li>\n<\/ul>\n

      Grading<\/h2>\n

      The course will consist of homework and a project, weighted as follows:<\/p>\n

      1.\u00a0\u00a0\u00a0\u00a0\u00a0 Homework:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 30%<\/p>\n

      2.\u00a0\u00a0\u00a0\u00a0\u00a0 Project:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 70%<\/p>\n

      There are three phases for the project, graded as follows:<\/p>\n

        \n
      • phase 1 (problem statement): \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1\/9<\/li>\n
      • phase 2 (analysis): \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2\/9<\/li>\n
      • phase 3 (design): \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1\/3<\/li>\n
      • phase 4 (implementation and critical review): 1\/3<\/li>\n<\/ul>\n

        Parts are evaluated equally unless otherwise stated.<\/p>\n

        Late homework is not accepted unless there is a reason why it was impossible<\/em> for you. If there is such an impossibility, the work will be graded on a pass\/fail basis.<\/p>\n

        Project Organization<\/h2>\n

        You will be required to submit an analyzed, designed and implemented project according to the deadlines shown in the schedule. Detailed requirements will follow.<\/p>\n

        With the instructor\u2019s permission, it may be possible to substitute all or part of the project with an investigation of tools for OOA&D such as Rational Rose or Together.\u00a0 This will require a detailed evaluation and an investigation of how these tools are being used extensively in a particular company.<\/p>\n

        Teams two are permitted, and will be evaluated at a higher standard. All members must know all parts.<\/p>\n

        You will be required to give a presentation on at least two of the phases in your project.<\/p>\n

        Syllabus:<\/h2>\n

        This syllabus is subject to about 15% modification.<\/p>\n

        The order of topics will be driven by the notes, which the instructor will hand out, not by the textbook. The textbook will serve as background and reference.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        Wk.<\/span><\/td>\nDate<\/span><\/td>\nTopic<\/span><\/td>\nText<\/span><\/p>\n

        chapters<\/span><\/td>\n

        		Project<\/span><\/p>\n

        Times are approximate.\u00a0 See \u201cdate homework due\u201d section for final dates<\/span><\/td>\n<\/tr>\n

        1<\/td>\n9\/3<\/td>\n\n
          \n
        • Review Syllabus<\/li>\n
        • Review Software Development Process<\/li>\n<\/ul>\n<\/td>\n
        		Notes 0-1<\/td>\nPhase 1 assigned<\/td>\n<\/tr>\n
        2<\/td>\n9\/10<\/td>\n\n
          \n
        • Introduction, Overview, and Goals of Design<\/li>\n
        • UML as required<\/li>\n
        • Extreme programming and refactoring<\/li>\n<\/ul>\n<\/td>\n
        		Notes 1-3<\/td>\n<\/td>\n<\/tr>\n
        3<\/td>\n9\/17<\/td>\n\n
          \n
        • Requirements I: Use Cases<\/li>\n<\/ul>\n<\/td>\n
        		Notes 13 part 1<\/td>\nPresentations;<\/p>\n

        Assign phase 2<\/td>\n<\/tr>\n

        4<\/td>\n9\/24<\/td>\n\n
          \n
        • Requirements II: Sequence Diagrams<\/li>\n<\/ul>\n<\/td>\n
        		Notes 13 part 2<\/td>\nPhase 1 due;<\/td>\n<\/tr>\n
        5<\/td>\n10\/1<\/td>\n\n
          \n
        • Requirements III:\u00a0 Completing Domain Classes<\/li>\n
        • Writing Detailed Requirements<\/li>\n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		Notes 13 part 3<\/p>\n

        Larman 10<\/td>\n

        		<\/td>\n<\/tr>\n
        6<\/td>\n10\/8<\/td>\n\n
          \n
        • Software Architectures<\/li>\n<\/ul>\n<\/td>\n
        		Notes 14 part 1<\/td>\nAssign phase 3<\/td>\n<\/tr>\n
        7<\/td>\n10\/22<\/td>\nTo be determined<\/td>\n<\/td>\nPresentations; Phase 2 due;<\/td>\n<\/tr>\n
        8<\/td>\n10\/29<\/td>\n\n
          \n
        • Review Design Patterns as required<\/li>\n
        • Discussion of Tools<\/li>\n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		Notes 4-6<\/td>\n<\/td>\n<\/tr>\n
        9<\/td>\n11\/5<\/td>\n\n
          \n
        • Frameworks<\/li>\n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		<\/td>\nPresentations on architectures<\/td>\n<\/tr>\n
        10<\/td>\n11\/12<\/td>\n\n
          \n
        • Design Topics<\/li>\n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		Notes 14 part 2<\/td>\nAssign phase 4<\/p>\n

        Phase 3 due<\/td>\n<\/tr>\n

        11<\/td>\n11\/19<\/td>\n\n
          \n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		<\/td>\nPresentations on detailed designs<\/td>\n<\/tr>\n
        12<\/td>\n11\/26<\/td>\n\n
          \n
        • Detailed Design<\/li>\n
        • Review Student Designs<\/li>\n<\/ul>\n<\/td>\n
        		<\/td>\nPresentations<\/td>\n<\/tr>\n
        13<\/td>\n12\/3<\/td>\n\n
          \n
        • Implementing OO designs<\/li>\n
        • Shlaer-Mellor<\/li>\n<\/ul>\n<\/td>\n
        		<\/td>\nPresentation of results (1 of 2)<\/td>\n<\/tr>\n
        14<\/td>\n12\/10<\/td>\n\n
          \n
        • Presentations on Finished Applications<\/li>\n<\/ul>\n<\/td>\n
        		<\/td>\nPhase 4 due Presentation of results (2 of 2)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
          \n
        • Notes are from Software Design<\/em> (Braude, to be published by Wiley in March 2002)<\/li>\n
        • ** <\/em>Applying UML and Patterns: \u2026 (Larman)<\/li>\n<\/ul>\n

          Dates Homework is due <\/strong><\/p>\n\n\n\n\n\n\n\n\n\n\n
          Num-ber<\/td>\nName<\/td>\nDue date<\/td>\n<\/tr>\n
          <\/td>\nProject phase 1<\/td>\n9\/24<\/td>\n<\/tr>\n
          1<\/td>\n\u201cDesign Issues\u201d<\/td>\n9\/17<\/td>\n<\/tr>\n
          1<\/td>\n3.4 (Pass Fail)<\/td>\n9\/17<\/td>\n<\/tr>\n
          <\/td>\nProject phase 2<\/span>: (10\/2\/2002<\/p>\n

          )<\/p>\n

          1.Attach first a copy of your phase 1.\u00a0 Respond specifically to whatever comments I may have made on your phase 1.\u00a0\u00a0 You can write these directly on the copy.<\/p>\n

          2.<\/p>\n

          Show the sequence diagrams for at least the two use cases you have introduced.\u00a0 Key them to the use case steps, which you should number.3.List requirements by \u201cdomain class\u201d paragraphs, including<\/p>\n

          — The testable functionality that the application will definitely<\/em> accomplish<\/p>\n

          –What you would like to <\/em>have the application accomplish if time permits<\/p>\n

          Criterion: a. <\/em> Requirements clearly written. (A = very clear description of application\u2019s goals; no detail omitted)<\/em><\/em><\/p>\n

          <\/em> <\/em><\/p>\n

          <\/em> <\/em>4.<\/em>Provide a class diagram for your project consisting of all of the domain classes as well as the domain packages that you will use.<\/em><\/p>\n

          <\/em> <\/em><\/p>\n

          <\/em> <\/em> Criteria: <\/em><\/em><\/p>\n

          <\/em><\/em> b. Clarity and completeness<\/span> Sufficiency of key classes for committed requirements and use cases (A = very clear class meanings; no domain class missing no other domain classes required<\/span>) <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em> g. Economy (A = no redundancy at all in the class model)<\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>Here are some typical improvements.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>M<\/span><\/strong>ost room for improvement<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>1.\u00a0\u00a0\u00a0\u00a0\u00a0 Make your domain names specific<\/span> to your application; e.g., PetStoreTransaction, FootballGame, FootballTeam<\/em> rather than Transaction<\/em> or Game<\/em> or Team<\/em>. <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>2.\u00a0\u00a0\u00a0\u00a0\u00a0 Use the \u201centities\u201d section<\/span> correctly.\u00a0 This applies when there are specific entities that the application is required to have. It does not include entities that will be created at runtime that you can\u2019t specify entirely at requirements time.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>3.\u00a0\u00a0\u00a0\u00a0\u00a0 Many internal classes have corresponding GUI classes<\/span>.\u00a0 For example, PetStoreAccount<\/em> entities may get their data from a PetStoreAccountGUI<\/em> entity.\u00a0 Specify the latter in its own category rather than under PetStoreAccount<\/em>.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>4.\u00a0\u00a0\u00a0\u00a0\u00a0 In your requirements, distinguish between <\/span>the initiator and <\/span>the substance<\/span> of functionality. <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>For example, under \u201cCourses\u201d a functionality might be \u201c12.1.5 The application shall be able to display the catalog description of each course in the following format \u2026\u201d\u00a0 (Corresponds to class Course<\/em>).\u00a0 Under the \u201cCourse GUI\u201d paragraph an event might be \u201cWhen the display course<\/em> button is pressed, the functionality described in section 12.1.5 is initated.\u201d\u00a0 Under the \u201cStudent GUI\u201d paragraph an event might be \u201cWhen the show course<\/em> button is pressed, the functionality described in section 12.1.5 is initated.\u201d Etc.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>Do not<\/em> say \u201c12.1.5 When the display course<\/em> button is pressed on the Course GUI, the application can display the catalog description of each course in the following format \u2026\u201d\u00a0 Otherwise you will have a maintenance nightmare and a poor mapping to the design and implementation.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>5. <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>R<\/span><\/strong>oom for improvement<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>1. <\/strong>Most <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>2. <\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>3. <\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>4. <\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>5. <\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>6.<\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>7.<\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>objects are not sensitive to events<\/span> unless they are GUI objects.\u00a0 Buttons are examples.\u00a0 Many objects have functionality that may be invoked as a result<\/em> of an event on an <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>other object.\u00a0 For example, a customer\u2019s information may be displayed when the button is clicked.\u00a0 But \u201cdisplay\u201d is a function of Customer<\/em>: Any one of clients can invoke it, some event-sensitive and others not.\u00a0 The object with (direct) event reaction is the button, not the customer. <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>2. <\/em><\/em><\/em><\/em>In your requirements document, don\u2019t say \u201cThe customer shall include a name \u2026\u201d (which is strange English).\u00a0 Instead: \u201cThe application shall maintain the name of customers \u2026.\u201d<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>3. <\/em><\/em><\/em><\/em>Distinguish between objects and object aggregates<\/span>.\u00a0 For example, you could have a \u201cCustomers\u201d requirements paragraph with functionality such as \u201cApp shall be able to send a customer profile to the central database.\u201d\u00a0 This will correspond to a class Customer<\/em>.\u00a0 You could also have a \u201cCustomer List\u201d\u00a0 paragraph with functionality such as \u201cIt shall be possible to add new customers \u2026\u201d\u00a0 This will correspond to a class such as CustomerList<\/em>.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>4. <\/em><\/em><\/em><\/em>Don\u2019t waste words<\/span>. In particular, give a sentence or two under each paragraph that adds value.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>NOT: <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>1.4 Customers<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>This section describes the requirements for customers.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>BUT<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>1.4 Customers<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>The application shall track the customers of the video store as follows. \u2026<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em>1.<\/strong> <\/strong><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em> <\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/td>\n

          		10\/22<\/td>\n<\/tr>\n
          3<\/td>\nClown problem 10\/9\/02<\/p>\n

          Draw a class model for an application for drawing human figures.\u00a0 The picture shown is a typical product of the application.\u00a0 The figures are always<\/em> neck-upward; mouths are always<\/em> lines, necks always<\/em> rectangles, etc. \u2013 the shapes that appear in the figure.\u00a0 Assume that the business will never change — but we want to be able to easily upgrade the shop\u2019s capability within these constraints (e.g., draw necks with various colors, new kinds of border lines).\u00a0 The class model should make figure drawing convenient (e.g., allowing the retrieval of previously constructed figure parts). Show attributes or operations whenever they clarify your solution.\u00a0 Include useful abstractions (but to extend the current business).<\/p>\n

          There is no requirement to take into account the GUI for the application (icons, menu\u2019s etc.)<\/p>\n

          Here is a scenario: <\/strong><\/strong><\/p>\n

          <\/strong> The user … pulls onto the monitor \u201cabeLincolnFace14\u201d (which excludes the ears and neck) <\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/span><\/strong><\/strong> … adds \u201cear123\u201d on the left by dragging to its vicinity and releasing <\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/strong><\/span><\/strong><\/strong> The application places ear123 in a correct position<\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/span><\/strong><\/strong><\/span><\/strong><\/strong> The user invokes the \u201ccomplete with suitable parts\u201d command.<\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> The application <\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> \u2026 completes the figure with a neck and hat that it considers most suitable. <\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> … creates an ear on the right, complete with matching position, interior texture and color, and styles of border lines <\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> Criteria: <\/em><\/strong>a<\/em><\/strong>. completeness relative to requirements (A = sufficient classes for requirements, including appropriate generalizations) <\/em><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> b. economy of classes (A = no more than necessary for requirements)<\/em><\/strong><\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong> <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/p>\n

          <\/em><\/strong><\/em><\/strong><\/strong><\/strong><\/span><\/strong><\/span><\/strong><\/span><\/strong><\/strong><\/span><\/strong><\/strong><\/td>\n

          		10\/29<\/td>\n<\/tr>\n
          4<\/td>\n14.1 \u2013 14.6<\/td>\n11\/5<\/td>\n<\/tr>\n
          <\/td>\nsee more below<\/td>\nsee below<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Project Phase 3<\/span>:<\/span> Due 11\/12<\/p>\n

          1.\u00a0 Attach a copy of your phase 2 as graded by me, with specific responses to whatever comments I may have made on your phase 2.<\/p>\n

          2. Provide a class diagram for your project, showing inheritance and aggregation.\u00a0 Show key methods, key dependencies, and inheritance and aggregation.\u00a0\u00a0 Use your packages and Facades to avoid a single overwhelming figure.<\/p>\n

          3. Show at least one additional model that completes your design.<\/p>\n

          Criteria: <\/em><\/p>\n

          a. Clarity<\/span> of the model (A = very clear class meanings; very clear organization; no unnecessary details)<\/em><\/em><\/em><\/p>\n

          b. Adequacy of class model<\/span> for effecting the requirements.\u00a0 (A= detailed enough to clearly allow an implementation that satisfies the requirements.) <\/em><\/em><\/em><\/em><\/p>\n

          g. Completeness<\/span> **** of models to specify the entire design. (A=right models selected; clearly no gaps in description)<\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          M<\/span><\/strong>ost room for improvement<\/em><\/em><\/em><\/em><\/p>\n

          1. If you use a data flow diagram, indicate the data types that flow.<\/em><\/em><\/em><\/em><\/p>\n

          2. If you use a data flow diagram, indicate the functionality at each processing node.<\/em><\/em><\/em><\/em><\/p>\n

          3. In the interest of clarity, show the relationships among the packages.\u00a0 You can employ <<uses>> relationships.\u00a0 Omit the classes from such a figure.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          R<\/span><\/strong>oom for improvement<\/em><\/em><\/em><\/em><\/p>\n

          1. In this course we did not give meaning to solid lines with arrows.\u00a0 Explain what you mean by them, or don\u2019t use them.<\/em><\/em><\/em><\/em><\/p>\n

          2. Be specific about associations: Do you mean two-way aggregations?<\/em><\/em><\/em><\/em><\/p>\n

          3. You have introduced a class whose name does not indicate a clear purpose and which is not a domain class.\u00a0 Explain it\u2019s purpose.<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          A L<\/span><\/strong>ittle room for improvement<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          1. \u2026..<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          <\/span><\/em><\/em><\/em><\/em><\/p>\n

          <\/span><\/em><\/em><\/em><\/em><\/p>\n

          Project Phase 4<\/span>: \u00a0\u00a0\u00a0 Due 12\/10<\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          Section 1<\/span> Attach Phases 2 and 3. Response to my comments on phase 3. ( not graded, but required)<\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/p>\n

          Section 2<\/span> Show representative input and output. <\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/em><\/p>\n

          Section 3<\/span> <\/em>Explain the application of all of the steps covered in the notes — explain if they did not apply. <\/em><\/em><\/em><\/em><\/p>\n

          (criterion: a<\/em>. Clarity and completeness — A = all relevant steps thoroughly implemented where applicable and explained where not)<\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Section 4 Provide a complete class diagram and other appropriate model(s), building on the models you submitted for phase 3. <\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          (criterion: b<\/em>. clarity and completeness — A = very clearly chosen and arranged models)<\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Section 5 <\/span>Account of the degree to which you accomplished your requirements as given in phase 2.\u00a0 Please refer to them by number (e.g., 11.3.5).<\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          (criterion: <\/em>g. degree of accomplishment.\u00a0 A = excellent functional capabilities for a graduate course) <\/em> <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Section 6<\/span>. Source code. <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          (<\/em>d. criterion: clarity — A = extremely clear layout & code; each part easily traceable to the corresponding design element)<\/em> <\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Please … <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          note that your class diagrams and code must be consistent; <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          indicate all differences with prior design decisions; <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          indicate all sections using numbered tabs (e.g., Post-it notes) <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          <\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Forums — past and present<\/strong><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Fall 2001<\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n

          Fall 2002 email to the group is: 770F02@yahoogroups.com<\/strong><\/em><\/span><\/em><\/em><\/em><\/em><\/em><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

          Last updated: November 13, 2002 Recent updates are often in red. Contacting Eric Braude changed if this is red Materials changed if this is red Forums changed if this is red Overview changed if this is red Grading changed if this is red Project Organization changed if this is red Homework and Due Dates changed […]<\/p>\n","protected":false},"author":2828,"featured_media":0,"parent":22,"menu_order":7,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/pages\/58"}],"collection":[{"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/users\/2828"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/comments?post=58"}],"version-history":[{"count":2,"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/pages\/58\/revisions"}],"predecessor-version":[{"id":60,"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/pages\/58\/revisions\/60"}],"up":[{"embeddable":true,"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/pages\/22"}],"wp:attachment":[{"href":"https:\/\/sites.bu.edu\/braude\/wp-json\/wp\/v2\/media?parent=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}