Design Approaches
Lecture 1
1
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.
Lecture 1
2
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.
Lecture 1
3
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.
Lecture 1
4
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.
Lecture 1
5
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.
Lecture 1
6
Example Specification
Functional Area
Description
Quotations
No order can be taken without a valid quotation. The OPS will assist the sales team
in preparing quotations. Each quotation should be associated with a particular
product. Quotations are required for standard and non-standard products. Each
quotation entails an estimation process and a possible estimation for non-standard
products.
Cost Estimation
When estimating costs the salesperson needs both product and customer information.
Cost estimates are based on various criteria such as quality, components, standard or
non-standard product. Cost estimation for non-standard products required additional
processing.
Order Entry
A member of the sales team records an initial order or may change an existing order.
The sales manager must approve orders.
Production
When an order has been accepted the production process for that product should be
initiated.
Delivery
When the production department has produced the required product, the production
department ships the product to the customer and the production department
confirms the delivery. The sales team is notified of the delivery and generates an
invoice for the delivered product.
Invoicing
Payment is expected within a month of delivery. In case of order cancellation or
customer queries on pricing, the sales manager must approve any changes to
invoices.
Sales Ledger
The OPS must integrate with the existing sales ledger by sending invoice information
to the sales ledger.
Lecture 1
7
Lecture 1
8
Lecture 1
9
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/sp
99/lectures/design-by-contract.ppt
Lecture 1
10
Design by Contract
• Principles: Design by contract (DbC) is a design philosophy that that
makes the sender of a message responsible for guaranteeing the preconditions 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
Lecture 1
11
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.
Lecture 1
12
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.
Lecture 1
13
Design by Contract
Advantages:
• Blame assignment– Who is to blame if:
– Precondition doesn’t hold?
– Postcondition doesn’t hold?
• Avoids inefficient defensive checks
Lecture 1
14
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.
Lecture 1
15
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.
Lecture 1
16
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 (1:M).
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.
Lecture 1
17
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.
Lecture 1
18
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.
Lecture 1
19
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.
Lecture 1
20
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.
Lecture 1
21
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
Lecture 1
22
mapped onto processors
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.
Lecture 1
23
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.
Lecture 1
24
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).
Lecture 1
25
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.
Lecture 1
26
Object Oriented Concepts
(Summary)
• The main concepts include classes, objects,
encapsulation, messages, inheritance,
polymorphism.
Lecture 1
27
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.
Lecture 1
28
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. aWard:Ward .
Lecture 1
29
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.
Lecture 1
30
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.
Lecture 1
31
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.
Lecture 1
32
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
don’t 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.
Lecture 1
33