Chapter 14: Object-Oriented Design

1. Object-oriented design based on abstractions of real-world or system entities objects manage a private state communication by message passing advantages obvious map to real-world easier to debug due to reduced system coupling easier reuse easier maintenance (objects are stand-alone entities) Functional design based on interacting functional components of a solution functions share a global state communication via shared variables advantages functional data flow may be more intuitive more obvious control model Chapter 14: Object-Oriented Design

2. Object-oriented development • Three related but distinct OO stages • analysis (OOA) : develop an object model of the application domain • design (OOD): develop an object-oriented system model to implement requirements • programming (OOP) : realize an OOD using an OO language such as C++ • Commonalities: • identifying objects, attributes and services • organizing objects into an aggregation hierarchy • constructing object-use descriptions to show how services are used • specifying object interfaces

3. Passive and active objects • Passive objects • all state changes effected through operations defined in the object interface • e.g. aStack.Push(item) • Active objects • can change their own state • e.g. an object might have a (private) timer to update its state every 100 ms (similar to JavaScript setTimeout)

4. 14.2 Object identification • The most difficult part of object oriented design • No 'magic formula' for object identification • Relies on skill, experience, and domain knowledge • Iterative--you are unlikely to get it right first time • How is this like anything else you do well? • Approaches • grammatical based on a description of the system: nouns are objects, adjectives are attributes, verbs are operations • identify tangible things in the application domain • behavioral, identifying objects based on what participates in what behavior • scenario analysis

5. An office information system The Office Information Retrieval System (OIRS) is an automatic file clerk which can file documents under some name in one or more indexes, retrieve documents, display and maintain document indexes, archive documents and destroy documents. The system is activated by a request from the user and always returns a message to the user indicating the success or failure of the request.

6. Retrie v al Document Inde x User system Name Name Name Name File Displa y Retr ie v e Delete entr y Put message Archiv e Add entr y Destro y An office information system The Office Information Retrieval System (OIRS) is an automatic file clerk which can filedocumentsunder some name in one or more indexes,retrievedocuments,display and maintaindocument indexes, archive documents and destroydocuments. The system is activated by a request from the user and always returns a message to the user indicating the success or failure of the request. User command Get command

7. Weather mapping system 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. Will look at this two ways 1. non-layered 2. layered

8. Data display layer where objects are concerned with preparing and «subsystem» presenting the data in a human- Data display readable form Data archiving layer where objects «subsystem» are concerned with storing the data Data archiving for future processing Data processing layer where objects «subsystem» are concerned with checking and Data processing integ rating the collected data Data collection layer where objects «subsystem» are concerned with acquiring data Data collection from remote sources Top-level architecturesNon-layered Layered

9. Subsystems derived from layered view

10. Comment on notation • The design is organized into logically related groups of objects • In the UML, these are encapsulated using packages • This is a logical model • The actual organization of objects in the system may be different Next step: decompose weather station subsystem

11. W eather station Identifier W eather data Instr ument status Initializ e T r ansmit data T r ansmit status Self test Shut do wn Weather station objects • Use domain knowledge to identify more objects and operations • weather stations should have a unique identifier • weather stations are remotely situated so instrument failures have to be reported automatically, therefore attributes and operations for self-checking are required • 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 processing time • What are the objects inside this?

12. Air thermometer T emper ature T est Calibr ate W ind v ane Rain gaug e Bar ometer Direction Rainf all Pressure Height T est Reset T est T est Calibr ate Hardware control objects Gr ound Anemometer thermometer T emper ature Wind speed T est T est Calibr ate

13. W eather data T emperature data Pressure Air temper ature data Readings Readings Ground temper ature data Maxim um Read Wind speed data Minim um A v er age Wind direction data A v er age Pressure Read Rainf all Mak e readings Process data W ind speed data Readings A v er age Max. gust Read Weather data objects W ind direction Rainfall data Readings Cum ulativ e Read Read

14. Weather station subsystems (layered)

15. i n t e rf a c e We a t h e r S t a ti o n { p u b li c v o i d We at he r S ta t i o n ( ) ; p u b li c v o i d s ta r t u p () ; p u b li c v o i d s ta r t u p (I n st r u me n t i) ; p u b li c v o i d s h u t d o w n () ; p u b li c v o i d s h u t d o w n (I n s t r u m en t i ) ; p u b li c v o i d r ep or tW e a t h e r ( ) ; p u b li c v o i d t e s t () ; p u b li c v o i d t e s t ( In s t r u me nt i ) ; p u b li c v o i d c al i b r at e ( I n st r u me n t i) ; p u b li c i n t g e t I D ( ) ; } // We a t h e r S t a ti o n Object interface design • Specify the detail of the object interfaces so that objects can be developed in parallel • This means defining • attribute types • the signatures and semantics of object operations • Use a programming language to achieve precision • Avoid representation information

16. Design evolution • How would you add pollution monitoring facilities to the weather stations? • (to sample the air and compute the amounts of different pollutants) • (pollution readings are transmitted with weather data) • Changes required: • add an object class called AirQuality as part of WeatherStation. • add an operation reportAirQuality to WeatherStation. Modify the control software to collect pollution readings. • add objects representing pollution monitoring instruments. W eatherStation P ollution monitoring instruments Air quality identifier NOData NOmeter SmokeMeter repor tW eather () smok eData repor tAirQuality () benz eneData calibrate (instruments) test () collect () BenzeneMeter star tup (instruments) summarise () shutdown (instruments)

17. Weather station subsystems (layered) «subsystem» «subsystem» Inter face Data collection CommsController W eatherData Instrument Status W eatherStation «subsystem» Instruments Air RainGauge Anemometer thermometer Ground Barometer W indV ane thermometer Smoke meter Benzine meter NO meter

18. Other pieces mentioned in text • State machines show responses • to requests for services • Sequence diagrams show • interactions among objects