Design Approaches

Lecture 1 1

Design Approaches

Lecture 1 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.

Lecture 1 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.

Lecture 1 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.

Lecture 1 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.

Lecture 1 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.

Lecture 1 7

Example SpecificationFunctional 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 8

Lecture 1 9

Lecture 1 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/lectures/design-by-contract.ppt

Lecture 1 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

Lecture 1 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.

Lecture 1 13

Design by ContractAdvantages:

• 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 14

Design by ContractAdvantages:

• Blame assignment– Who is to blame if:

– Precondition doesn’t hold?

– Postcondition doesn’t hold?

• Avoids inefficient defensive checks

Lecture 1 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.

Lecture 1 16


• 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 17


• 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.


Lecture 1 18

Architecture and RDD


• RDD can facilitate component based reuse• More of a ‘system view’ rather than a user view.

Lecture 1 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.

Lecture 1 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.

Lecture 1 21


• 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 22


• 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

Lecture 1 23


• 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 24


• 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 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).

Lecture 1 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.

Lecture 1 27

Object Oriented Concepts (Summary)

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

Lecture 1 28


• 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 29


• 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 30


• 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 31


• 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 32


• 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 33


• 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.

Documents

Design Approaches