Phase 3 - Design I - static modeling

• Tasks
• Tips

The goal in 3rd and 4th phases is to produce models of the system behaviour and complement the structural model with design-level class diagram. Dynamic description is represented as sequence- and state diagrams. Present object-based systems are usually designed in an iterative (i.e. phases are implemented in repeated cycles, a series of consecutive "mini-waterfalls") and incremental (i.e. descriptions are complemented and refined and new components are added to the system in each iteration) way. This is partially simulated in phases 3 and 4.

The analysis class diagram is mainly focused on domain classes. In the design phase the diagram is updated with essential user interface and controller classes. In addition, the domain model is refined with implemented associations and detailed operations.

Tasks

1. Based on the analysis class diagram, draw the design class diagram. Complement/divide new user interface (boundary) and controller classes and add operations to classes (note that updating the analysis class diagram is not required - is should be kept as "high-level" construct).
   
2. Define responsibilities of the most essential classes using CRC cards. Explicate the responsibilities as methods in the class diagram.
   
3. Refine the class diagram on association implementation: add reference attributes, array-typed reference attributes or optionally container classes.
4. Group the classes to packages. Depending on the tool used, actual package symbols do not need to be drawn provided that the package structure is clear from the class placement or comment marks. For larger systems, separate class diagrams for each package can be drawn. 

Tips

• Make use of collaboration diagrams and CRC cards as you specify methods in classes. You can use the following CRC card template: (html, doc, odt).
• Guidelines for drawing design class diagram:
  
• • Idealized classes representing boundary and control objects in collaboration diagrams should be partitioned to different classes (note: user interface can be still kept as general - do not model particular window objects or user interface components). See that the new classes do not contradict requirements document (=topic description), use case descriptions, or collaboration diagrams:
  • 1. Examine the techniques how theuser interacts with the system: Devices? Embedded systems? GUI- or text-based UI? Web UI? Is it possible to partition the user interface in relation to user roles (i.e. offer different services to different users), or can the UI be partitioned according to services offered by the system (i.e. one user interface module supplies a service)?
    2. Is it possible to partition the controllers to serve different actors, or can controllers be assigned to handle the application logic different funtionalities (=use cases) offered by the system? If you drew ICONIX-style robustness diagrams in phase 2, you should actually combine multiple controllers in the diagram to fewer classes (most of the ICONIX controllers end up as methods in controller classes and others) - consider the responsibilities in CRC cards.
       
  • Association implementation (see the lecture slides on detailed design and example assignment):
  • 1. 1-1-association: if the communication is unidirectional, define the sender a reference-valued attribute that contains the reference to a receiving object (e.g. volume_ref). If the communication is bidirectional, define the reference attribute to both classes.
    2. 1 to Many -association: an object belonging to class A can be associated to multiple objects belonging to class B, but objects of class B communicate only with one object of class A. Implement by defining an array- or collection-type attribute that contains references to objects of class B (e.g. Collection<B>, ArrayList<B>, B[], or BArray). Alternatively, define explicitly a new collection class that stores the references to objects in collection (e.g. CustomerContainer, Customers) - internal implementation of collection class could be array or other data structure. You can also use classes from an actual standard library of your favorite object-based language (e.g. Java Collections Framework or container classes in C++ Standard Template Library) to specify the data structure. In class B implement like 1-1 association, depending on directionality.
       
    3. Many-to-many association: object of class A can be associated to multiple objects of class B and vice versa. Implement as in 1-M-association with collections or collection classes in both directions.
  • Depending on the purpose of the system if may be necessary to add additional operations related to search and update functionality in the domain classes (add, search, update, etc).
• Package structure forms the base for (logical) system architecture and components. Consider the communication by classes within and between different packages and try to enable clear and straightforward communication with well-defined interfaces.