Object-Oriented Analysis & Design

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 if this is red        Phase 3

Required Background                changed if this is red

Learning Objectives             changed if this is red

Syllabus and Dates for Classes  changed if this is red

Overview 

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.

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

Required Background

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

Materials and references

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.  This is the first time that this instructor has used this book, and it is not clear how much the book will be used.

The instructor will provide notes for all classes.

Other references:

·        The Unified Modeling Language User Guide by Booch et al (Prentice Hall) ISBN0-201-57168-4

·        The Unified Modeling Language Reference Manual James Rumbaugh, Ivar Jacobson, Grady Booch Addison-Wesley Pub Co; ISBN: 020130998X

·        Design Patterns by Gamma et al

·        Object-Oriented Software Engineering by I Jacobson

·        Object-Oriented Analysis & Design by G. Booch

·        Modeling the world in data by S. Schlaer and S. Mellor

·        Modeling the world in states by S. Schlaer and S. Mellor

·        The Unified Method draft www.rational.com

·        Object-oriented Analysis by P. Coad and E. Yourdon

·        Object-oriented Design by P. Coad and E. Yourdon

·        Object-oriented Programming by P. Coad and A Nicola

·        Software Engineering: An Object-Oriented Perspective  by Eric Braude

 

Learning Objectives

 Students will be able to ...

·        ... analyze problems from an object perspective

·        ... create OO designs which are ready for coding

·        ... implement a pilot OO project

 

Grading

The course will consist of homework and a project, weighted as follows:

1.      Homework:                  30%

2.      Project:                        70%

There are three phases for the project, graded as follows:

·        phase 1 (problem statement):                            1/9

·        phase 2 (analysis):                                             2/9

·        phase 3 (design):                                               1/3

·        phase 4 (implementation and critical review): 1/3

Parts are evaluated equally unless otherwise stated.

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

Please see http://metcs.bu.edu/~ebraude/GradePolicy.htm for more details on grading computations.

 

Project Organization

You will be required to submit an analyzed, designed and implemented project according to the deadlines shown in the schedule. Detailed requirements will follow.

With the instructor’s 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.  This will require a detailed evaluation and an investigation of how these tools are being used extensively in a particular company.

Teams two are permitted, and will be evaluated at a higher standard. All members must know all parts.

You will be required to give a presentation on at least two of the phases in your project.

 

To contact Dr. Braude

see: http://metcs.bu.edu/~ebraude/avail.htm

 

Syllabus:

This syllabus is subject to about 15% modification.

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.

Wk.

Date

Topic

Text

chapters

Project

Times are approximate.  See “date homework due” section for final dates

1

9/3

·        Review Syllabus

·        Review Software Development Process

Notes 0-1

Phase 1 assigned

2

9/10

·        Introduction, Overview, and Goals of Design

·        UML as required

·        Extreme programming and refactoring

Notes 1-3

 

3

9/17

·        Requirements I: Use Cases

Notes 13 part 1

Presentations;

Assign phase 2

4

9/24

·        Requirements II: Sequence Diagrams

Notes 13 part 2

Phase 1 due;

5

10/1

·          Requirements III:  Completing Domain Classes

·          Writing Detailed Requirements

·        Review Student Designs

Notes 13 part 3

Larman 10

 

6

10/8

·        Software Architectures

Notes 14 part 1

Assign phase 3

7

10/22

To be determined

 

Presentations; Phase 2 due;

8

10/29

·        Review Design Patterns as required

·        Discussion of Tools

·        Review Student Designs

Notes 4-6

 

9

11/5

·        Frameworks

·        Review Student Designs

 

 

Presentations on architectures

10

11/12

·        Design Topics

·        Review Student Designs

Notes 14 part 2

Assign phase 4

Phase 3 due

11

11/19

·        Review Student Designs

 

Presentations on detailed designs

12

11/26

·        Detailed Design

·        Review Student Designs

 

Presentations

13

12/3

·        Implementing OO designs

·        Shlaer-Mellor

 

Presentation of results (1 of 2)

14

12/10

·        Presentations on Finished Applications

 

Phase 4 due Presentation of results (2 of 2)

·        Notes are from Software Design (Braude, to be published by Wiley in March 2002) 

·        ** Applying UML and Patterns: … (Larman)

Dates Homework is due 

Num-ber

Name

Due date

 

Project phase 1

9/24

1

“Design Issues”

9/17

1

3.4 (Pass Fail)

9/17

 

Project phase 2: (10/2/2002

)

1.Attach first a copy of your phase 1.  Respond specifically to whatever comments I may have made on your phase 1.   You can write these directly on the copy.

2.Show the sequence diagrams for at least the two use cases you have introduced.  Key them to the use case steps, which you should number.

3.List requirements by “domain class” paragraphs, including

 -- The testable functionality that the application will definitely accomplish 

 --What you would like to have the application accomplish if time permits 

Criterion: a.  Requirements clearly written. (A = very clear description of application’s goals; no detail omitted)

 

4.Provide a class diagram for your project consisting of all of the domain classes as well as the domain packages that you will use.

 

Criteria:

b.  Clarity and completeness Sufficiency of key classes for committed requirements and use cases (A = very clear class meanings; no domain class missing no other domain classes required)                                                                               

g. Economy (A = no redundancy at all in the class model)

 

Here are some typical improvements.

Most room for improvement

1.      Make your domain names specific to your application; e.g., PetStoreTransaction, FootballGame, FootballTeam rather than Transaction or Game or Team. 

2.      Use the “entities” section correctly.  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’t specify entirely at requirements time.

3.      Many internal classes have corresponding GUI classes.  For example, PetStoreAccount entities may get their data from a PetStoreAccountGUI entity.  Specify the latter in its own category rather than under PetStoreAccount.

4.      In your requirements, distinguish between the initiator and the substance of functionality. 

For example, under “Courses” a functionality might be “12.1.5 The application shall be able to display the catalog description of each course in the following format …”  (Corresponds to class Course).  Under the “Course GUI” paragraph an event might be “When the display course button is pressed, the functionality described in section 12.1.5 is initated.”  Under the “Student GUI” paragraph an event might be “When the show course button is pressed, the functionality described in section 12.1.5 is initated.” Etc.

Do not say “12.1.5 When the display course button is pressed on the Course GUI, the application can display the catalog description of each course in the following format …”  Otherwise you will have a maintenance nightmare and a poor mapping to the design and implementation.

5.       

Room for improvement

1.      Most

2.       

3.       

4.       

5.        

6. 

7. 

objects are not sensitive to events unless they are GUI objects.  Buttons are examples.  Many objects have functionality that may be invoked as a result of an event on an

other object.  For example, a customer’s information may be displayed when the button is clicked.  But “display” is a function of Customer: Any one of clients can invoke it, some event-sensitive and others not.  The object with (direct) event reaction is the button, not the customer.

 

2.      In your requirements document, don’t say “The customer shall include a name …” (which is strange English).  Instead: “The application shall maintain the name of customers ….”

3.      Distinguish between objects and object aggregates.  For example, you could have a “Customers” requirements paragraph with functionality such as “App shall be able to send a customer profile to the central database.”  This will correspond to a class Customer.  You could also have a “Customer List”  paragraph with functionality such as “It shall be possible to add new customers …”  This will correspond to a class such as CustomerList.

4.      Don’t waste words. In particular, give a sentence or two under each paragraph that adds value.

NOT:

1.4 Customers

This section describes the requirements for customers.

BUT

1.4 Customers

The application shall track the customers of the video store as follows. …

 

1. 

 

 

10/22

3

Clown problem 10/9/02

Draw a class model for an application for drawing human figures.  The picture shown is a typical product of the application.  The figures are always neck-upward; mouths are always lines, necks always rectangles, etc. – the shapes that appear in the figure.  Assume that the business will never change -- but we want to be able to easily upgrade the shop’s capability within these constraints (e.g., draw necks with various colors, new kinds of border lines).  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.  Include useful abstractions (but to extend the current business). 

There is no requirement to take into account the GUI for the application (icons, menu’s etc.)

 

Here is a scenario:

The user ... pulls onto the monitor “abeLincolnFace14” (which excludes the ears and neck)

... adds “ear123” on the left by dragging to its vicinity and releasing

The application places ear123 in a correct position

The user invokes the “complete with suitable parts” command.

The application

… completes the figure with a neck and hat that it considers most suitable.

... creates an ear on the right, complete with matching position, interior texture and color, and styles of border lines

Criteria:  a. completeness relative to requirements (A = sufficient classes for requirements, including appropriate generalizations)         

b. economy of classes (A = no more than necessary for requirements)

 

 

 

 

10/29

4

14.1 – 14.6

11/5

 

see more below

 

 

see below

 

Project Phase 3:      Due 11/12

1.  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. 

2. Provide a class diagram for your project, showing inheritance and aggregation.  Show key methods, key dependencies, and inheritance and aggregation.   Use your packages and Facades to avoid a single overwhelming figure.

3. Show at least one additional model that completes your design.

Criteria:

a. Clarity of the model (A = very clear class meanings; very clear organization; no unnecessary details)

b. Adequacy of class model for effecting the requirements.  (A= detailed enough to clearly allow an implementation that satisfies the requirements.)

g. Completeness **** of models to specify the entire design. (A=right models selected; clearly no gaps in description)

 

Most room for improvement

1. If you use a data flow diagram, indicate the data types that flow.

2. If you use a data flow diagram, indicate the functionality at each processing node.

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

 

Room for improvement

1. In this course we did not give meaning to solid lines with arrows.  Explain what you mean by them, or don’t use them.

2. Be specific about associations: Do you mean two-way aggregations?

3. You have introduced a class whose name does not indicate a clear purpose and which is not a domain class.  Explain it’s purpose.

 

A Little room for improvement

 

1. …..

 

 

 

Project Phase 4:     Due 12/10

 

Section 1 Attach Phases 2 and 3. Response to my comments on phase 3. ( not graded, but required)

 

 

Section 2 Show representative input and output. 

 

 

Section 3 Explain the application of all of the steps covered in the notes -- explain if they did not apply.

(criterion: a. Clarity and completeness -- A = all relevant steps thoroughly implemented where applicable and explained where not)

 

Section 4 Provide a complete class diagram and other appropriate model(s), building on the models you submitted for phase 3. 

(criterion: b. clarity and completeness -- A = very clearly chosen and arranged models)

 

 

Section 5  Account of the degree to which you accomplished your requirements as given in phase 2.  Please refer to them by number (e.g., 11.3.5).

(criterion: g. degree of accomplishment.  A = excellent functional capabilities for a graduate course)  

 

Section 6. Source code.

(d. criterion: clarity -- A = extremely clear layout & code; each part easily traceable to the corresponding design element)

 

 

Please ...           

note that your class diagrams and code must be consistent; 

indicate all differences with prior design decisions;          

indicate all sections using numbered tabs (e.g., Post-it notes)

 

 

 

Forums -- past and present

Fall 2001

Fall 2002  email to the group is: 770F02@yahoogroups.com