Software Construction

Contents
Introduction
Design Model
Block Design
Working with construction
Summary

Software Construction 1
Software Construction
1.Introduction(cont.…)
• Software engineering discipline.
• Group of activities that go into software development.
• Focuses on coding and debugging but also includes some detailed design and unit
testing.
• Detailed creation of working meaningful software through a combination of
coding, verification, unit testing, integrating testing and debugging.
• Comes after architectural design and before system testing.

Software Construction 2
1.Introduction(cont.…)

• Large part of software development.

• Typically takes 30 to 80 % of the total project.
• Construction is at center of the software development process.
• Construction is also sometime known as “coding” or “programming”.
• Software construction knowledge area is linked to all the other knowledge areas,
but must strongly linked to software design and software testing.
• Construction is mostly coding and debugging but also involves detailed design,
construction planning, unit testing, integration testing and other activities.

Software Construction 3
1.Introduction(cont.…)

Fig.1.1 : SDLC

Software Construction 4
 1.Introduction

Fig.1.2 : Construction’s place related to other software development activities

Software Construction 5
1.1. Why do we have a construction process? (cont.…)
• Build our system in construction, based on the analysis model and the requirements model
created during analysis.
• Construction process lasts until the coding completed and the included units have been
tested.
• Construction consists of design and implementation.
• Following the construction process we have the testing process in which the use cases and
the entire system are tested and certified.
• This does not mean that you must wait until all parts have been constructed before starting
the verification of the system, instead we try to do as much as possible in parallel.

Software Construction 6
1.1. Why do we have a construction process? (cont.…)
There are three main reasons for having a construction phase.
a) The analysis model is not sufficiently formed.
• In order to seamlessly change to the source code we must refine the objects; which
operation should be offered, exactly what should be communicate between the different
objects look like, which stimuli are sent , and so on ?
b) The actual system must be adopted to the implementation environment.
• In analysis we assumed an ideal world for our system. In reality we must make
adaptions to the environment in which the system implement.
• This means that we must initially transform the analysis model from analysis space to a
space with still more dimension, shown in fig-3.

Software Construction 7
1.1. Why do we have a construction process? (cont.…)

Fig.1.3 Transform a model in the analysis space into design space.

Software Construction 8
1.1. Why do we have a construction process? (cont.…)
• We must for example consider performance requirements, the properties of the
programming language, the DBMS to used , and so on.

c) We want to validate the analysis results.

• As our system is growing and formalized, we will see how well the analysis
model and the requirement model describe the system.
•During construction , we can see at an early stage whether the result of the
analysis will be appropriate for construction?
• If we discover unclear points in the analysis model or requirements model , we
must clarify them, perhaps by returning to the analysis process.

Software Construction 9
1.1. Why do we have a construction process? (cont.…)

Since the purpose of analysis is to understand the system and to give it a good
structure.
Consequently important to understand that the considerations given in
construction should influence our system structure as little as possible.
We want to keep the good properties in the system that the analysis model has
focused on.

Fig.1.4 : The input and output models construction

Software Construction 10
1.1. Why do we have a construction process?
To make correct assessments regarding necessary performance optimization, in
most cases, we need something to measure.
Since we have nothing to measure until the system has been built, we cannot
make these at early stage.
To avoid this dilemma is to make simulations of the system in which we simulate
the critical part.
Another ways to perform prototyping to get an early opinion of what the system
will look like, but this method since you can make rough simplifications.
However , if you know for sure where the performance critical parts are, for
instance because you have a very good application knowledge, optimization could
be done at an early stage.

Software Construction 11
1.2. What is done in the construction phase? (cont.…)
Construction activity produces two models, the design model and the
implementation.
Thus construction is divided into two phase design and implementation which
each develop model as shown in fig.4.
The design model is a further refinement and formalizations of the analysis
model where consequences of the implementation environment have been taken
into account.
The implementations model is actual implementation(code) of the system.
(include who ,what , where and how a program is setup and run)

Software Construction 12
1.2. What is done in the construction phase? (cont.…)
To develop the design model we perform three main steps.
a) Identifying the implementation environment.
• Include identifying and investigating what consequences the implementation environment
will have on the design. Such as, how will the DBMS be incorporate into the system? what
components libraries will be used and how? How should processes and process
communication be handled? Error handling and garbage collection? And so on.
b) Incorporate these conclusions and develop a first approach to a design model.
• Here, we use the analysis model as a base and translate the analysis objects into design
objects in the design model that fits the current implementation environment.
• When doing further development, the analysis model forms a logical basis for understanding
the system and thus is an essential model to keep during the entire system life cycle.

Software Construction 13
1.2. What is done in the construction phase? (cont.…)
To develop the design model we perform three main steps.
c) Describe how the objects interact in each specific use case.
• Here the design model is formalized to describe all stimuli sent between the objects and also to
define, what each operation will do each object.
• The use model will be of great help during this help us to specify each specific flow in the
system in detail. This step gives us the object interface.

The implementation activity then implements each specific object from the design
model we get very detailed specifications of all objects, including their operations
and attributes.
The programming language and the component library used will of course be
fundamental tools of the implementation.

Software Construction 14
 2. The Design Model

2.1.Traceability

• It is ability to trace work items across development lifecycle.

• The first attempt at a design model can be made mechanically based on the analysis model.
• The transformation is made so that initially each analysis object becomes a block. This
transformation rule that we obtain a clear traceability in the models.
• Each analysis object is traceable to a block , changes introduced in the analysis model will be
local in the design model and thus also in the source code.
• Traceability is bidirectional, that is , it also goes the other way. We can trace a class in the source
back to the analysis see what give rise to it.
• Traceability is a tremendously important property in system development because each major
system will be altered during its lifetime.

Software Construction 15
Fig 2.1 : Analysis model of Fig 2.2 : First attempt to design the
the recycling machine structure of the recycling machine

Software Construction 16
2.2. The implementation environment
• To adapt the design model to the actual implementation environment, we must
first identify the actual technical constraints that the system should be built under.
• This identification may be done early, ideally before the analysis model is
developed since it affects how far the analysis model should be refined.
• What do we include in the implementation environment?
• Target environment(where the system should execute during operation),
• Programming language and existing products that should be used(e.g DBMSs), but in fact
everything that affects the realization of the system must be included in this concept.
• Since one of the most common changes of a system is a change in the
implementation environment , it is preferable to handle this in the same
‘changeable’ way as the rest of the system.

Software Construction 17
2.3.Interaction diagram
• Interaction diagram is created for each use-case diagram.
• Interaction diagram contains the detail description of different signals sent and received by the
system.
• The main purpose of interaction diagram is to define the protocols of each blocks in the system.
• The time axis in the interaction diagram is viewed as going downwards.
• The use case thus starts with the behavior described at the beginning of the interaction diagram.
• The time axis of the interaction diagram is not linear , but should be regarded as event controlled .
• The distance between two events in the diagram has no relation to the real time between these
events.
• At the left edge of the interaction diagram, to left of the system border , we describe the
sequences. The description is textual and consists of structured text or pseudo-code.
• If we use pseudo-code, constructs that exists in the current programming could be use .This is to
ease our later migration to the actual implementations.

18
Software Construction
 Fig 2.8 Interaction diagram of the recycling machine with operations in
the participating block.

19
Software Construction
2.4. Definition of Stimuli
• A stimulus is drawn in the interaction diagram as a horizontal arrow that starts in the columns
corresponding to the sending block and ends in the column corresponding to the receiving block.
• The interaction diagrams are controlled by events. A new event gives rise to a new operation,
these events are stimuli that are sent from one objects to another and initiate an operation.
• Most of the interaction diagram start with a stimulus from the outside, that is , it is drawn from
system border.
• When working on the design of the use cases you will define the stimuli that each object should
be able to receive .
• To define stimuli is one of the more critical parts of a development. since several persons are
normally involved in the design of the use cases , the stimuli to one and the same block will be
designed by different people.
• A stimulus can have different semantics, e.g. be either interprocess or intraprocess
communications.

20
Software Construction
2.4.Defination of Stimuli
• An intraprocess stimulus is a normal call inside one process .This kinds of
stimulus we normally called a message.
• An interprocess stimulus is a stimulus sent between two processes. Such a
stimulus we usually call a signal. Signal may be either synchronous or
asynchronous .

Fig.2.9 different types of stimuli may be used in OOSE

• The receiver may be active when the signal arrives and therefore the signal must
be in queued at the receiver until processed.

21
Software Construction
2.5.Structures of Interaction Diagram
• Interaction diagram gives the designer a unique possibility of seeing the entire sequence in a use
case at a survey level.
• Designer can quickly get a picture of how the sequence progresses over the objects participating
in the use case.
• Often tells us a lot about the realization characteristics of the use case.
• Here we can , in principle, validate the structure of the use case that was defined in the analysis
model.
• If it has been moved the maximum number of permitted times we must check whether the move
shall be made in the warehouse or if the move to be made to a checking station.

Software Construction 22
 Fork Diagram VS Stair Diagram
● Fork Diagram is characterized by the fact that is an object acting like a
spider in web and so controls the other objects' has centralized
structure. A centralized (fork) control structure is appropriate when:
❏ the operations can change order.
❏ new operations could be inserted.

● Stair diagram is characterized by delegate responsibility. It has

decentralized structure. A decentralized (stair) control structure is
appropriate when:
❏ the operations have a strong connection.
❏ the operations will always be performed in the same order.
 Fig.2.10 Transport with the transporter controlling the detailed flow

Software Construction 25
 3. Block design
3.1. The block interface
• The actual implementation of the block in the source code can start when the
block interfaces start to stabilize and are frozen.
• Often we refer to the source code as implementation model since it too is a model
with a finer granularity than the design model.
• When the implementation of blocks starts, normally ancestor blocks should be
implemented prior to descendent blocks .

Software Construction 26
 3.2. Object behavior
• As an intermediate level for the internals of the object , before looking at the actual
implementation , we may use state transition graphs.
• Their purpose is to provide a simplified description that increases understanding of
the block without having to go down to source code level,
• And to provide a description that is less dependent on the selected programming
language.
• In these graph we describe which stimuli can be received and what shall happen when
a stimulus is received, for a discussion on state transition graphs.
• States and state transitions can be described in many ways . We will here show some
different notations that can be used for the example we will use stack.
• Insertion ,delations takes place at one end, operation(Push,Pop) and work is in LIFO .

Software Construction 27
3.1. Object behavior

Fig.3.1 A state transition graph for describing a stack

Software Construction 28
3.3. Internal Block structure
• The internal structure of the block will consists of object modules.
• If our implementation language is object-oriented, these object modules will in
reality become classes in the language,
• But if we do not have classes naturally in language , then they will be module
units in the source code.
• When the structuring of a block is done, we define the classes in the system.
• Components are important to use in structuring the internals of a block
sometimes components must be adapted in order to be used,
• And therefore they may also give rise to new classes that act as a shell for the
component but, as said before.

Software Construction 29
3.4. Implementation
• Now that we have described the blocks using state transition graphs, we can seamlessly
implement them in the programming language.
• The adaption to the programming language will be made according to a specialization of the
construction process to the selected language.
• The specialization of programming describes how we translate the terms used in the design
into the terms and properties in the implementation language.
• Many projects and organizations have coding rule concerning how the source code should be
written.
• The purpose of these rule is to obtain a uniform source code that not only facilitates
understanding and reading ,
• But also achieves portability between different environments.
• Object-oriented language have classes and these classes will correspond to the object modules
that we have designed.

Software Construction 30
3.5. Implementation of probs
• The explanation why the extends association gives rise to a
communication association was given earlier.
• This association is associated with a probe which specifies where the
sequence should be inserted .
• By a probe we mean a position in a use case description or its
accompanying interaction diagram where, when a use case follows
this description, another behavior can be inserted.
• Since the original description must be independent of the new,
inserted behavior , all of the control structure should be placed in the
block offering the inserted use case.

Software Construction 31
4. Working with construction
4.1. Existing product
• A common requirements from the implementation environment is that the
system must use existing products.
• Even if the limit for extending the existing product and thus making a further
development is fluctuating, it is still two different problems.
• One case the existing product is the same system, but in an older version, and in
the other we build another system that only makes use of the existing product
because already exists.
• One of the criteria when deciding whether you should use something old or
develop something new yourself is to consider the testing costs.
• Another important decision is how well you know the existing product and how
much resources are needed to get know it.
• Otherwise it may take a long time , especially if the documentation is poor, before
you learned this product and how to use it.
Software Construction 32
4.2. Abstractions
• When you develop systems on an industrial scale you must at all time be able to handle
the system complexity.
• This is an the important issues for abstractions on different levels , we have seen how we
have used the blocks to encapsulate and thus abstract actual implementations details.
• In this manner we could group several classes in the actual system to one block in the
design model .
• The blocks structure used in the example is appropriate for smaller systems, but is by no
means satisfiable for large systems.
• We must find some way to group these blocks into larger unit.
• To flexible for larger systems, we can have subsystems within subsystems.
• These subsystems should becomes the managements units in the organization.

Software Construction 33
4.2. Development is incremental
• The development is an incremental process and many iterations must be done
before all stimuli are defined and the iterations can be frozen.
• When implementation is started , changes of the definitions of stimuli will occur.
There you will get notice that you must get a reference to an object as a
parameter.
• These iterations will occur and there is no point in rejecting them initially.
• Iterations may thus exist on several different levels of granularity .
• Still smaller iterations can mean that after an inspection meeting you may
change something in the design.
• The lowest level of iteration is probably an individual designer who simply makes
changes in his or her own classes.

Software Construction 34
5. Summary
• Construction we carry out the design and implementation of the system.
• Based on the output from analysis.
• Purpose with this model is to gain a robust and maintainable structure over the
entire system life cycle.
• In contrast , we must thus identify the actual implementation environment.
• We must investigate all prevailing conditions for the realization of the system,
includes how the DBMS should be integrated, how processes and distribution
should be handled , the constraints of programming language, what component
library used and the incorporation of any GUI tools.
• Also includes organizational issues such as distributed development, competence
are of the staff and market issues.
• When the analysis model starts mature , the implementation strategy should be
added to this model.

Software Construction 35
 5. Summary
• This will give us the first design model. Here we show how the DBMS is
incorporated, how the system distribution is solved , and so on.
• The objects are then structured and implemented using one or several objects
modules.
• The implementation is straightforward in the language. An object oriented
language is preferable since all important concepts used in OOSE are directly
mapped onto these languages.
• If the language is not object oriented , some deviations must be made.
• To handle the construction for real system development, we need abstraction
mechanisms on several.
• The most important concept involved in handling complexity is that of
subsystems.
• These subsystems will partition the design model and can be used to define
explicit interface for the subsystems in terms of block interface or class
interface.
Software Construction 36
Thank YOU !!!

Software Construction 37