©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented as a set of interacting objects that manage their own state and operations To introduce various models that describe an object- oriented design To show how the UML may be used to represent these models To introduce design patterns

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 2 Characteristics of OOD l Objects are abstractions of real-world or system entities and manage themselves l Objects are independent and encapsulate state and representation information. l System functionality is expressed in terms of object services l Shared data areas are eliminated Objects communicate by message passing l Objects may be distributed l Objects may execute sequentially or in parallel

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 3 Interacting objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 4 Advantages of OOD l Easier maintenance. Objects may be understood as stand-alone entities l Objects are appropriate reusable components l For some systems, there may be an obvious mapping from real world entities to system objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 5 Object-oriented development l Object-oriented analysis, design and programming are related but distinct l OOA is concerned with developing an object model of the application domain l OOD is concerned with developing an object- oriented system model to implement requirements l OOP is concerned with realising an OOD using an OO programming language such as Java or C++

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 6 Objects and object classes l Objects are entities in a software system which represent instances of real- world and system entities l Object classes are templates for objects Classes may be used to create objects l Object classes may inherit attributes and services from other object classes

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 7 Object communication l Conceptually, objects communicate by message passing l Messages The name of the service requested by the calling object. Copies of the information required to execute the service and the name of a holder for the result of the service. l In practice, messages are often implemented by procedure (a.k.a. method) calls Name = method name Information = parameter list Result holder = method return value

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 8 Message examples //Call a method associated with a buffer //object that returns the next value //in the buffer v = circularBuffer.Get () ; //Call the method associated with a //thermostat object that sets the //temperature to be maintained thermostat.setTemp (20) ;

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 9 Generalisation and inheritance l Objects are members of classes which define attribute types and operations l Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes) l A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own l It is a reuse mechanism at both the design and the programming level l Inheritance introduces complexity and this is undesirable, especially in critical systems

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 10 A generalisation hierarchy

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 11 Object Relationships l Objects and object classes participate in relationships with other objects and object classes In UML, such a relationship is indicated by an association l Associations may be annotated with information that describes the association

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 12 Concurrent objects l The nature of objects as self-contained entities make them suitable for concurrent implementation l The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system l Active objects have an internal thread of control and may change their own state

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 13 Object identification l Identifying objects (or object classes) is the most difficult part of object oriented design l There is no “magic formula” for object identification It relies on the skill, experience and domain knowledge of system designers l Object identification is an iterative process You are unlikely to get it right first time

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 14 Approaches to identification l Use a grammatical approach based on a natural language description of the system (used in Hood method) l Base the identification on tangible things in the application domain l Use a behavioural approach and identify objects based on what participates in what behaviour l Use a scenario-based analysis – the objects, attributes and methods in each scenario are identified

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 15 Object interface specification l Object interfaces have to be specified so that the objects and other components can be designed in parallel l Designers should avoid designing the interface representation but should hide this in the object itself l Objects may have several interfaces which are viewpoints on the methods provided

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 16 Identifying HazMat Rover Objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 17 Design models l Design models show the objects and object classes and relationships between these entities l Static models describe the static structure of the system in terms of object classes and relationships l Dynamic models describe the dynamic interactions between objects.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 18 Examples of design models l Sub-system models that show logical groupings of objects into coherent subsystems UML package diagrams l Sequence models that show the sequence of object interactions UML sequence diagrams l State machine models that show how individual objects change their state in response to events UML statechart diagrams l Other models include use-case models, aggregation models, generalisation models,etc.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 19 Weather station subsystems

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 20 Weather station data collection sequence

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 21 Statecharts l Object states l State transitions triggered by requests to objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 22 Design patterns l A design pattern is a way of reusing abstract knowledge about a problem and its solution l A pattern is a description of the problem and the essence of its solution l It should be sufficiently abstract to be reused in different settings l Patterns often rely on object characteristics such as inheritance and polymorphism

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 23 Pattern elements l Name A meaningful pattern identifier l Problem description l Solution description Not a concrete design but a template for a design solution that can be instantiated in different ways l Consequences The results and trade-offs of applying the pattern

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 24 Multiple displays enabled by Observer

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 25 The Observer pattern l Name Observer l Description Separates the display of object state from the object itself l Problem description Used when multiple displays of state are needed l Solution description See slide with UML description l Consequences Optimisations to enhance display performance are impractical

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 26 The Observer pattern

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 27 l OOD is an approach to design in which design components have private state and operations l Objects provide services to other objects l Objects may be implemented sequentially or concurrently l The Unified Modeling Language provides different notations for defining different object models l Object-oriented design simplifies system evolution l Design patterns are generic, reusable design templates Key points