Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently formal (does not provide info on what stimuli to send etc., to provide seamless transition) –system must be adapted to implementation environment (fig 8.1) –to validate analysis result. Proceed to coding only if the results are appropriate for construction do not optimize at this stage. (simulate critical elements or prototype for optimizing, if necessary)

Activities in construction phase Fig. 8.2 Identify implementation environment Incorporate the results and develop a first approach to a design model Describe how objects interact in each specific use case (all stimuli, and what each operation will do to an object)

Design model - traceability The design model gives a detailed description of all objects including operations and attributes. We define the interfaces of the objects and also the semantics of the operations. Design model is composed of blocks which are design objects. These blocks will later be implemented by the source code. Initially each analysis object becomes a block (hence traceability) Each block should be cohesive Fig 8.3 Fig 8.4 Blocks help in identifying construction errors in early stage

Design model - implementation environment Keep few encapsulated objects that are aware of the constraints of the implementation environment (fig 8.5) This can be done through –abstract class that specifies the interface, which is implemented in environment specific descendants that are instantiated as required by the chosen platform –the object can check which platform it is running on and execute the correct statement –link different.c files for different environments, with the interface defined in the header file (conditional compile) implementation factors that may affect design –programming language (error handling, memory management such as automatic garbage collection) –components library –existing products –requirements for performance or limitation of memory –people and organization - division of work based on core competency

Common changes to design due to environmental considerations –introduce design blocks in the design model which do not exist in the analysis model –delete blocks –split or join existing blocks –change associations between blocks in the design model (fig 8.6) Fig stimulus sent up the inheritance hierarchy - call through Think about components at this stage.... Use it where there is a [0...N] acquaintance association (Fig 8.8) Before we implement blocks, we must describe in detail how they are to communicate with one another

Design model - Interaction diagrams describes communication between blocks create one diagram for each concrete use case it shows how objects/blocks behave in each use case (Fig 8.9) Fig 8.10 shows the operation in the interaction diagram

Design model - Stimuli Interaction diagrams are controlled by events (stimuli sent from one object to another and initiate an operation) pg 219, Fig 8.11 While defining stimuli, keep the following in mind –reusability increases if we have fewer parameters in a stimuli –stimuli that invoke similar behavior should have same name –naming of stimuli should reflect the distribution of responsibilities between blocks –it should clearly show exchange of info., name should be selected carefully to reflect this –handling the creation of new instances or initiation of new processes are performed in the same manner as ordinary stimulus handling intra-process communication (message) vs. Inter-process communication (signal)(fig. 8.12)

Design model - Structure of interaction diagrams centralized (fig 8.13) decentralized (fig 8.14) Fig (8.15) Which is better –centralized (fork) is better when »the operations can change order »new operations could be inserted –decentralized is better when »operations have strong connection (p226) »the operations will always be performed in same order

Design model - Use cases with extension extension of one use case by another is represented by a probe position. This position indicates a position in the use case to be extended and is often accompanied by a condition which indicates under what circumstances the extension should take place. The probe belongs to the extending use case, not the original extended use case Homogenization of stimuli is also required in the design phase Use as few stimuli as possible (with maximum reuse)

Block Design Starts after designing all the use cases for a block implementation of the blocks start with the freezing of the block interfaces ancestor blocks should be implemented before descendant blocks interface for Returning item block is got with the help of the interaction diagram ( pg 231) public and private block modules (8.18) other requirements can be got from requirements spec. (real time, memory space requirements etc.)

Object Behavior computational state: how far we have come in execution and potential future execution internal state: values of our variables that are important for the description of the object, variables relating to application and implementation environment state transition diagrams ( ) an object that will perform the same operation independent of the state when a certain stimulus is received is called a stimulus controlled object. Objects that implement entity objects are normally stimulus controlled. Objects that select operations based on its current state are called state-controlled objects. e.g., stack object - since we cannot pop out of an empty stack etc. Objects that implement control objects are normally state- controlled.

Internal block structure Detailed analysis and design can lead to automatic generation of this code homogenization of classes design as many component classes to use in design of classes to implement a block can encapsulate handling of instances (exists(), etc) and the actual instance in(increase counter etc) the same block

Implementation Use OO languages if possible traceability Table 8.1, (page 247) implementation of probes (250)