Please use the alphabetical Index, Contents List, and your browsers search feature to find what you need.

This page generated on Mon Apr 30 13:43:26 PDT 2001. This page is a part of the CS599 course materials at the California State University, San Bernardino. It was generated from dick04.mth by Dr. Dick Botting.

Contents

    Outline for Class 4 on Software Engineering
    (Previous): [ dick03.html ]
    (Home): [ dick.html ]
    (Next): [ dick05.html ]

    Definitions
  1. OO::="Object Oriented".
  2. OOA::= OO " Analysis".
  3. OOD::= OO " Design".
  4. OOP::= OO " Programming".
  5. CRC::="Class, Responsibility, Collaboration" A CRC card way to record what objects of a given class are responsible for and who the cooperate with -- See Fowler and Scott pages 75..77 and [ paper.html ]

    Object-Oriented Analysis

     Schach suggests Three steps: Usecases, classes, dynamics. This is good. BUT he suggests using statecharts for dynamics. In the UML use sequence and collaboration diagrams FIRST. The "informal strategy" (11.5.1, stages 2 and 3) approach is pretty much discreditted, CRC cards (11.5.2) are popular these days instead. However the figure 11.7 on page 390 and Figure 11.9 on Page 392 have the wrong layout. Use the CRC card format from Fowler & Scott, OR draw a collaboration diaagram. By the way.... be suspicious of classes named "XYZ Controler" -- they may be fantasies. In this case the name "Elevator Controller" might be replaced by "Set Of Elevators".

    The Osbert Oglesby Case Study is a better case study. The "XYZ Application" and "XYZ Utilities" classes are needed for Java. Don't do them for C++!

    Usecases are classes of scenarios with similar users and goals.

    A scenario must be from the user's point of view and not expose (prejudge) any of the internal workings of the software. The scenario determines what is exposed to the user.

    Class diagrams can get very complicated (chapter 6 of Fowler and Scott). Never use a notation unless you absolutely have to! Also be ready to change your class diagrams many times. Keep them simple. Remember: It is only a metaphor. Analytical classes are in the user's mmind and may differe (subtly, completely?) from what is actually inside the software.

    Ideas: Parameters, stereotypoes, constraints, dependency, objects, classwide scope, aggregation and composition, derived attributes and relations, {constraints}, {abstract}, {frozen}, <<interface>>, lollypops, ...

    Use CRC, sequence diagrams, and collaboration diagrams (Chapter 5 of Fowler and Scott) to refine your scenarios. This starts to work on what is inside the software -- how things work together. The often lead you to revise you class diagrams.

    Ideas: creation of objects, lifelines, selfcalls and messages, [conditions], * iterations, return, destruction, ...

    Statecharts are used in both design and in analysis. They are used differently. In design they help develop code. In analysis they can (if taken strictly) tie the designers hands -- in analysis "It's Only a Metaphor". It says what the user thinks is happening.... not what the software actually is doing.

    . . . . . . . . . ( end of section Object-Oriented Analysis) <<Contents | Index>>

    Elevator Case Study

    Has an bad pair of UseCases. The user may push buttons but this does not make them usecases. A usecase represents a complete sequence of interations that achieve something useful. I'd have a single usecase: "Move from one floor to another".

    Evolution

     Three things always happen to existing pieces of software:
    1. It is used in other software. -- -- --(reused)
    2. It is moved to a new platform. -- -- --(ported)
    3. It is controlled by other programs. -- -- --(interoperation)

    Good software has to support these three things.

    Activities

    Object-Oriented Activity

     One way to sharpen our grasp of objects is to use Class, Responsibility, Collaboration (CRC) Cards. (Fowler and Scott, page 75).

  6. CRC walkthroughs: relax and have fun. As a team, on your board:
    1. List the names of classes in Phase I of your project.

    2. Draw CRC boxes (page 75-77 of Scott and Fowler) on board for each class -- with name and responsibilities.

    3. Manager lead a walkthru with people playing the objects of each class. Librarian notes what happens. Note: The manager plays the part of the user but doesn't tell objects what to do. Each object(play of a part) has to do what is on their cards and call on others for help.

    4. If there is nobody to help then add responsibilities to classes or add new classes.

    5. If class needs to use another class note the collaboration on the CRC.

    6. Watch out for classes that do everything -- they may have low cohesion and get coupled to many other classes.

    7. Review, improve CRCs, repeat.

    8. (Optional) record complicated collaborations and/or sequences using the UML.

    9. Update or make a class diagram using the UML of classes, functions, and associations. Each collaboration needs to follow some association. Each responsibility becomes an operation/functions. But do not over-specify.

    10. Librarian records result. Text? Diagrams? Make sure all get to see it.

    11. Share the result with the teacher. (But don't Email diagrams!)

    . . . . . . . . . ( end of section Activities) <<Contents | Index>>

    Deliverables

    . . . . . . . . . ( end of section Outline for Class 4 on Software Engineering) <<Contents | Index>>

    Next

    [ dick05.html ]

Formulae and Definitions in Alphabetical Order