CSE 111 - Object Oriented Software Design

Lectures

Lecture 1: Process, Requirements and Use Cases
Slides: ppt | pdf
Related Reading: Larman, Chapters: 1-6
Project:

  1. Concept description. Provide a one or two paragraph description of your proposed project.
  2. Construct Use Cases for your project. These should be for the whole functionality, not just the Phase 1 functionality. Use the paragraph style for use cases, from Larman on pp. 67 - 72.
  3. Choose the limited functionality for the Phase 1 iteration.

Lecture 2: Elaboration and Domain Models
Slides: ppt | pdf
Related Reading: Larman, Chapters: 8-9
Project:

  1. Construct a domain model for the Phase 1 functionality.

Lecture 3: System Architecture
Slides: ppt | pdf
Related Reading: Larman, Chapter 13
Project:

  1. Describe the anticipated system architecture for your system. Do you see any possible uses for Observer/Observable?

Lecture 4: Sequence Interaction Diagrams
Slides: ppt | pdf
Related Reading: Larman: Chapter: 10; pp. 227 - 247
Project:

  1. Construct Sequence Interaction Diagrams for the use cases that will be implemented in Phase 1. These should show interactions between the user and the system, and between subsystem components.

Lecture 5: Collaboration Diagrams
Slides: ppt | pdf
Related Reading: Larman: Chapter 15
Project:

  1. No specific task. Continue making progress

Lecture 6: Design Evaluation and Basic Patterns
Slides: ppt | pdf
Related Reading: Larman: Chapter 17
Project:

  1. Construct collaboration diagrams for the design of phase 1
  2. Identify occurrences of the basic patterns (Expert, Creator, Controller)
  3. Evaluate your design with respect to Cohesion and Coupling

Lecture 7: Functional and Design Descriptions
Slides: ppt | pdf
Related Reading: Larman: Chapter 16, 19
Project:

  1. Do a visibility analysis of your design.
  2. Construct Design Class Diagrams showing associations, dependencies and attributes.

Lecture 8: O/O Programming
Slides: ppt | pdf
Related Reading: Larman: Chapter 20

Lecture 9: Catching up and Midterm review
Slides: none
Related Reading: none
Project:

  1. Continue making progress

Lecture 10: Midterm
Slides: none
Related Reading: none
Project:

  1. Continue making progress
  2. First deliverables due on lecture 12!

Lecture 11: UML Terminology and Additional Models
Slides: ppt | pdf
Related Reading: Larman: pp. 260, 264, 509 - 519, 525-527
Project:

  1. Phase 2: Create domain models for the full system, incorporating generalization and aggregation notation and examples. Use the guidelines to justify your examples of generalization and aggregation.

Lecture 12: State Diagrams
Slides: ppt | pdf
Related Reading: Larman: Chapter 29
Project:

  1. Phase 1 Due
  2. Phase 2: Use one or more state models to specify the GUI structure for your second phase system.

Lecture 13: Programming by Contract
Slides: ppt | pdf
Related Reading: Larman: Chapter 11
Project:
  1. Construct informal subsystem contracts for each of the subsystem operations, containing:
    • descriptive name
    • precondition
    • postcondition
    The post-condition for a subsystem S operation contract description needs to only include the resulting state changes in S caused by the operation. e.g. the GUI contract description for the addMember event only describes changes in the state of the GUI, not the resulting changes that are caused in the state of the DataBase subsystem/object.
    Susbsystem operations correspond to messages received by the subsystems (e.g. DomainLogic, and DataBase).

Lecture 14: Callbacks, Singletons and Wrappers
Slides: ppt | pdf
Related Reading: Larman: pp. 442 - 446, 436 - 438
Project:

  1. Construct collaboration diagrams for the design of the phase2 GUI.
    1. In doing this incorporate the new features from phase 2 that affect the GUI (e.g. administrator options, system feature requiring call back.)
    2. Incorporate the use of call backs for one of the features. This is the feature in DS whereby a message is printed out if DL discovers some special condition. In this approach the GUI constructor will register a call back object with Domain Logic (to which it must have visibility). The execution of the call back object in the Domain Logic subsystem will prompt the GUI into displaying an appropriate message.
    3. Try out the singleton pattern in the phase 2 GUI. In the DS we did this as follows. Instead of creating a new message dialog box to display a message each time a message needs to be generated, use the singleton pattern to construct a message dialog class that supports the singleton pattern. Note: in Java a class with static items cannot be an inner class, so if your design has the dialogs as inner classes of a main GUI frame class, this will have to be an exception, and be moved to the top level.

Lecture 15: Polymorphism and State Patterns
Slides: ppt | pdf
Related Reading: Larman: pp. 414 - 421, 642 - 645
Project:

  1. Construct collaboration diagrams for the design of the Phase 2 DomainLogic
    1. In doing this incorporate the new Phase 2 features that affect the DomainLogic (e.g. special callback feature, and the trap door feature)
    2. Use a decorator/wrapper in the phase 2 design. In the DS example, we did this as follows. When the GUI sends a get a date message to the DL, it looks to see if this is a special user Pamela. If so, instead of doing a full date search, it returns the name of Dave, the programmer who wrote the system, with his properties changed to match those of the date request. This was implemented with a decorator wrapper that used the regular DateRequest class, and augmented it with this additional functionality.
    3. Also try to incorporate the state pattern into your design. In the DS, we did the following. We considered DomainLogic to be in different states depending on whether a member, the administrator, or an unauthorized person is logged on. DomainLogic acts differently depending on which user state the system is in. States were used to incorporate this aspect of the system into its design and impelementation.
    4. Remember to use the patterns and design evaluation guidelines that were previously discussed. In particular try to use expert/object animation for performing some of the requests made to DomainLogic.

Lecture 16: Factories and Frameworks
Slides: ppt | pdf
Related Reading: Larman: pp. 625 - 628, 441 - 442
Project:

  1. Construct collaboration diagrams for the Phase 2 DataBase subsystem. Construct it by first building a framework, which you subclass for your program. How this could be done in the DS example is described below.
  2. (Recall that it may help to construct class descriptions/diagrams at the same time, or even before some of the collaboration diagrams, even though they will not be required until the next exercise.)
  3. Notes for phase 2 data base part of project:
    1. Recall that in Phase 1 our approach to persistent object management was to use files. Between uses of the data base system, the data base of data items is saved, and then restored for access when the system is restarted. The data base for Phase 2 must also have the functionality that is required for the administrator functions, not included in Phase 1. You may have included a feature for adding data in Phase 1 in order to allow the start up use case to load up a (dummy) in memory data base with data, since there was no persistent object management in our DB subsystem.
    2. Proxy/facade subsystem. Our Phase 1 system design includes an interface that is implemented by a facade that acts as a subsystem controller. For the purposes of not disturbing the other parts of the system (GUI and DomainLogic), we will keep this.
    3. DataBase charcteristics. Our system requires a data base that has the following characteristics:
      • the objects that we want to store have instance variables that themselves have objects as values (e.g. in Dating System, MemberData objects have instance variables of type DateeData and AdminData), but there is no shared use here, each main data record has unique values for these instance variables.
      • the referenceable objects have an attribute whose value is unique and can act as a key for the objects.
      • we could have an in-memory array that is used to store the data objects
      • it is reasonable to store each data object and its instance variable object values in a sequence of consecutive bytes in a file, like a kind of virtual record. Each object could be written out to the file when the object data base is saved, and the saved data could be easily used to reconstruct the objects when they are read back in during system startup.
      • the constructor for the data base could be used to read in the objects from the file of saved objects/records and create the internal object array
      • a closeDB() operation that would write the array back out to the file where the data base was stored
      • a general approach would be create a file that we wrote to using a (PrintWriter (new FileWriter(file))) stream and read from using a BufferedReader( new (FileReader(file)) stream. The operations to be used would be println and readln.
      • the operations we want to perform on the database, e.g. getFirst(), getNext(), getData(x), addData(x), etc. are quite general, and we could imagine reusing the data base in other applications in which x would be replaced with similar kinds of persistent data objects.
    4. DataBase framework
      • the above describes is a fairly general kind of simple data base, so we would like to construct a simple data base framework that we could use for different kinds of objects that play a similar role to MemberData in the Dating System example
      • in our framework, we could require that the data objects be instances of a subclass of a general PersistentObjects class which would have read and write operations. These file methods will have to work with the file structure we adopted for the data base framework. They would take all of the details of how you read and write a specific subclass of PersistentObjects and put them in the specific object's class definition, in the spirit of object animation. i.e. we assume that objects in an application specific subclass of PersistentObject know how to read and write themselves to and from the data base back-up file.
    5. DataBaseFramework and the Factory pattern
      • our database framework's constructor will need to read object records in from a file and store them as objects in an object array. This means it will have to create objects of the appropriate subclass of PersistentObject. But this class will not be known, so we have to defer the details of how they are created. We can do this using the factory pattern.
      • the DataBaseFramework can have an abstract method createObject(), which is defined when the framework is subclassed to create an actual database. The abstract version of createObject() will have a PersistentObject return type, since the definitions for abstract methods must have the same signature as the abstract methods. However, our concrete createObject() method will use the constructor for the actual, application specific, type of data that we are going to use (e.g. MemberData).
      • the PersistentObject objects returned by the createObject() method defined in the framework subclass will have the properties of the application specific subclass of PersistentObject, and could, for example, be cast as that type of data.
    6. Dating System data base
      • for the DataBase part of our DatingSystem, we defined the DataBase to be a subclass of a general DataBaseFramework of the kind discussed above. We used a general data class PersistentData of which objects such as MemberData from the Dating System example will be a subclass. We used a factory pattern in which the framework has a create() method for returning instances of PersistentData which in the sample system DataBase subclass of the framework is defined to be a method that creates an instance of the appropriate type, such as MemberData in the dating system.
      • we retained the facade/interface so as to ensure complete compatibility with the other parts of the system, and consistency with the data base stub that was used to construct and test them.

Lecture 17: Patterns Potpourri
Slides: ppt | pdf
Related Reading: Larman: pp. 421, 447 - 452, 452 - 460, 461 - 463, 645, 647 - 651
Project:

  1. Construct the class diagrams and start coding. Identify any of these additional patterns that you use.

Lecture 18: Anti-patterns and refactoring
Slides: ppt | pdf
Related Reading: none
Project:

  1. Finish the coding for Phase 2

Lecture 19: Introduction to Components
Slides: ppt | pdf
Related Reading: Larman: p. 605
Project:
finish up.

Lecture 20:
Project:
Phase 2 due : 6/7/07