1. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design

2. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 2 Objectives An Object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state. Objectives: l To explain how a software design process involves designing objects classes and the relationships between these classes; l To describe the activities in the object-oriented design process l To introduce various models that can be used to describe an object-oriented design l To show how the UML may be used to represent these models

3. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 3 Topics covered l Objects and object classes l An object-oriented design process l Design evolution

4. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 4 Object-oriented development (1/2) l Object-oriented Analysis, Design and Programming are related but distinct stage: l OOA is concerned with developing an object model of the application domain: These model reflect the entities and operations associated with the problem to be solved (i.e., express the system requirements). Problem objects are identified. l OOD is concerned with developing an object-oriented system model to implement the identified requirements: There may be close relationships between some problem object and some solution object. l OOP is concerned with realising an OOD using an OO programming language such as Java or C++: Define object classes; Provide a run-time system to create objects from these classes

5. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 5 Object-oriented development (2/2) l Compatible notation should be used at each stage; l Moving to the next stage involves refining the previous stage by adding detail and devising new classes to provide additional functionality; l As information is concealed (information hiding), detailed design decision about the representation of data can be delayed until the system is implemented.

6. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 6 Example: Model Driven Architecture l MDA proposes that system design can be devised in two levels: 1.Implementation-independent level: 1. An abstract model is designed. 2.Implementation-dependent level: 1.A platform-dependent model is designed and can be used as a basis for code generation. l MDA approach is still experimental ….

7. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 7 Interacting objects

8. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 8 From chapter 8: Object models during requirements analysis l Object models describe the system in terms of object classes and their associations. l It is useful to combine data-flow models and semantic data models; l An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object: no details are included. l Various object models may be produced Inheritance models; Aggregation models; Interaction models. l Developing object models during requirements analysis simplifies the transition to object-oriented design and programming.

9. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 9 From chapter 8: Object models during requirements analysis l Natural ways of reflecting the real-world entities manipulated by the system l More abstract and high-level entities are more difficult to model using this approach l Object class identification is recognised as a difficult process requiring a deep understanding of the application domain l Object classes reflecting domain entities are reusable across systems

10. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 10 From chapter 8: Inheritance models during requirements analysis l Organise the domain object classes into a hierarchy. l Classes at the top of the hierarchy reflect the common features of all classes. l Object classes inherit their attributes and services from one or more super-classes. These may then be specialised as necessary. l Class hierarchy design can be a difficult process if duplication in different branches is to be avoided.

11. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 11 From chapter 8: Object models and the UML l The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods. l It has become an effective standard for object- oriented modelling. l Notation Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section; Relationships between object classes (known as associations) are shown as lines linking objects; Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy.

12. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 12 From chapter 8: Library class hierarchy

13. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 13 From chapter 8: User class hierarchy

14. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 14 From chapter 8: Multiple inheritance l Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes. l This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. l Multiple inheritance makes class hierarchy reorganisation more complex.

15. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 15 From chapter 8: Multiple inheritance

16. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 16 From chapter 8: Object aggregation l An aggregation model shows how classes (that are collections) are an “aggregate” of a set of other classes. l Aggregation models are similar to the part-of relationship in semantic data models.

17. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 17 From chapter 8: Object aggregation

18. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 18 From chapter 8: Object behaviour modelling l A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use- case. l Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects.

19. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 19 From chapter 8: Issue of electronic items

20. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 20 From chapter 8: Semantic data models l Used to describe the logical structure of data processed by the system. l An entity-relation-attribute (ERA) model sets out the entities in the system, the relationships between these entities and the entity attributes l Widely used in database design. Can readily be implemented using relational databases. l No specific notation provided in the UML but objects and associations can be used.

21. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 21 From chapter 8: Library semantic model

22. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 22 From chapter 8: Data dictionaries l Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. l Advantages Support name management and avoid duplication; Store of organisational knowledge linking analysis, design and implementation; l Many CASE workbenches support data dictionaries.

23. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 23 From chapter 8: Data dictionary entries

24. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 24 Advantages of OOD l Easier maintenance. Objects may be understood and modified as stand-alone entities. l Objects are potentially reusable components: They are independent encapsulations of state and operations. However, reuse is best implemented using collection of objects (COMPONENT) l For some systems, there may be an obvious mapping from real-world entities to system objects: Hardware component and their controlling objects.

25. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 25 Agile Methods and Design Activity l Object-oriented design can be an expensive task. l System development based on extensive up-front design can be criticised because the extensive analysis and design effort is not well suited to incremental development and delivery. l So-called agile methods have been developed to reduce or eliminate the Object-oriented design activity. l However, for large system and/or critical system, an extensive design is necessary.

26. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 26 Objects and object classes (1/2) l Objects are entities in a software system which represent “instances” of real-world and system entities. l Object classes are templates for objects. They may be used to create objects. l Object classes may inherit attributes and services from other object classes. More precisely ……..

27. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 27 Objects and object classes (2/2) An object is an entity that has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

28. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 28 The Unified Modeling Language l Several different notations for describing object-oriented designs were proposed in the 1980s and 1990s. l The Unified Modeling Language is an integration of these notations. l It describes notations for a number of different models that may be produced during OO analysis and design. l It is now a de facto standard for OO modelling. l The UML uses the term “operation” to mean the specification of an action; the term “method” is used to refer the implementation of an operation

29. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 29 Employee object class (UML)

30. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 30 Object communication (1/3) l Conceptually, objects communicate by message passing: i.e., objects communicate by requesting services (method calls) and by exchanging information required for service provision; l This style of communication involves: 1.The name of the service requested by the calling object; 2.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 calls Name  procedure name; Information  parameter list.

31. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 31 Object communication: message examples (2/3) // 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) ;

32. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 32 Object communication (3/3) l Service-based systems, object communication are implemented directly in XML text message that objects exchange. l The receiving object parse the text message, identifies the service and the associated data, and carries out the requested service. l However, when the object coexist in the same program, method call are implemented as procedure call or function call. l Synchronous  VS  Asynchronous

33. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 33 Generalisation and inheritance l Objects are instances of classes that 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 Generalisation in the UML is implemented as inheritance in OO programming languages.

34. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 34 A generalisation hierarchy

35. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 35 Advantages of inheritance l It is an abstraction mechanism which may be used to classify entities. l It is a reuse mechanism at both the design and the programming level. l The inheritance graph is a source of organisational knowledge about domains and systems.

36. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 36 Problems with inheritance l Object classes are not self-contained. They cannot be understood without reference to their super- classes. l Designers have a tendency to reuse the inheritance graph created during analysis: can lead to significant inefficiency. l The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained.

37. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 37 UML associations l Objects and object classes participate in relationships with other objects and object classes. l In the UML, a generalised relationship is indicated by an association. l Associations may be annotated with information that describes the association. l Associations are general. They may indicate that an attribute of an object is an associated object or that a method relies on an associated object.

38. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 38 An association model

39. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 39 Concurrent objects l The nature of objects as self-contained entities make them suitable for concurrent implementation. l The general message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system. l Generally, most oriented programming languages implements, as default, request for object services as function calls (serial execution model) … l …. but, for example Java, includes the built-in Thread class that let us create objects that execute concurrently.

40. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 40 Servers and active objects There are two kind of concurrent object implementation: l Servers The object is implemented as a parallel process (server) with entry points corresponding to object operations. If no calls are made to it, the object suspends itself and waits for further requests for service. l Active objects Objects are implemented as parallel processes and the internal object state may be changed by the object itself and not simply by external calls.

41. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 41 Servers objects l Server objects are most useful in distributed environment where the calling and the called object may execute on different machine. l The response time is unpredictable; l The system should be designed in such a way that the objects do not make assumption about the execution time. l Servers objects may also be used in a single machine where several objects request the service for printing a document.

42. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 42 Active objects (1/2) l Active objects are especially used in real-time system where objects are associated to hardware devices that collect information about the system environment. l The object’s methods allow other objects in the system access to the state information l So …..

43. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 43 Active transponder object l Active objects may have their attributes modified by operations but may also update them autonomously using internal operations. l A Transponder object broadcasts an aircraft’s position. The position may be updated using a satellite positioning system. The object periodically update the position by triangulation from satellites.

44. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 44 An active transponder object class Transponder extends Thread { Position currentPosition ; Coords c1, c2 ; Satellite sat1, sat2 ; Navigator theNavigator ; public Position givePosition () { return currentPosition ; } public void run () { while (true) { c1 = sat1.position () ; c2 = sat2.position () ; currentPosition = theNavigator.compute (c1, c2) ; } } //Transponder

45. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 45 Java threads l Threads in Java are a simple construct for implementing concurrent objects. l Threads must include a method called run() and this is started up by the Java run-time system. l Active objects typically include an infinite loop so that they are always carrying out the computation.

46. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 46 An object-oriented design process l Object-oriented Design processes involve developing a number of different system models. l They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. l However, for large systems ( often developed by different groups ) design models are an essential communication mechanism.

47. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 47 Process stages l Highlights key activities without being tied to any proprietary process such as the RUP. Understand and define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces. l It is not illustrated as a simple process diagram because all the above activities are interleaved an so influence each other: For example, objects are identified and the interface fully o partially specified as the architecture of the system is defined; This can lead to refinements.

48. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 48 Weather system description A weather mapping system is required to generate weather maps on a regular basis using data collected from remote, unattended weather stations and other data sources such as weather observers, balloons and satellites. Weather stations transmit their data to the area computer in response to a request from that machine. The area computer system validates the collected data and integrates it with the data from different sources. The integrated data is archived and, using data from this archive and a digitised map database a set of local weather maps is created. Maps may be printed for distribution on a special-purpose map printer or may be displayed in a number of different formats.

49. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 49 Stages of processing l It is simple to identify the following stages of processing: 1.Data collection; 2.Data integration; 3.Data archiving; 4.Map generation; ….. A layered architecture is adeguate: each stage relies only on the previous stage;

50. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 50 1) System context and models of use l The first stage in any software design process is to develop an understanding of the: Relationships between the software being designed and its external environment (the system context); The system use. l Model of system context A static model that describes other systems in the environment: 1.use a subsystem model to show other systems. Following slide shows the systems around the weather station system. l Model of system use A dynamic model that describes how the system interacts with its environment: 1.use use-cases diagrams to show possible interactions; 2.single use-case natural language description to identify objects, operation, exchanged information and to understand how interaction is initialized and so on.

51. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 51 Layered architecture An approach is: 1.Represent the system context by association and block diagram; 2.Develop this by deriving the sub- system model (on the left) by using UML packages.

52. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 52 Subsystems in the weather mapping system The context of the weather station is within a sub-system data collection

53. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 53 Use-case diagrams l Use-case diagrams are used to represent each interaction with the system. l A use-case model shows: the system features as ellipses; the interacting entity as a stick figure. l In the weather station system the interacting entity are not human but is the data-processing system for the weather data.

54. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 54 Use-cases diagram for the weather station Data-processing system

55. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 55 Use-case description Identification of objects and operations.

56. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 56 From the above use-cases The uses-cases helps to identify objects and operation in the system; l From the above use-cases (from the DESCRIPTION of Report use-case) it is obvious identify: 1.The object representing the instruments that collects weather data; 2.The object representing the summary (the encapsulation) of the weather data. 3.The operations request and send.

57. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 57 2) Architectural design l Once interactions between the system and its environment have been understood and identified, you use this information for designing the system architecture. l From the above information and from general knowledge …. a layered architecture (as discussed in Chapter 11) is appropriate for the weather station Interface layer for handling communications; Data collection layer for managing instruments and collecting their data; Instruments layer for encapsulating instruments. l There should normally be no more than 7 entities in an architectural model.

58. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 58 Weather station architecture

59. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 59 3) 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.

60. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 60 Approaches to identification (1/2) l Use a grammatical approach based on a natural language description of the system: Objects and attributes are nouns; Operations or services are verbs; l Base the identification on: Tangible things on the application domain  aircraft: Roles  managers; Events  request, notification; Locations  offices, remote; Interaction  meetings; …. etc.

61. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 61 Approaches to identification (2/2) l Use a behavioural approach to firstly understand the overall behaviour of the system; l Refine the overall behaviour in various system behaviours and identify objects based on who participates in what behaviour: Participants who play significant roles are recognised as objects. l Use a scenario-based analysis: the objects, attributes and methods in each scenario are identified. …. nevertheless objects identification remains very difficult ….

62. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 62 Weather station description A weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected periodically. When a command is issued to transmit the weather data, the weather station processes and summarises the collected data. The summarised data is transmitted to the mapping computer when a request is received.

63. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 63 Weather station object classes 1. Weather station The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model. 2. Weather data Encapsulates the summarised data from the instruments. 3. Ground thermometer, Anemometer, Barometer Application domain objects that are ‘hardware’ objects related to the instruments in the system. l 1) and 2) have been identified from the system description and the scenario (use-case) description; l 3) have been identified from the application domain.

64. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 64 Weather station object classes

65. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 65 Further objects and object refinement l Use application domain knowledge to identify more objects and operations Weather stations are remotely situated so instrument failures have to be reported automatically: Therefore, attributes and operations for self-checking are required. Since there are several weather stations, they should have a unique identifier; l Active or passive objects? In this case, objects are passive and collect data on request rather than autonomously. This introduces flexibility at the expense of controller (Comms) processing time.

66. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 66 4) Develop Design models l Design models show the objects and object classes and relationships between these entities. l Design models are the output of the OODesign activity: They are the bridge between requirements and implementation; They have to be abstract so that the relationships between them and the requirements is not hidden but … They have to be enough detailed in order to help programmers to make decision related to the implementation. l If the requirements engineers, the designers and the programmes are “closely linked”, an high-level abstract model is required … otherwise … a detailed model may be required.

67. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 67 4) Develop Design models An important step is to decide which model you need depending on the type of system that is being developed: This is also done, by tacking into account that minimising the number of models reduce costs and time. There are two type of design model that should be produced: 1.Static models describe the static structure of the system in terms of object classes and relationships. 2.Dynamic models describe the dynamic interactions between objects (not the object classes).

68. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 68 Examples of design models There are a lot different static and dynamic model in UML. For our example, we will see: 1.Sub-system models that show logical groupings of objects into coherent subsystems (static: a form of package/class diagrams). 2.Sequence models that show the sequence of object interactions (dynamic: sequence diagrams). 3.State machine models that show how individual objects change their state in response to events (dynamic: state-charts diagrams). Other models include use-case models, aggregation models, generalisation models, etc.

69. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 69 1) Subsystem models A package model + an object class model should describe the logical grouping in the system: the design is organised into logically related groups of objects. l In the UML, these are shown using packages - an encapsulation construct: this is a logical model; the actual organisation of objects in the system may be different but this encapsulation construct may be reflected in constructs such as library (Java, C++)

70. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 70 Weather station subsystems

71. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 71 2) Sequence models l Sequence models show the sequence of object interactions that take place Objects are arranged horizontally across the top; Time is represented vertically so models are read top to bottom; Interactions are represented by labelled arrows, Different styles of arrow represent different types of interaction; A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system.

72. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 72 Data collection sequence

73. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 73 Sequence models l You should produce a sequence diagram for each significant interaction. l If you have developed use-cases model then there should be sequence diagrams for each use- case.

74. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 74 3) State-charts l Show how objects respond to different service requests and the state transitions triggered by these requests If object state is Shutdown then it responds to a Startup() message; In the waiting state the object is waiting for further messages; If reportWeather () then system moves to summarising state; If calibrate () the system moves to a calibrating state; A collecting state is entered when a clock signal is received.

75. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 75 Weather station state diagram

76. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 76 5) 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 including details designing the interface but should hide this in the object itself. l Objects may have several interfaces which are viewpoints on the methods provided. l The UML uses class diagrams for interface specification but Java may also be used.

77. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 77 Weather station interface

78. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 78 Design evolution l Hiding information inside objects means that changes made to an object do not affect other objects in an unpredictable way. l Objects are loosely coupled so it is simple to introduce new objects without significant effects. l Assume pollution monitoring facilities are to be added to weather stations. These sample the air and compute the amount of different pollutants in the atmosphere. l Pollution readings are transmitted with weather data.

79. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 79 Changes required l Add an object class called Air quality as part of WeatherStation. l Add an operation reportAirQuality to WeatherStation. Modify the control software to collect pollution readings. l Add objects representing pollution monitoring instruments.

80. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 80 Pollution monitoring

81. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 81 l OOD is an approach to design so that design components have their own private state and operations. l Objects should have constructor and inspection operations. They 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. Key points

82. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 82 Key points l A range of different models may be produced during an object-oriented design process. These include static and dynamic system models. l Object interfaces should be defined precisely using e.g. a programming language like Java. l Object-oriented design potentially simplifies system evolution.