Chapter 7 – Design And Implementation
Chapter 7 – Design and ImplementationSummaryChapter 7 Design and implementation1
Topics covered Object-oriented design using the UMLDesign patternsImplementation issuesOpen source developmentChapter 7 Design and implementation2
Design and implementation Software design and implementation is the stagein the software engineering process at which anexecutable software system is developed. Software design and implementation activitiesare invariably inter-leaved.– Software design is a creative activity in which youidentify software components and their relationships,based on a customer’s requirements.– Implementation is the process of realizing the designas a program.Chapter 7 Design and implementation3
Build or buy In a wide range of domains, it is now possible tobuy off-the-shelf systems (COTS) that can beadapted and tailored to the users’ requirements.– For example, if you want to implement a medicalrecords system, you can buy a package that is alreadyused in hospitals. It can be cheaper and faster to usethis approach rather than developing a system in aconventional programming language. When you develop an application in this way, thedesign process becomes concerned with how touse the configuration features of that system todeliver the system requirements.Chapter 7 Design and implementation4
An object-oriented design process Structured object-oriented design processesinvolve developing a number of differentsystem models. They require a lot of effort for developmentand maintenance of these models and, forsmall systems, this may not be cost-effective. However, for large systems developed bydifferent groups design models are animportant communication mechanism.Chapter 7 Design and implementation5
Process stages There are a variety of different object-orienteddesign processes that depend on the organizationusing the process. Common activities in these processes include:–––––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. Process illustrated here using a design for awilderness weather station.Chapter 7 Design and implementation6
System context and interactions Understanding the relationships between the softwarethat is being designed and its external environment isessential for deciding how to provide the requiredsystem functionality and how to structure the systemto communicate with its environment. Understanding of the context also lets you establishthe boundaries of the system. Setting the systemboundaries helps you decide what features areimplemented in the system being designed and whatfeatures are in other associated systems.Chapter 7 Design and implementation7
Context and interaction models A system context model is a structural modelthat demonstrates the other systems in theenvironment of the system being developed. An interaction model is a dynamic model thatshows how the system interacts with itsenvironment as it is used.Chapter 7 Design and implementation8
System context for the weather stationChapter 7 Design and implementation9
Weather station use casesChapter 7 Design and implementation10
Use case description—Report weatherSystemWeather stationUse caseReport weatherActorsWeather information system, Weather stationDescriptionThe weather station sends a summary of the weather data that has beencollected from the instruments in the collection period to the weatherinformation 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 five-minute intervals.StimulusThe weather information system establishes a satellite communication linkwith the weather station and requests transmission of the data.ResponseThe summarized data is sent to the weather information system.CommentsWeather stations are usually asked to report once per hour but this frequencymay differ from one station to another and may be modified in the future.Chapter 7 Design and implementation11
Architectural design Once interactions between the system and its environment havebeen understood, you use this information for designing the systemarchitecture. You identify the major components that make upthe system and their interactions, and then mayorganize the components using an architecturalpattern such as a layered or client-server model. The weather station is composed of independentsubsystems that communicate by broadcastingmessages on a common infrastructure.Chapter 7 Design and implementation12
High-level architecture of the weatherstationChapter 7 Design and implementation13
Architecture of data collection systemChapter 7 Design and implementation14
Object class identification Identifying object classes is too often adifficult 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.Chapter 7 Design and implementation15
Approaches to identification Use a grammatical approach based on a natural languagedescription of the system (used in Hood OOD method). Base the identification on tangible things in the applicationdomain. Use a behavioural approach and identify objects based onwhat participates in what behaviour. Use a scenario-based analysis. The objects, attributes andmethods in each scenario are identified.Chapter 7 Design and implementation16
Weather station descriptionA weather station is a package of software controlled instrumentswhich collects data, performs some data processing and transmitsthis data for further processing. The instruments include air andground thermometers, an anemometer, a wind vane, a barometerand a rain gauge. Data is collected periodically.When a command is issued to transmit the weather data, theweather station processes and summarises the collected data.The summarised data is transmitted to the mapping computerwhen a request is received.Chapter 7 Design and implementation17
Weather station object classes Object class identification in the weather station system maybe based onthe tangible hardware and data inthe system:– Ground thermometer, Anemometer, Barometer Application domain objects that are ‘hardware’ objects related to theinstruments in the system.– Weather station The basic interface of the weather station to its environment. It thereforereflects the interactions identified in the use-case model.– Weather data Encapsulates the summarized data from the instruments.Chapter 7 Design and implementation18
Weather station object classesChapter 7 Design and implementation19
Design models Design 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.Chapter 7 Design and implementation20
Examples of design models Subsystem models that show logical groupings of objects intocoherent subsystems. Sequence models that show the sequence of objectinteractions. State machine models that show how individual objectschange their state in response to events. Other models include use-case models, aggregation models,generalisation models, etc.Chapter 7 Design and implementation21
Subsystem models Shows how the design is organised intologically related groups of objects. In the UML, these are shown using packages an encapsulation construct. This is a logicalmodel. The actual organisation of objects inthe system may be different.Chapter 7 Design and implementation22
Sequence models Sequence models show the sequence ofobject interactions that take place– Objects are arranged horizontally across the top;– Time is represented vertically so models are readtop to bottom;– Interactions are represented by labelled arrows,Different styles of arrow represent different typesof interaction;– A thin rectangle in an object lifeline represents thetime when the object is the controlling object inthe system.Chapter 7 Design and implementation23
Sequence diagram describing datacollectionChapter 7 Design and implementation24
State diagrams State diagrams are used to show how objectsrespond to different service requests and the state transitionstriggered by these requests. State diagrams are useful high-level models ofa system or an object’s run-time behavior. You don’t usually need a state diagram for allof the objects in the system. Many of theobjects in a system are relatively simple and astate model adds unnecessary detail to thedesign.Chapter 7 Design and implementation25
Weather station state diagramChapter 7 Design and implementation26
Interface specification Object interfaces have to be specified so that the objects andother components can be designed in parallel. Designers should avoid designing the interface representationbut should hide this in the object itself. Objects may have several interfaces which are viewpoints onthe methods provided. The UML uses class diagrams for interface specification butJava may also be used.Chapter 7 Design and implementation27
Weather station interfacesChapter 7 Design and implementation28
Key points Software design and implementation are inter-leaved activities. The levelof detail in the design depends on the type of system and whether you areusing a plan-driven or agile approach. The process of object-oriented design includes activities to design thesystem architecture, identify objects in the system, describe the designusing different object models and document the component interfaces. A range of different models may be produced during an object-orienteddesign process. These include static models (class models, generalizationmodels, association models) and dynamic models (sequence models, statemachine models). Component interfaces must be defined precisely so that other objects canuse them. A UML interface stereotype may be used to define interfaces.Chapter 7 Design and implementation29
Design patterns A design pattern is a way of reusing abstractknowledge about a problem and its solution. A pattern is a description of the problem andthe essence of its solution. It should be sufficiently abstract to be reusedin different settings. Pattern descriptions usually make use ofobject-oriented characteristics such asinheritance and polymorphism.Chapter 7 Design and implementation30
Pattern elements Name– A meaningful pattern identifier. Problem description. Solution description.– Not a concrete design but a template for a designsolution that can be instantiated in different ways. Consequences– The results and trade-offs of applying the pattern.Chapter 7 Design and implementation31
The Observer pattern Name– Observer. Description– Separates the display of object state from the object itself. Problem description– Used when multiple displays of state are needed. Solution description– See slide with UML description. Consequences– Optimisations to enhance display performance are impractical.Chapter 7 Design and implementation32
The Observer pattern (1)PatternnameObserverDescriptionSeparates the display of the state of an object from the object itself andallows alternative displays to be provided. When the object statechanges, all displays are automatically notified and updated to reflect thechange.ProblemdescriptionIn many situations, you have to provide multiple displays of stateinformation, such as a graphical display and a tabular display. Not all ofthese may be known when the information is specified. All alternativepresentations should support interaction and, when the state is changed,all displays must be updated.This pattern may be used in all situations where more than onedisplay format for state information is required and where it is notnecessary for the object that maintains the state information to knowabout the specific display formats used.Chapter 7 Design and implementation33
The Observer pattern (2)Pattern nameObserverSolutiondescriptionThis involves two abstract objects, Subject and Observer, and two concreteobjects, ConcreteSubject and ConcreteObject, which inherit the attributes of therelated abstract objects. The abstract objects include general operations that areapplicable in all situations. The state to be displayed is maintained inConcreteSubject, which inherits operations from Subject allowing it to add andremove Observers (each observer corresponds to a display) and to issue anotification when the state has changed.The ConcreteObserver maintains a copy of the state of ConcreteSubject andimplements the Update() interface of Observer that allows these copies to be keptin step. The ConcreteObserver automatically displays the state and reflectschanges whenever the state is updated.ConsequencesThe subject only knows the abstract Observer and does not know details of theconcrete class. Therefore there is minimal coupling between these objects.Because of this lack of knowledge, optimizations that enhance displayperformance are impractical. Changes to the subject may cause a set of linkedupdates to observers to be generated, some of which may not be necessary.Chapter 7 Design and implementation34
Multiple displays using the ObserverpatternChapter 7 Design and implementation35
A UML model of the Observer patternChapter 7 Design and implementation36
Design problems To use patterns in your design, you need to recognizethat any design problem you are facing may have anassociated pattern that can be applied.– Tell several objects that the state of some other object haschanged (Observer pattern).– Tidy up the interfaces to a number of related objects thathave often been developed incrementally (Façadepattern).– Provide a standard way of accessing the elements in acollection, irrespective of how that collection isimplemented (Iterator pattern).– Allow for the possibility of extending the functionality ofan existing class at run-time (Decorator pattern).Chapter 7 Design and implementation37
Implementation issues Focus here is not on programming, although this isobviously important, but on other implementation issuesthat are often not covered in programming texts:– Reuse Most modern software is constructed by reusing existingcomponents or systems. When you are developing software,you should make as much use as possible of existing code.– Configuration management During the development process,you have to keep track of the many different versions of eachsoftware component in a configuration management system.– Host-target development Production software does not usuallyexecute on the same computer as the software developmentenvironment. Rather, you develop it on one computer (the hostsystem) and execute it on a separate computer (the targetsystem).Chapter 7 Design and implementation38
Reuse From the 1960s to the 1990s, most new software wasdeveloped from scratch, by writing all code in a highlevel programming language.– The only significant reuse or software was the reuse offunctions and objects in programming language libraries. Costs and schedule pressure mean that this approachbecame increasingly unviable, especially forcommercial and Internet-based systems. An approach to development based around the reuseof existing software emerged and is now generally usedfor business and scientific software.Chapter 7 Design and implementation39
Reuse levels The abstraction level– At this level, you don’t reuse software directly but useknowledge of successful abstractions in the design of yoursoftware. The object level– At this level, you directly reuse objects from a libraryrather than writing the code yourself. The component level– Components are collections of objects and object classesthat you reuse in application systems. The system level– At this level, you reuse entire application systems.Chapter 7 Design and implementation40
Reuse costs The costs of the time spent in looking for software to reuseand assessing whether or not it meets your needs. Where applicable, the costs of buying the reusablesoftware. For large off-the-shelf systems, these costs can bevery high. The costs of adapting and configuring the reusablesoftware components or systems to reflect therequirements of the system that you are developing. The costs of integrating reusable software elements witheach other (if you are using software from differentsources) and with the new code that you have developed.Chapter 7 Design and implementation41
Configuration management Configuration management is the name given tothe general process of managing a changingsoftware system. The aim of configuration management is tosupport the system integration process so that alldevelopers can access the project code anddocuments in a controlled way, find out whatchanges have been made, and compile and linkcomponents to create a system. See also Chapter 25.Chapter 7 Design and implementation42
Configuration management activities Version management, where support is provided to keep track ofthe different versions of software components. Versionmanagement systems include facilities to coordinate developmentby several programmers. System integration, where support is provided to help developersdefine what versions of components are used to create eachversion of a system. This description is then used to build a systemautomatically by compiling and linking the required components. Problem tracking, where support is provided to allow users toreport bugs and other problems, and to allow all developers to seewho is working on these problems and when they are fixed.Chapter 7 Design and implementation43
Host-target development Most software is developed on one computer (thehost), but runs on a separate machine (the target). More generally, we can talk about a developmentplatform and an execution platform.– A platform is more than just hardware.– It includes the installed operating system plus othersupporting software such as a database managementsystem or, for development platforms, an interactivedevelopment environment. Development platform usually has different installedsoftware than execution platform; these platforms mayhave different architectures.Chapter 7 Design and implementation44
Development platform tools An integrated compiler and syntax-directedediting system that allows you to create, edit andcompile code. A language debugging system. Graphical editing tools, such as tools to edit UMLmodels. Testing tools, such as Junit that can automaticallyrun a set of tests on a new version of a program. Project support tools that help you organize thecode for different development projects.Chapter 7 Design and implementation45
Integrated development environments(IDEs) Software development tools are often grouped tocreate an integrated development environment (IDE). An IDE is a set of software tools that supports differentaspects of software development, within somecommon framework and user interface. IDEs are created to support development in a specificprogramming language such as Java. The language IDEmay be developed specially, or may be an instantiationof a general-purpose IDE, with specific languagesupport tools.Chapter 7 Design and implementation46
Component/system deploymentfactors If a component is designed for a specific hardware architecture, or relieson some other software system, it must obviously be deployed on aplatform that provides the required hardware and software support. High availability systems may require components to be deployed on morethan one platfo
using different object models and document the component interfaces. A range of different models may be produced during an object-oriented design process. These include static models (class models, generalization models, association models) and dynamic models (sequence models, state machine models).
Part One: Heir of Ash Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25 Chapter 26 Chapter 27 Chapter 28 Chapter 29 Chapter 30 .
TO KILL A MOCKINGBIRD. Contents Dedication Epigraph Part One Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Part Two Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18. Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25 Chapter 26
DEDICATION PART ONE Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 PART TWO Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 .
About the husband’s secret. Dedication Epigraph Pandora Monday Chapter One Chapter Two Chapter Three Chapter Four Chapter Five Tuesday Chapter Six Chapter Seven. Chapter Eight Chapter Nine Chapter Ten Chapter Eleven Chapter Twelve Chapter Thirteen Chapter Fourteen Chapter Fifteen Chapter Sixteen Chapter Seventeen Chapter Eighteen
18.4 35 18.5 35 I Solutions to Applying the Concepts Questions II Answers to End-of-chapter Conceptual Questions Chapter 1 37 Chapter 2 38 Chapter 3 39 Chapter 4 40 Chapter 5 43 Chapter 6 45 Chapter 7 46 Chapter 8 47 Chapter 9 50 Chapter 10 52 Chapter 11 55 Chapter 12 56 Chapter 13 57 Chapter 14 61 Chapter 15 62 Chapter 16 63 Chapter 17 65 .
HUNTER. Special thanks to Kate Cary. Contents Cover Title Page Prologue Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter
Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 . Within was a room as familiar to her as her home back in Oparium. A large desk was situated i
The Hunger Games Book 2 Suzanne Collins Table of Contents PART 1 – THE SPARK Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8. Chapter 9 PART 2 – THE QUELL Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapt
