Presentation on software construction

Software Construction
1
Object-Oriented Software Engineering (C.Sc.539)
MSC-CSIT
Central Department of Computer Science & Information Technology (CDCSIT)
TU, Kirtipur, Nepal

Presentation
On
2
Presented By
Santosh Pyakurel (50)
Hari Lal Chalise (57)
Nischal Maharjan (60)

• 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 3
1.Introduction

• 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.
1.Introduction

1.Introduction
Fig.1.1 : SDLC

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

1.1. Why do we have a construction process?
• 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.

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.

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

• 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.

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

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.

1.2. What is done in the construction phase?
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)

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.

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.

2. The Design Model
2.1.Traceability
• The design model will further refine the analysis model in light of the actual
implementation environment.
• We will explicitly define the interface of the objects and also the semantics of the
operations.
• Additionally we will decide how different issues such as DBMSs, programming
language features and distribution will be handled.
• The design model will be composed of blocks which are the design objects. These
will make up the actual structure of the design model and show how the system
is designed
• These blocks will be implemented in the source code.

2.1.Traceability
• 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.

2.1.Traceability
• We have the great advantage of traceability ; you can easily find your way in the
system even if it has been subjected to major changes.
• It is also important to have a high functional locality in order to know that
changes will not influence large parts of the system.
• Here is a example of our analysis model shown in figure 2.1.
• Based on this analysis model we can now mechanically , and seamlessly , find the
first attempt at a design model.
• The first attempt is simply to design the same model as a analysis model.
• To differentiate between the two models, we use another notations and draw
these blocks as rectangles instead as circles, shown in figure 2.2.

2.1.Traceability
Fig 2.1 : Analysis model of the recycling machine

2.1.Traceability
Fig 2.2 : First attempt to design the structure of the recycling machine

2.1.Traceability
• During design we therefore must decide how this association should be
implemented and change the design model to reflect this.
• Similarly , if the programming language does not offer any technique to support
inheritance , we must reflect on how the inheritance in the analysis model is
really implemented .
• The design model enables us to reduce the complexity of the system.
• The blocks are actually an abstraction mechanism for the source code.
• By speaking in terms of blocks we can discuss the system on a survey level and
understand the architecture of the system.

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.

• This implies that as few objects as possible should be aware of the constraints of
the actual implementation environment.
• Therefore the overall strategy to handle it should be to have such commitments
locally and to encapsulate them as much as possible.
• To be able to change parts in the target environments, these parts should be
encapsulated in a new block. You will thus create new blocks that represent
occurrences in the target environment.
• Example, if your application will handle files in the operating systems, you should
create a block that interfaces the application’s file handling and the OS’s file
handling as shown fig 2.3.
• In fig 2.3 , the file manager block offer operations such as create file to the
applications objects.

Fig.2.3 Special block should be included to encapsulate the special
properties of the target environment

• When producing software the it would then be decided which module should be
linked into the final product , What way is chosen is dependent above all on the
programming environment.
• It is also important to investigate whether the target environment will execute in a
distributed way on different processors or in different processes .
• Which programming language is used will affect the design.
• Closely related to the programming language is the use of components for
programming . The use of such component libraries may also affect the design.
• Often existing products are used when developing new systems such as(DBMSs),
user interface management system(UIMS), network facilities and other internally
or externally developed applications that should be incorporated in this new
system.

• Products that are used only during developments may also affects the design.
Such products may includes compilers, debuggers, preprocessors and others tools.
• They may affect how the code is written and configured other such implications
may come from standards and coding rules.
• During construction we must also take into consideration any requirements for
performance or limitations of memory. Such requirements may also effect the
design.
• E.g. when database are used and frequent transactions are too slow. Then a
redesign of the database design may be necessary.
• The people and organization involved in the development could also affect the
design.

• All of these issues should affect the design as little as possible for maximum robustness.
• The Overall principle is that changes can and should occur, but all changes should be
justified and documented, also for robustness reason.
• Principally , we may have to change the ideal design model in various ways:
• To introduce new blocks in the design model which does not have any representation in the
analysis model.
• To delete blocks from the design model,
• To change blocks in the design mode (splitting and joining existing blocks),
• To change the associations between the blocks in the design model.
• Normally ,adding blocks to handle the environment is a good change. Adding blocks for
other functionality should normally not be done, since they should be introduced
through the analysis model.

28
• Deleting blocks is more suspicious, Why are you deleting the block? If you have a
good reason for it is fine . If it is not, you should view such a change with great
reservation.
• Splitting and joining blocks are also suspicious changes . Any such change will
often decrease the robustness of the system and should be done with great care
for implementation or performance reasons it may be justified, but the designer
should devote a great deal of judgment to such changes.
Fig 2.4 Behavior b1 extends behavior b2 this will normally implemented
with a stimulus being sent from b2 to b1

29
• Changes of associations are perhaps the most common changes in the design
model. These often come from the implementation environment.
• Synchronization and communication between processes is one example of where
the communication between objects may be changed.
• What extends actually means is that a behavior , b1 ,shall be inserted into another
behavior, b2, shown in fig2.4.
• We want the behavior b2 to be completely independent and unknowing of
behavior b1.
• Ideally we should want b1 itself to take the initiative and insert itself into b2,
however there is no mechanism in some ordinary programming language by which
this can be express.

30
• One solution to this is to have b2 take the initiative by sending a stimulus to b1.
How we do this in source code will be described when we implement the blocks.
• We will therefore have a communication association from b2 to b1 where this
stimulus could be sent.
• In the example of the recycling machine we have one extends association .We
choose to implement this in the manner described above.
• In the analysis model we have a conceptual picture of the functionality . The
extends association has come from the Alarm use case.
• When an alarm is detected during insertion of items , the Alarm use case should
be inserted. The detection is done by customer panel which sends the error
stimuli to the system.

31
• The receiver is now Deposit Item receiver extended with Alarmist.
• The communication association should thus be between Deposit Item Receiver
and Alarmist since this is the way the stimuli will be sent in the design.
Fig 2.5 The refined designed model for the recycling machine

32
• Any inheritance association must be reviewed if we cannot implement it in the
programming language.
• Before we can implement the blocks we must describe in detail how they are to
communicate with one another.
• This is done by defining the stimuli to be sent between them.
• When we have described the block interfaces completely, we can implement them
seamlessly using the rules that describes how the different terms are
implemented in the relevant programming language.

33
Fig.2.6 The first proposal of the classes that implements the Receipt Basis
block Classes with a c are ready made component.

34
2.3.Interaction diagram
• When we have identified the system architecture we describe how the blocks are
to communicate.
• This is done by designing the use case which were described in the analysis
phase.
• The use cases constitute the key to OOSE .They control the analysis and generate
the analysis model.
• The interaction diagram describes how each case is offered by communicating
objects.
• For each concrete use case we will draw an interaction diagram. The diagram
shows how the participating objects realize the use case through their interaction
.
• The interaction takes place as the blocks send stimuli between one another.

35
• As we draw the interaction diagrams, we will also define all the stimuli including
their parameters sent.
• The interaction diagram is a type of diagram used for a long time in the world of
telecommunications.
• In the interaction diagram we have drawn a column for the Deposit Item when
the use case is carried out, this object will actually be Can , Bottle or Crate we
have consequently also used polymorphism in the interaction diagram; this is a
very useful technique.
• In almost all the interaction diagrams we also have a column for the surrounding
world, usually call this column the system border.
• This column represents the interface with everything outside the blocks in the
diagram , such as external actors.

36
Fig 2.7 The sketch for the interaction diagram for the use case Returning Item consists
of columns for each block that participates, and a column for the system border.

37
• 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.

38
Fig 2.8 Interaction diagram of the recycling machine with operations in the
participating block.

39
2.4.Defination 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.

40
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 .
• The receiver may be active when the signal arrives and therefore the signal must
be in queued at the receiver until processed.
Fig.2.9 different types of stimuli may be used in OOSE

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.
• The use case starts as the technician sends a stimulus to Transporter. And
transporter then ask Pallet how many times it has been moved.
• 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.
• In the interaction diagram shown in fig 2.10 , we can see that everything is
handled and controlled by the Transporter.
• This object controls the flow and operates on the other objects, and then it
decides what to do.

2.5.Structures of interaction diagram
Fig.2.10 Transport with the transporter controlling the detailed flow

2.6. Use case with extends
• One of the most important properties in the use case model is the possibility of the
extending a use case by means of extends.
• We must also be able to describe this behavior in the interaction diagram. This is done by
means of probes.
• A probes is a positions in a description where an extended behavior can be inserted.
• The description in which there is a possibility that an extended new behavior shall be
added should not show that a behavior can be inserted.
• An extend between two use cases means that when one use case is executing, obeying its
description, this use case is extended to follow also the behavior of the description of the
second use case.
• The probe then gives the position in the first use case where the extension will take place.
• In the interaction diagram drawn for the inserted use case, we must specify the probe as
exactly as possible .

2.6. Homogenization
• The use cases are normally designed in parallel and by several designers who can
work more or less independently of one another.
• This means that stimuli are defined by several different designers.
• We therefore have to homogenize all stimuli when the use cases have been
designed .
• Homogenization means that we try to get as few stimuli as possible, which should
be maximally reusable and easy to work with . We should strive for is a set of
powerful stimuli that can be reuse.
• Sometime it may be sufficient to change the name of the stimulus or to change the
parameters.
• This new set of stimuli must have the same power of expression as the new set.

2.6. Homogenization
• For instance, imagine you have the following set of stimuli defined on an object
person by different developers.
What_is_your_phone_number
Where_do_you_live
Get_address
Get_address_and_phone_number
These could be homogenized to
Get_address
Get_phone_number
• We have reduced the number of stimuli , but we can get everything that we got
with the first set-up of stimuli.

3. Block design
• 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 .
3.1. The block interface

• 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 .
3.2. Object behavior

3.1. Object behavior
Fig.3.1 A state transition graph for describing a stack

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.

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.

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.

• 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.
4. Working with construction
4.1. Existing product

• 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.
4.2. Abstractions

• 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.
4.2. Development is incremental

• 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.
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.
5. Summary

Thank YOU !!!

Presentation on software construction

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Presentation on software construction

Similar to Presentation on software construction (20)

Recently uploaded

Recently uploaded (20)

Presentation on software construction