An Object-oriented Design Process Process Stages

An object-oriented design processzzzStructured design processes involvedeveloping a number of different systemmodels.They require a lot of effort for developmentand maintenance of these models and, forsmall systems, this may not be costeffective.However, for large systems developed bydifferent groups design models are anessential communication mechanism. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 1Weather system descriptionProcess stageszHighlights key activities without being tied toany proprietary process such as the RUP. Ian Sommerville 2004zSlide 3Layered architecture Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 2zDevelop an understanding of the relationshipsbetween the software being designed and itsexternal environmentSystem context The area computer system validates the collected data and integrates it withthe data from different sources. The integrated data is archived and, usingdata from this archive and a digitised map database a set of local weathermaps is created. Maps may be printed for distribution on a special-purposemap printer or may be displayed in a number of different formats.Software Engineering, 7th edition. Chapter 14Software Engineering, 7th edition. Chapter 14System context and models of useA weather mapping system is required to generate weather maps on aregular basis using data collected from remote, unattended weather stationsand other data sources such as weather observers, balloons and satellites.Weather stations transmit their data to the area computer in response to arequest from that machine. Ian Sommerville 2004Define the context and modes of use of thesystem;Design the system architecture;Identify the principal system objects;Develop design models;Specify object interfaces.zA static model that describes other systems in theenvironment. Use a subsystem model to show othersystems. Following slide shows the systems around theweather station system.Model of system use A dynamic model that describes how the system interactswith its environment. Use use-cases to show interactions Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 4Subsystems in the weather mapping systemSlide 5 Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 6

Use-case modelsUse-cases for the weather stationUse-case models are used to represent eachinteraction with the system.A use-case model shows the systemfeatures as ellipses and the interacting entityas a stick figure.zz Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 7 Ian Sommerville 2004Use-case eCommentsSoftware Engineering, 7th edition. Chapter 14Slide 9zzOnce interactions between the system and itsenvironment have been understood, you use thisinformation for designing the system architecture.A layered architecture as discussed in Chapter 11 isappropriate for the weather station zInterface layer for handling communications;Data collection layer for managing instruments;Instruments layer for collecting data.There should normally be no more than 7 entities inan architectural model. Ian Sommerville 2004Weather station architecturezzSoftware Engineering, 7th edition. Chapter 14Software Engineering, 7th edition. Chapter 14Slide 10Object identificationz Ian Sommerville 2004Slide 8Architectural designWeather stationReportWeather data collection system, Weather stationThe weather station sends a summary of the weather data that has beencollected from the instruments in the collection period to the weather datacollection system. The data sent are the maximum minimum and averageground and air temperatures, the maximum, minimum and average airpressures, the maximum, minimum and average wind speeds, the totalrainfall and the wind direction as sampled at 5 minute intervals.The weather data collection system establishes a modem link with theweather station and requests transmission of the data.The summarised data is sent to the weather data collection systemWeather stations are usually asked to report once per hour but thisfrequency may differ from one station to the other and may be modified infuture. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 11Identifying objects (or object classes) is themost difficult part of object oriented design.There is no 'magic formula' for objectidentification. It relies on the skill, experienceand domain knowledge of system designers.Object identification is an iterative process.You are unlikely to get it right first time. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 12

Approaches to identificationzzzzWeather station object classesUse a grammatical approach based on a naturallanguage description of the system (used in HoodOOD method).Base the identification on tangible things in theapplication domain.Use a behavioural approach and identify objectsbased on what participates in what behaviour.Use a scenario-based analysis. The objects,attributes and methods in each scenario areidentified. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 13zGround thermometer, Anemometer, Barometer zWeather station zzzActive or passive objectsSoftware Engineering, 7th edition. Chapter 14In this case, objects are passive and collect data onrequest rather than autonomously. This introducesflexibility at the expense of controller processing time.Software Engineering, 7th edition. Chapter 14Slide 16Examples of design modelsDesign models show the objects and objectclasses and relationships between theseentities.Static models describe the static structure ofthe system in terms of object classes andrelationships.Dynamic models describe the dynamicinteractions between objects. Ian Sommerville 2004Weather stations should have a unique identifier;Weather stations are remotely situated so instrumentfailures have to be reported automatically. Thereforeattributes and operations for self-checking are required. Ian Sommerville 2004Design modelszSlide 14Use domain knowledge to identify more objects andoperations zSoftware Engineering, 7th edition. Chapter 14Further objects and object refinement Slide 15Encapsulates the summarised data from the instruments. Ian Sommerville 2004zSoftware Engineering, 7th edition. Chapter 14The basic interface of the weather station to itsenvironment. It therefore reflects the interactionsidentified in the use-case model.Weather data Weather station object classes Ian Sommerville 2004Application domain objects that are ‘hardware’ objectsrelated to the instruments in the system.Slide 17zzzzSub-system models that show logical groupings ofobjects into coherent subsystems.Sequence models that show the sequence of objectinteractions.State machine models that show how individualobjects change their state in response to events.Other models include use-case models, aggregationmodels, generalisation models, etc. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 18

Subsystem modelszzWeather station subsystemsShows how the design is organised intologically related groups of objects.In the UML, these are shown usingpackages - an encapsulation construct. Thisis a logical model. The actual organisation ofobjects in the system may be different. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 19Sequence modelszSoftware Engineering, 7th edition. Chapter 14Slide 20Data collection sequenceSequence models show the sequence ofobject interactions that take place Objects are arranged horizontally across thetop;Time is represented vertically so models areread top to bottom;Interactions are represented by labelled arrows,Different styles of arrow represent differenttypes of interaction;A thin rectangle in an object lifeline representsthe time when the object is the controlling objectin the system. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 21Statechartsz Ian Sommerville 2004 Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 22Weather station state diagramShow how objects respond to different servicerequests and the state transitions triggered by theserequests If object state is Shutdown then it responds to a Startup()message;In the waiting state the object is waiting for furthermessages;If reportWeather () then system moves to summarisingstate;If calibrate () the system moves to a calibrating state;A collecting state is entered when a clock signal isreceived. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 23 Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 24

Object interface specificationzzzzWeather station interfaceObject interfaces have to be specified so that theobjects and other components can be designed inparallel.Designers should avoid designing the interfacerepresentation but should hide this in the objectitself.Objects may have several interfaces which areviewpoints on the methods provided.The UML uses class diagrams for interfacespecification but Java may also be used.interface WeatherStation {public void WeatherStation () ;public void startup () ;public void startup (Instrument i) ;public void shutdown () ;public void shutdown (Instrument i) ;public void reportWeather ( ) ;public void test () ;public void test ( Instrument i ) ;public void calibrate ( Instrument i) ;public int getID () ;} //WeatherStation Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 25 Ian Sommerville 2004Design evolutionzzzSoftware Engineering, 7th edition. Chapter 14Slide 27Pollution monitoring Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 26Changes requiredHiding information inside objects means thatchanges made to an object do not affect otherobjects in an unpredictable way.Assume pollution monitoring facilities are to beadded to weather stations. These sample theair and compute the amount of differentpollutants in the atmosphere.Pollution readings are transmitted with weatherdata. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 29zzzAdd an object class called Air quality as partof WeatherStation.Add an operation reportAirQuality toWeatherStation. Modify the control softwareto collect pollution readings.Add objects representing pollution monitoringinstruments. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14Slide 28

Object identification z Identifying objects (or object classes) is the most difficult part of object oriented design. z There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. z Object identification is an iterative process. You are unlikely to get it right first time.