Construction 1: Interaction and Behaviour of Objects

Construction 1: Interaction and Behaviour of Objects

1. Collaboration Diagram

   • Boxes show objects, which are class instances and may be transient
   • We can link objects according to associations by drawing solid lines between them
   • Messages sent between objects, shown as arrow from sender to receiver, with hieracrchical numbered steps to show sequence of actions
     • can include <<create>> ing or <<destroy>> ing an object

2. Sequence Diagram

   • Contains same info as Collaboration diagram, but puts focus on time dimension
   • Objects shown across the page, time moves the page. Each object has a lifeline, begins and ends on creation and destruction
   • Shows focus of control over time and when the processing is current, control given to more than one object

3. Coupling

   • We want loose coupling, where classes do not depend strongly on details of other classes
     • Reusability, Modifiability, Easier understanding of classes in isolation, Can change class without affecting others, all improve maintainability
     • Keeps parts of the design clear and independent

4. Responsibility Driven Design

   • Each class is responsible for manipulating and processing its own data
   • Leads to loose coupling, and a client-server contract model
   • Advantages: loose coupling, every object considered a server, improves reliability, partitioning, and graceful degradation

5. Interfaces

   • To be used as specifications
     • Define method signatures through which classes interact
   • Strong separation between functionality and the code that implements it (information hiding)
     • clients interact in the same way whatever the implementation

6. Error Situations

   • programmer error
     • Incorrect implementation, in that it doesn't meet the specification
     • inappropriate object request, eg invalid index
     • inconsistent or invalid object state (eg by class extension)
   • Other sources of error
     • user, network, file processing
   • Defensive Programming
     • In client-server interaction:
       • should a server assume that clients are well-behaved or potentially hostile
         • Each approach requires different implementations
     • Arguments are very vulnerable client-server interfaces
       • Constructor arguments
         • initialise state of objects
       • Method arguments
         • control behaviour
       • Thus argument checking is a defensive measure
     • Can report errors either through diagnostic values or exception, exceptions are preffered
     • Clients must respond to diagnostic reports, checking diagnostic values, listening to exceptions
     • involves writing extra code
   • Error Avoidance
     • Clients can query server methods to avoid errors, but increases client -server coupling