Object-oriented Design ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 1
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 the UML may be used to represent these models ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 2
Topics covered l l l Objects and object classes An object-oriented design process Design evolution ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 3
Object-oriented development (1/2) l l Object-oriented Analysis, Design and Programming are related but distinct stage: 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 the identified requirements: • l These model reflect the entities and operations associated with the problem to be solved (i. e. , express the system requirements). Problem objects are identified. There may be close relationships between some problem object and some solution object. 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 4
Object-oriented development (2/2) l l l Compatible notation should be used at each stage; Moving to the next stage involves refining the previous stage by adding detail and devising new classes to provide additional functionality; As information is concealed (information hiding), detailed design decision about the representation of data can be delayed until the system is implemented. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 5
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 …. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 6
Interacting objects ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 7
From chapter 8: Object models during requirements analysis l l Object models describe the system in terms of object classes and their associations. It is useful to combine data-flow models and semantic data models; 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. Various object models may be produced • • • l Inheritance models; Aggregation models; Interaction models. Developing object models during requirements analysis simplifies the transition to object-oriented design and programming. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 8
From chapter 8: Object models during requirements analysis l l Natural ways of reflecting the real-world entities manipulated by the system More abstract and high-level entities are more difficult to model using this approach Object class identification is recognised as a difficult process requiring a deep understanding of the application domain Object classes reflecting domain entities are reusable across systems ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 9
From chapter 8: Inheritance models during requirements analysis l l Organise the domain object classes into a hierarchy. Classes at the top of the hierarchy reflect the common features of all classes. Object classes inherit their attributes and services from one or more super-classes. These may then be specialised as necessary. Class hierarchy design can be a difficult process if duplication in different branches is to be avoided. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 10
From chapter 8: Object models and the UML l l l The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods. It has become an effective standard for objectoriented modelling. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 11
From chapter 8: Library class hierarchy ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 12
From chapter 8: User class hierarchy ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 13
From chapter 8: Multiple inheritance l l 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. This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics. Multiple inheritance makes class hierarchy reorganisation more complex. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 14
From chapter 8: Multiple inheritance ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 15
From chapter 8: Object aggregation l l An aggregation model shows how classes (that are collections) are an “aggregate” of a set of other classes. Aggregation models are similar to the part-of relationship in semantic data models. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 16
From chapter 8: Object aggregation ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 17
From chapter 8: Object behaviour modelling l l A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a usecase. Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 18
From chapter 8: Issue of electronic items ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 19
From chapter 8: Semantic data models l l l Used to describe the logical structure of data processed by the system. An entity-relation-attribute (ERA) model sets out the entities in the system, the relationships between these entities and the entity attributes Widely used in database design. • l Can readily be implemented using relational databases. No specific notation provided in the UML but objects and associations can be used. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 20
From chapter 8: Library semantic model ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 21
From chapter 8: Data dictionaries l 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. Advantages • • l Support name management and avoid duplication; Store of organisational knowledge linking analysis, design and implementation; Many CASE workbenches support data dictionaries. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 22
From chapter 8: Data dictionary entries ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 23
Advantages of OOD l l Easier maintenance. Objects may be understood and modified as stand-alone entities. Objects are potentially reusable components: • • l They are independent encapsulations of state and operations. However, reuse is best implemented using collection of objects (COMPONENT) For some systems, there may be an obvious mapping from real-world entities to system objects: • Hardware component and their controlling objects. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 24
Agile Methods and Design Activity l l Object-oriented design can be an expensive task. 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. So-called agile methods have been developed to reduce or eliminate the Object-oriented design activity. However, for large system and/or critical system, an extensive design is necessary. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 25
Objects and object classes (1/2) l l l Objects are entities in a software system which represent “instances” of real-world and system entities. Object classes are templates for objects. They may be used to create objects. Object classes may inherit attributes and services from other object classes. More precisely ……. . ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 26
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 27
The Unified Modeling Language l l l Several different notations for describing object-oriented designs were proposed in the 1980 s and 1990 s. The Unified Modeling Language is an integration of these notations. It describes notations for a number of different models that may be produced during OO analysis and design. It is now a de facto standard for OO modelling. 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 ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 28
Employee object class (UML) ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 29
Object communication (1/3) l Conceptually, objects communicate by message passing: • l This style of communication involves: 1. 2. l i. e. , objects communicate by requesting services (method calls) and by exchanging information required for service provision; 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. In practice, messages are “often” implemented by procedure calls • • Name procedure name; Information parameter list. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 30
Object communication: message examples (2/3) // Call a method associated with a buffer // object that returns the next value // in the buffer v = circular. Buffer. Get () ; // Call the method associated with a // thermostat object that sets the // temperature to be maintained thermostat. set. Temp (20) ; ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 31
Object communication (3/3) l l Service-based systems, object communication are implemented directly in XML text message that objects exchange. The receiving object parse the text message, identifies the service and the associated data, and carries out the requested service. However, when the object coexist in the same program, method call are implemented as procedure call or function call. Synchronous VS Asynchronous ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 32
Generalisation and inheritance l l Objects are instances of classes that define attribute types and operations. 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). A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own. Generalisation in the UML is implemented as inheritance in OO programming languages. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 33
A generalisation hierarchy ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 34
Advantages of inheritance l l l It is an abstraction mechanism which may be used to classify entities. It is a reuse mechanism at both the design and the programming level. The inheritance graph is a source of organisational knowledge about domains and systems. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 35
Problems with inheritance l l Object classes are not self-contained. They cannot be understood without reference to their superclasses. Designers have a tendency to reuse the inheritance graph created during analysis: • l can lead to significant inefficiency. The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 36
UML associations l l Objects and object classes participate in relationships with other objects and object classes. In the UML, a generalised relationship is indicated by an association. Associations may be annotated with information that describes the association. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 37
An association model ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 38
Concurrent objects l l The nature of objects as self-contained entities make them suitable for concurrent implementation. The general message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system. Generally, most oriented programming languages implements, as default, request for object services as function calls (serial execution model) … …. but, for example Java, includes the built-in Thread class that let us create objects that execute concurrently. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 39
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 40
Servers objects l l Server objects are most useful in distributed environment where the calling and the called object may execute on different machine. The response time is unpredictable; The system should be designed in such a way that the objects do not make assumption about the execution time. Servers objects may also be used in a single machine where several objects request the service for printing a document. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 41
Active objects (1/2) l l l Active objects are especially used in real-time system where objects are associated to hardware devices that collect information about the system environment. The object’s methods allow other objects in the system access to the state information So …. . ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 42
Active transponder object l l Active objects may have their attributes modified by operations but may also update them autonomously using internal operations. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 43
An active transponder object class Transponder extends Thread { Position current. Position ; Coords c 1, c 2 ; Satellite sat 1, sat 2 ; Navigator the. Navigator ; public Position give. Position () { return current. Position ; } public void run () { while (true) { c 1 = sat 1. position () ; c 2 = sat 2. position () ; current. Position = the. Navigator. compute (c 1, c 2) ; } } } //Transponder ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 44
Java threads l l l Threads in Java are a simple construct for implementing concurrent objects. Threads must include a method called run() and this is started up by the Java run-time system. Active objects typically include an infinite loop so that they are always carrying out the computation. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 45
An object-oriented design process l l l Object-oriented Design processes involve developing a number of different system models. They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. However, for large systems (often developed by different groups) design models are an essential communication mechanism. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 46
Process stages l Highlights key activities without being tied to any proprietary process such as the RUP. • • • l Understand 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 47
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 48
Stages of processing l It is simple to identify the following stages of processing: 1. 2. 3. 4. Data collection; Data integration; Data archiving; Map generation; …. . A layered architecture is adeguate: • each stage relies only on the previous stage; ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 49
1) System context and models of use l The first stage in any software design process is to develop an understanding of the: • • l Relationships between the software being designed and its external environment (the system context); The system use. 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-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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 50
Layered architecture An approach is: 1. Represent the system context by association and block diagram; 2. Develop this by deriving the subsystem model (on the left) by using UML packages. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 51
Subsystems in the weather mapping system The context of the weather station is within a sub-system data collection ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 52
Use-case diagrams l l Use-case diagrams are used to represent each interaction with the system. A use-case model shows: • • l the system features as ellipses; the interacting entity as a stick figure. In the weather station system the interacting entity are not human but is the data-processing system for the weather data. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 53
Use-cases diagram for the weather station Data-processing system ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 54
Use-case description Identification of objects and operations. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 55
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 56
2) Architectural design l l Once interactions between the system and its environment have been understood and identified, you use this information for designing the system architecture. From the above information and from general knowledge …. a layered architecture (as discussed in Chapter 11) is appropriate for the weather station • • • l Interface layer for handling communications; Data collection layer for managing instruments and collecting their data; Instruments layer for encapsulating instruments. There should normally be no more than 7 entities in an architectural model. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 57
Weather station architecture ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 58
3) Object identification l l l Identifying objects (or object classes) is the most difficult part of object oriented design. There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative process. You are unlikely to get it right first time. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 59
Approaches to identification (1/2) l Use a grammatical approach based on a natural language description of the system: • • l Objects and attributes are nouns; Operations or services are verbs; Base the identification on: • • • Tangible things on the application domain aircraft: Roles managers; Events request, notification; Locations offices, remote; Interaction meetings; …. etc. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 60
Approaches to identification (2/2) l l Use a behavioural approach to firstly understand the overall behaviour of the system; Refine the overall behaviour in various system behaviours and identify objects based on who participates in what behaviour: • l Participants who play significant roles are recognised as objects. Use a scenario-based analysis: • the objects, attributes and methods in each scenario are identified. …. nevertheless objects identification remains very difficult …. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 61
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 62
Weather station object classes 1. Weather station • 2. Weather data • 3. l Encapsulates the summarised data from the instruments. Ground thermometer, Anemometer, Barometer • l The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model. Application domain objects that are ‘hardware’ objects related to the instruments in the system. 1) and 2) have been identified from the system description and the scenario (use-case) description; 3) have been identified from the application domain. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 63
Weather station object classes ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 64
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. • l Since there are several weather stations, they should have a unique identifier; 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 65
4) Develop Design models l l Design models show the objects and object classes and relationships between these entities. Design models are the output of the OODesign activity: • • • l 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. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 66
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). ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 67
Examples of design models There 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 individual objects change their state in response to events (dynamic: state-charts diagrams). Other models include use-case models, aggregation models, generalisation models, etc. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 68
1) Subsystem models A package model + an object class model should describe the logical grouping in the system: • l the design is organised into logically related groups of objects. 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++) ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 69
Weather station subsystems ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 70
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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 71
Data collection sequence ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 72
Sequence models l l You should produce a sequence diagram for each significant interaction. If you have developed use-cases model then there should be sequence diagrams for each usecase. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 73
3) State-charts l Show 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 report. Weather () 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 74
Weather station state diagram ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 75
5) Object interface specification l l Object interfaces have to be specified so that the objects and other components can be designed in parallel. Designers should avoid including details designing the interface but should hide this in the object itself. Objects may have several interfaces which are viewpoints on the methods provided. The UML uses class diagrams for interface specification but Java may also be used. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 76
Weather station interface ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 77
Design evolution l l Hiding information inside objects means that changes made to an object do not affect other objects in an unpredictable way. Objects are loosely coupled so it is simple to introduce new objects without significant effects. 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. Pollution readings are transmitted with weather data. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 78
Changes required l l l Add an object class called Air quality as part of Weather. Station. Add an operation report. Air. Quality to Weather. Station. Modify the control software to collect pollution readings. Add objects representing pollution monitoring instruments. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 79
Pollution monitoring ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 80
Key points l l OOD is an approach to design so that design components have their own private state and operations. Objects should have constructor and inspection operations. They provide services to other objects. Objects may be implemented sequentially or concurrently. The Unified Modeling Language provides different notations for defining different object models. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 81
Key points l l l A range of different models may be produced during an object-oriented design process. These include static and dynamic system models. Object interfaces should be defined precisely using e. g. a programming language like Java. Object-oriented design potentially simplifies system evolution. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 14 Slide 82
Скачать презентацию Object-oriented Design Ian Sommerville 2004 Software Engineering 7
080e1bc0a9b61bfd91020588ce76f240.ppt