Design Approaches

1
Design Approaches
2
Responsibility Driven Design

• Maximize Abstraction Hide the distinction
  between data and behaviour. Think of
  responsibilities for knowing, doing, and
  deciding, keeping track of
• Distribute Behaviour Make objects smart have
  them behave intelligently, not just hold bundles
  of data. Objects should not be too lean or too
  fat.
• Preserve Flexibility Design objects and
  collaborations so they can be readily changed.
  Responsibility-Driven Design is a set of tools
  for thinking about systems. It emphasises the
  concepts of Class, Responsibility and
  Collaboration. Objects behave by knowing, doing
  and deciding. behaviour of classes of objects,
  first, data second.
• Responsibility-Driven Design is a set of tools
  for thinking about systems. It emphasises the
  concepts of Class, Responsibility and
  Collaboration. Objects behave by knowing, doing
  and deciding. behaviour of objects, first, data
  second.

3
Responsibility Driven Design

• Using RDD produces a different type of
  architecture based more on the class diagram than
  the use case diagram.
• RDD can facilitate component based reuse
• More of a system view rather than a user view.

4
Use Case Driven Design

• The Unified Process (UP) is use case driven,
  meaning
• Systematic use is made of use cases various
  stages in the design process, realization of use
  case.
• Tests can be systematically derived from use
  cases to provide acceptance tests for the system.
• Use cases are a good way to structure
  requirements, but there are issues not addressed.
  
• Some classes that do not interact with the system
  but are still important.
• Component based development, reuse, architectures
  also need to be considered.
• With UCDD the idea is to keep focus on use cases
  throughout a development, not just in
  requirements capture. Keeps attention on the
  requirements.
• There is good tracability from use case to code
  because every use case links to a method in the
  same System class (if every use case is realized
  as a class).
• No single viewpoint (RDD or UCDD) suited to all
  projects.

5
RRD differs from UCDD

• RRD differs from UCDD UCCD emphasise on the
  required user perceived system functionality is
  of RDD focuses on the behaviour of classes of
  objects.
• UCDD emphasises the requirement while RRD
  emphasis the system.
• 1) Using UCDD the system may end up being a
  top-down function-oriented system, which produces
  an inflexible and a difficult-to-maintain system.
  Focusing on the use cases may cause the
  developers to sacrifice the object-oriented
  nature of the system thus losing any advantage
  that such an approach offers. RDD takes a system
  view
• 2) Another danger of UCDD lies in mistaking
  design for requirements, where a design decision
  is mistaken for a constraint. Focusing on the
  requirements in a use case may cause developers
  to view the system too operationally, where a
  sequence of events is assumed to be the only
  answer. Developers need to distinguish between
  requirements and preferred designs. RDD focuses
  on the structure and behaviour of the software
  system.
• 3) There is a danger of missing some of the
  requirements especially if emphasis is placed on
  actors and their tasks, because not all the
  requirements will emerge in this process. A
  developer should use more that just one model of
  a proposed system. Ignoring the non-user
  interactions can lead to missing important
  information (e.g. Customer in BookingSystem). ,
  RRDD specifically seeks out key components of the
  system.
• RDD class modeling should be performed alongside
  use case modeling since one informs the other.
  This illustrates that use cases help mainly with
  requirements capture and testing but not with the
  design. Should not let any single viewpoint
  drive a project.

6
Example Specification

• A manufacturing company makes products to order
  for their customers. They have commissioned a
  software system to support their order processing
  workflow. The order processing system (OPS) will
  handle quotations, orders, delivery and invoicing
  for the company. The system will deal with only
  one product per order. The sales team and their
  manager will use the system. The OPS will
  interact with the production department and to
  the sales ledger, which is part of the existing
  accounting system. The following is a
  description of the main functional areas of
  interest.

7
Example Specification
8
(No Transcript)
9
(No Transcript)
10
Design by Contract

• A way of recording
• Details of method responsibilities
• Avoiding constantly checking arguments
• Assigning blame across interfaces
• See
• http//www.ccs.neu.edu/home/lieber/com3220/sp99/le
  ctures/design-by-contract.ppt

11
Design by Contract

• Principles Design by contract (DbC) is a design
  philosophy that that makes the sender of a
  message responsible for guaranteeing the
  pre-conditions of the operation. As a result the
  designer of an operation does not have to decide
  what to do when the precondition or posconditions
  fails. The contracts between objects are
  expressed as assertions. Design by contract means
  that for methods used in one object but provided
  by another, that is invoked by a client from a
  supplier, the client code guarantees any
  preconditions, and the supplier code guarantees
  post-conditions and invariants. Such guarantees
  must be describable statically. If the client
  fulfils the preconditions then the server should
  fulfil the post-conditions. The subclass is
  supposed to be able to fulfil the contract
  entered into by the superclass. An object of a
  subclass is supposed to be usable everywhere that
  the superclass is. The subclass is supposed to be
  able to fulfil the contract entered into by the
  superclass

12
Design by Contract

• Using DbC during development Using design by
  contract assertions can be introduced early in
  the development process, during analysis. As
  development progresses so the assertions will be
  refined with more detail being added. Assertions
  can be carried through into design and then into
  implementation. Importantly, assertions can be
  included in the final code to be checked both by
  the compiler and by the run-time system.
  Ultimately, the contract is embodied in the code
  and we have a traceable pathway from analysis to
  implementation that shows how the assertions were
  developed and relates the code directly to the
  requirements. At the implementation level, if
  the software representing the client and supplier
  meets its contract we can say that the software
  is correct with respect to its specification.

13
Design by Contract

• Advantages
• 1) traceability of assertions from analysis to
  implementation allows the developer to associate
  runtime activities or errors with design
  artefacts, hence a runtime error may be traceable
  to a design decision or design refinement. (a use
  case).
• 2) a (semi) formal way of stating correctness,
  the implementation respects the invariants,
  pre/post conditions in the specification. This
  can be agreed upon by both developer and client
  to be correct with respect to the specification.

14
Design by Contract

• Advantages
• Blame assignment Who is to blame if
• Precondition doesnt hold?
• Postcondition doesnt hold?
• Avoids inefficient defensive checks

15
Responsibility-Driven Design

• Responsibility-Driven Design is a set of tools
  for thinking about systems. It emphasises the
  concepts of Class, Responsibility and
  Collaboration. Objects behave by knowing, doing
  and deciding. Behaviour first. Data second .
  Class, responsibilities, collaborators are
  central concepts
• Class A class describes the behaviour of a set of
  objects of the same kind. Identifies class on
  card essential when acting out scenarios.

16
Responsibility-Driven Design

• Responsibilities are the knowledge that a class
  maintains and services that it provides. When
  acting out scenarios analyst must be able to
  develop or know the current responsibilities of a
  class. By discussing a problem in terms of
  responsibilities we increase the level of
  abstraction. This permits greater independence
  between objects, a critical factor in solving
  complex problems. The entire collection of
  responsibilities associated with an object is
  often described by the term interface or
  protocol.

17
Responsibility-Driven Design

• Collaborators A collaborator is a class whose
  services are needed to fulfil a responsibility.
  Collaborators must be related to the
  responsibilities that they help fulfil (1M).
  Collaborators may help fulfil responsibilities
  for several classes. Collaborations only exist to
  fulfil responsibilities. Collaborations are
  modelled as one way communications from initiator
  class to collaborator , the response is a message
  answer.
• The above ideas can be combined using CRC cards.
• Using RDD produces a different type of
  architecture based more on the class diagram than
  the use case diagram.

18
Architecture and RDD

• Using RDD produces a different type of
  architecture based more on the class diagram than
  the use case diagram.
• RDD can facilitate component based reuse
• More of a system view rather than a user view.

19
Unified Process Views (Summary)

• The use case view. This contains the basic
  scenarios that describe the users and the tasks
  that they need to perform with the aid of a
  software system. These scenarios are partitioned
  into use cases. This view validates the logical,
  process, component and deployment views. Focuses
  on understandability and usability. The UCV
  defines the systems external behaviour and is of
  use to users testers and analysts. It contains
  the requirements of the system and therefore
  constrains the other views, which describe the
  certain aspects of systems design or
  construction. This view is central to UP a use
  case driven approach. Useful for analysts, users
  and testers. Serves as the starting point for all
  subsequent development
• Diagrams Use case diagram. Object, sequence
  diagrams and collaboration diagrams are created
  to show how the various design elements interact
  to produce the desired behaviour.

20
Unified Process Views (Summary)

• The logical (or design) view. This is concerned
  with the functional requirements of the software
  system, a system focus. Useful for programmers as
  basis for coding. What should the software do for
  its intended users?
• Diagrams Typically, this involves the
  construction of one or more class diagrams. Like
  the UCV object, sequence diagrams and
  collaboration diagrams are used. However, here
  they are used to refine class diagram. Activity
  diagrams and state charts are also used in the
  design view.

21
Unified Process Views (Summary)

• The implementation view. This is concerned with
  the organization of the module that comprises a
  software system. Typically, it addresses the
  management of source code, data files and
  executables. A component typically maps to one or
  more classes, interfaces or collaborations.
  Useful for configuration management etc
• Diagrams Component diagrams (CD) represent the
  organization and dependencies among a set of
  components. A CD is a static implementation view
  of the system.

22
Unified Process Views (Summary)

• The deployment view. This is concerned with the
  relationship between the various executables (and
  other run-time components) and their intended
  computer systems
• Diagrams a deployment diagram is a configuration
  of run-time processing nodes and their components
  that live on them. DDs provides a static
  deployment view. DDs shows how the components
  are mapped onto processors

23
Unified Process Views (Summary)

• The process view. This is concerned with aspects
  of concurrency, distribution. What are the
  processes and threads? How do they interact? It
  deals with such things as response time, deadlock
  and fault tolerance.
• Diagrams Activity diagrams and statecharts are
  used in the process view. Statechart diagram
  are state machine (dynamic process view of the
  system)
• Emphasize event-ordered behavior of an object
  (useful in modeling reactive systems). They can
  be used to model behavior of an interface, class,
  or a collaboration. Activity diagram a bit like
  statechart with an activity flow (function of a
  system work flow of control among objects). This
  provides a dynamic process view of the system.

24
Unified Process Views (Summary)

• These views are related as in the diagram below,
  the use case view can be seen as central in that
  it relates the other views. This point could be
  included in UCV or mentioned separately.

25
How many diagrams? (Summary)

• One diagram type is not adequate to model the
  diverse aspects of systems.
• 1) The UML recognises that people have
  preferences, and that the main purpose of these
  diagrams is to communicate ideas with colleagues
  and clients. The UCD has a different audience
  than the statechart.
• 2) Different views of a system may more usefully
  be illustrated by different diagrams.
• 3) The diagrams individually do not capture the
  full meaning of the structure of the software, or
  its behaviour.
• 4) We are interested in different aspects of a
  design at different times (e.g. use case for
  requirements is user focused and statechart for
  modelling low level state change). More generally
  we need
• A static model which describes the elements of
  the system and their relationships to other
  elements (class diagrams).
• A dynamic model which describes the behaviour of
  a system over a period of time. (e.g. sequence
  diagrams).

26
Unified Process (UP) requirement document
(Summary)

• In a project using the Unified Process (UP) for
  requirement capture the principal components that
  you would expect in the requirements would be UC
  diagrams, domain model, textual description, and
  glossary. The textual description could be
  similar to the description of the hospital system
  found in appendix. It describes the main features
  of the domain and expected functionality. UP
  starts with use cases describing how users
  interact with the system. A domain model records
  facts about real world entities, the UML use case
  and class diagrams document these. The domain
  model is later refined. Systematic use is made of
  use cases various stages in the design process,
  realization of use case. The glossary records
  terms and their definitions for use throughout a
  project.

27
Object Oriented Concepts (Summary)

• The main concepts include classes, objects,
  encapsulation, messages, inheritance,
  polymorphism.

28
Object Oriented Concepts (Summary)

• Classes
• A class consists of a name, attributes,
  operations, associations with other classes, and
  semantics. Like a table in relational theory a
  class is the basic conceptual unit of OO. A
  class describes the behavior of a set of objects
  of the same kind.
• Classes are abstractions that allow us to filter
  out the detail of the real world objects in order
  to develop domain classes. They are the
  conceptual unit of OO that help the analyst
  identify real word and system objects. Classes
  can be used to focus on system aspects and
  structure (the abstract Doctor). The class is
  essential when building domain models. Classes
  represent both domain (e.g. Ward) and system
  concepts. Classes are abstractions. Ward is an
  abstraction of particular real world wards, while
  the abstract Doctor facilitates reuse discovered
  during system design. Note the difference between
  domain and system abstraction.

29
Object Oriented Concepts (Summary)

• Objects
• On object is an instance of a class. The class is
  essential when building domain models but the
  objects are necessary when acting out scenarios
  (or use cases). Object diagrams have a different
  notation to class diagrams, there is an
  underlined object name and class e.g. aWardWard .

30
Object Oriented Concepts (Summary)

• Encapsulation
• Encapsulation is the hiding from clients of a
  class the details of how the class is
  implemented. The visibility of the UML provides
  some degree of control of encapsulation(,,-,).
  
• Encapsulation eases integration As users of an
  object cannot access the internals of the object
  they must go via specified interfaces. As these
  interfaces can be published in advance of the
  object being implemented, others can develop to
  those interfaces knowing that they will be
  available when the object is implemented.
• Encapsulation eases maintenance As users of an
  object have been forced to access the object via
  the specified interfaces, as long as the external
  behavior of these objects appears to remain the
  same, the internals of the object can be
  completely changed.

31
Object Oriented Concepts (Summary)

• Messages
• This is a request from one object to another
  object requesting some operation or data. It is
  traditional to say that one object sends a
  message to another object requesting it to do
  something. The idea is that objects are polite
  well behaved entities which carry out functions
  by sending messages to each other. In other
  languages it might be consider akin to a
  procedure call.

32
Object Oriented Concepts (Summary)

• Inheritance
• The principle that knowledge of a more general
  category is also applicable to a more specific
  category is called inheritance. Classes can be
  organized into a hierarchical inheritance
  structure. A child class (or subclass) will
  inherit attributes from a parent class higher in
  the tree. An abstract parent class is a class
  (such as Mammal ) for which there are no direct
  instances it is used only to create subclasses.
  Abstract classes, were never intended to be
  executed so can be regarded as specification.
  Class hierarchies are constructed where there is
  commonality of state (attributes) or behavior
  (methods) and permit reuse. There are at least
  four types of inheritance substitution (or
  behaviour) inheritance, inclusion inheritance,
  constraint inheritance and specialization
  inheritance. Inheritance can be used as a
  taxonomy mechanism for domain modelling.

33
Object Oriented Concepts (Summary)

• Polymorphism
• Polymorphism is the ability of objects to send
  the same message to instances of different
  classes (if they do not have a common superclass
  this is polymorphism without inheritance). It is
  possible that the methods are defined differently
  in sub-hierarchies i.e. the subclass methods do
  not share the same super class definition.
• Simplified code - polymorphism. With polymorphism
  you dont need to worry about exactly what type
  of object you will get at run time, only that it
  must respond to the message (request for a method
  to be executed) that is sent to it. This means
  that it is a great deal easier to write reusable,
  compact code, than in many other languages.