3/20/2023

Topics covered

qThe design process

qImplementation issues
q (Including Config Mgt)
qOpen source development
Design and Implementation

Chapter 7 Design and implementation 433 Chapter 7 Design and implementation 434

Design and implementation Build or buy

q Software design and implementation is the stage in the
software engineering process at which an executable
software system is developed.
q Software design and implementation activities are
invariably inter-leaved.
q Software design is a creative activity in which you
identify software components and their relationships,
based on a customer’s requirements.
q i.e. deriving a solution which satisfies software
requirements
q Implementation is the process of realising the design
as a program. Chapter 7 Design and implementation 435
q In a wide range of domains, it is now possible to buy off-the-shelf
systems (COTS) that can be adapted and tailored to the users’
requirements.
q For example, if you want to implement a medical records system,
you can buy a package that is already used in hospitals.
q It can be cheaper and faster to use this approach rather than
developing a system in a conventional programming language.
q When you develop an application in this way, the design process
becomes concerned with how to use the configuration features of
that system to deliver the system requirements.
Chapter 7 Design and implementation 436

1
 3/20/2023

Stages of Design The Design Process

q Problem understanding q Any design may be modelled as a directed graph
Look at the problem from different angles to discover the
q
design requirements. made up of entities with attributes which participate
q Identify one or more solutions
q Evaluate possible solutions and choose the most appropriate
in relationships.
depending on the designer's experience and available q The system should be described at several different
resources.
q Describe solution abstractions levels of abstraction.
q Use graphical, formal or other descriptive notations to
describe the components of the design. q Design takes place in overlapping stages.
q Re pea t p ro c e s s fo r ea c h i d e nt i f i ed a bs t r a c t i on
until the design is expressed in primitive terms. q It is artificial to separate it into distinct phases but
some separation is usually necessary.

Phases in the Design Process Design

q Computer systems are not monolithic: they are usually
Requirements composed of multiple, interacting modules.
specifica
tion

Design acti
vities
q Modularity has long been seen as a key to cheap, high
Architectur
al Abstract Interface Component Data
structur
e
Algorithm quality software.
design specifica
tio design design design
n design
q The goal of system design is to decode:
System Software Interface Component
Data
structure
Algorithm q What the modules are;
architectur
e specifica
tion specifica
tion specifica
tion specifica
tion
specification

Design pr
oducts
q What the modules should be;
q How the modules interact with one another

2
 3/20/2023

Modular programming Procedural Abstraction

qIn the early days, modular programming was qTh e most obvious design methods involve
taken to mean constructing programs out of functional decomposition.

small pieces: “subroutines” q This leads to programs in which procedures

represent distinct logical functions in a program.
qBut modularity cannot bring benefits unless
q Examples of such functions:
the modules are
q “Display menu”
q autonomous,
q “Get user option”
q coherent and
q This is called procedural abstraction
q robust

Object-oriented design Five Criteria for Design Methods

• The system is viewed as a collection qWe can identify five criteria to help
of interacting objects. evaluate modular design methods:
qModular decomposability;
• The system state is decentralised and
qModular composability;
each object manages its own state.
qModular understandability;
• Objec ts m ay be ins tance s of an
qModular continuity;
object class and communicate by
qModular protection.
exchanging methods.

3
 3/20/2023

Modular Decomposability Stepwise Refinement

q This criterion is met by a design method if the q The simplest realistic design method, widely used in practice.

method supports the decomposition of a problem q Not appropriate for large-scale, distributed systems: mainly

into smaller sub-problems, which can be solved applicable to the design of methods.
q Basic idea is:
independently.
q Start with a high-level spec of what a method is to achieve;
q In general the method will be repetitive:
q Break this down into a small number of problems (usually
q sub-problems will be divided still further
no more than 10)
q Top-down design methods fulfil this criterion;
q For each of these problems do the same;
q stepwise refinement is an example of such method q Repeat until the sub-problems may be solved immediately.

Stepwise Refinement Hierarchical Design Structure

System level

Sub-system
level

source: learnlearn.uk/

4
 3/20/2023

Top-down Design Modular Composability

• In principle, top-down design involves
starting at the uppermost components in A method satisfies this criterion if it
t h e h ie ra r c h y a n d w o rk in g d o w n t h e
hierarchy level by level. leads to the production of modules
• In practice, large systems design is never
that may be freely combined to
truly top-down.
• Some branches are designed before produce new systems.
others.
• De sig n er s r e u s e e xp e rie n ce ( an d Composability is directly related to
sometimes components) during the
design process. the issue of reusability

Examples
1. The Numerical Algorithm Group (NAG) libraries contain a wide Modular Understandability
range of routines for solving problems in linear algebra, differential A design method satisfies this criterion if it
equations, etc. encourages the development of modules which
are easily understandable.
2. The Unix shell provides a facility called a pipe, (|), whereby:
COUNTER EXAMPLE 1.
 the standard output of one program may be redirected to the standard
 Take a thousand lines program, containing no
input of another for further processing; this convention favours procedures; it’s just a long list of sequential
composability. statements.
 Divide it into twenty blocks, each fifty statements
 Syntax: Command 1 | command 2 | command 3 | ……
long.
 E.g.: $ cat roughstudentlist.txt | sort | uniq > sortedstudentlist.txt  Make each block a method.
 (Fetches the file, sorts it and removes redundancies and saves in another file C O U N T E R EXAMPLE 2. “Go to”
with the same extension.) statements ...

5
 3/20/2023

A BASIC program written with

a GOTO statement Understandability
• Related to several component characteristics
– Can the component be understood on its own?
*
– Are meaningful names used?
" "
– Is the design well-documented?
"10"
– Are complex algorithms used?
"*"
• Informally, high complexity means many
+

excessive use of go to relationships between different parts of the

statements --> spaghetti
code. design.

Modular Continuity Modular Protection

A method satisfies this criterion if it leads to the A method satisfies this criterion if it yields architectures
production of software such that a small in which the effect of an abnormal condition at

change in the problem specification leads run-time only affects one (or very few) modules

to a change in just one (or a small number EXAMPLE. Validating input at source prevents errors

of ) modules. from propagating throughout the program.

 EXAMPLE. Some projects enforce the rule that no COUNTER EXAMPLE. Using int types where
numerical or textual literals should be used in short types are appropriate.
programs: only symbolic constants should be used

6
 3/20/2023

Five principles for Good Design Linguistic Modular Units

A programming language (or design language)
Once we have understood the criteria should support the principle of linguistic modular
for evaluating modular design units:
methods, we can distil five principles Modules must correspond to linguistic units in
the language used
that should be adhered to when designing:
Linguistic modular units;
EXAMPLE. Java methods and classes
Few interfaces;
COUNTER EXAMPLE.
Small interfaces
Subroutines in BASIC are called by giving a line
Explicit interfaces; number where execution is to proceed from; there
Information hiding.
is no way of telling, just by looking at a section of
code, that it is a subroutine (cf spaghetti code slide)

Few Interfaces Few Interfaces

This principle states that the overall number of
communication channels between modules should
be as small as possible:
 Every module should communicate with as few
others as possible.
So,in the system with n modules, there may be
a minimum of n-1 and
a maximum of n(n  1) links;

2
 Your system should stay closer to the minimum

7
 3/20/2023

Small Interfaces (Loose Coupling)

Small Interfaces (Loose Coupling)
This principle states:
If any two modules communicate,
t he y s h oul d e xc h a n g e a s l i t tl e
information as possible.
COUNTER EXAMPLE. Declaring
all instance variables as public!
q Coupling and Cohesion
q When a software program is modularised, its tasks are
divided into several modules based on some
characteristics.
q Modules are sets of instructions put together in order
to achieve some tasks.
q They are considered as single entities but may refer to
each other to work together.
q T h e q u al i t y o f a d e s i g n o f m od u l e s a n d t h e i r
interactions can be measured via the following metrics:
1. coupling
2. cohesion.

Coupling Coupling
qLoose coupling means component changes are
qA measure of
unlikely to affect other components.
qt he strength of the q Shared variables (see next slide) or control
interco nnecti ons be tw ee n information exchange lead to tight coupling.
q Loose coupling can be achieved by state
system components
decentralisation (as in objects where each
qi.e., a measure of the degree of has its own state) and component
interdependence between co m m u n ic at i o n v ia p a r a m et e r s o r
message passing.

8
 3/20/2023

Tight Coupling Loose Coupling

Module A

A’s data
Module A Module B

Module B Module C
Module C Module D B’s data C’s data

Shared data Module D

area D’s data
A change in the shared data area affects all modules.

Coupling and Inheritance Necessity of Coupling

• Object-oriented systems are loosely coupled
because there is no sh ared sta te and ob je cts
communicate using message passing.
• However, an object class is coupled to its
super-classes.
• Changes made to the attributes or operations in a super-
class propagate to all sub-classes.
In coupling, the components of two or more modules
are related.
T h i s might not be a good idea in functional
programming as it means an error in one module will
be propagated to other modules.
But by integrating coupling, modules interact and can
thus achieve the global objectives of a system
Chapter 7 Design and implementation 470

9
 3/20/2023

Explicit Interfaces Information Hiding

qThis principle states:
If two modules must communicate, they q All information about a module, (and particularly
how the module does what it does) should be
must do it so that we can see it:
private to the module unless it is specifically
 If modules A and B communicate, this must be declared otherwise.
qThus each module should have some interface,
obvious from the text of A or B or both.
which is how the world sees it
Why? q anything beyond that interface should be hidden.
 If we change a module, we need to see what qThe default Java rule:
q Make everything private
other modules may be affected by these changes.

Cohesion Cohesion Levels

qA measure of how well a component “fits together”. q Various levels of cohesion have been identified.
They are broadly grouped into 3; i.e. modules can have:
q Defines the degree of intra-dependability within q

q low (unacceptable) cohesion

elements of a module.
q The greater the cohesion, the better the program design.
q Note that a component should implement a
single logical entity or function.
q Thus cohesion is a desirable design component
attribute as whe n a change has to b e made, it
q The modules will be extremely difficult to effectively implement, test,
and maintain.
q They are highly undesirable and should be modified or replaced
q moderate (acceptable but not ideal) cohesion
q Consider modifying them, but note that changes might introduce other
design problems, so that you might best leave them alone.
q high (desirable) cohesion.
q Modules do not need to be changed (except to correct other kinds of
design problems).

is localised in a single cohesive component.

10
 3/20/2023

Low Cohesion Level Moderate Cohesion

 There are seven types of cohesion, namely – Procedural cohesion
 Co-incidental cohesion
 Elements
of a module are grouped together, which
 Unplanned and random cohesion, which might be the
result of breaking the program into smaller modules for are executed sequentially in order to perform a
the sake of modularization. task.
 Because it is unplanned, it may bring confusion to the Communicational cohesion
programmers and is generally not-accepted.
 Elements of a module are grouped together,
 Logical cohesion
executed sequentially and work on same data
 Logically categorised elements are put together into a
module. (information).
 Temporal Cohesion Sequential cohesion
 Elements of module are organised such that they are  Elements of a module are grouped because the
processed at a similar point in time. output of one element serves as input to another
and so on.

High Cohesion Cohesion Levels

Functional cohesion
 Considered to be the highest degree of cohesion Coincidental cohesion (weak)
 Is highly expected.
 Elements of a module in functional cohesion are
Parts of a component with no
grouped because they all contribute to a single well-
defined function. meaningful relationship to one
 It can also be reused.
another are simply bundled
together.
Chapter 7 Design and implementation 477

11
 3/20/2023

Coincidental Cohesion Coincidental Cohesion

A module that only has coincidental cohesion is one supporting  The legendary - and, one hopes, mythical- FORTRAN or
tasks that have no meaningful relationship to one another. COBOL programmer who, after being told to use
 E.g. ONE module (not necessarily one that can be implemented subroutines and being told of an ``ideal'' length for these,
using software!) supporting the following tasks. drew a horizontal line after every twenty lines of code and
 Fix Car put each block into a module.
 Bake Cake  If you discover that the best name you can find for a
 Walk Dog module is, ``Miscellaneous Functions,'' then this a sign that
 Fill out Job Application Form your module has this undesirably low level of cohesion.
 Have a soda  In a design for a system that's to be implemented using
 Get out of Bed any high level programming language, there are ZERO
 Go to the Movies
excuses for inclusion of modules whose level of cohesion
is this low, .

Cohesion Levels Logical Cohesion

 ``A logically cohesive module is one whose elements contribute
Logical association (weak) to activities of the same general category in which the activity
or activities to be executed are selected from outside the
 Components which perform similar functions are module.''
 E.g. when contemplating a journey you might compile the
grouped together. following list:
 Go by Car
 E.g. having a module called Do All System I/O.  Go by Train
 Go by Boat
 The only thing that relates all activities here is that  Go by Plane
 What relates these activities?
they're all means of I/O.
 They're all means of transport.
 But to perform any I/O, a person must choose one (it’s  For any journey, a person must choose a specific subset of
these modes of transport.
unlikely one would use them all on any one occasion).  It's unlikely anyone would use them all on any particular journey.

12
 3/20/2023

Logical Cohesion Cohesion Levels

A logically cohesive module contains a number of activities
of the same general kind. Temporal cohesion (weak)
 To use the module, we pick out just the piece(s) we need.
Components which are activated at the
 Thus, a logically cohesive module is a grab bag of activities.
 The activities, although different, are forced to share the same time are grouped.
one and only interface to the module. E.g. a Do All Startup Activities module or
 The meaning of each parameter depends on which activity
is be in g used ; f or c e rta i n a ctiv iti e s , some of the Do All Shutdown Activities module
parameters will even be left blank
Though this might have the higher level
 (although the calling module still needs to use them and
to know their specific types)." procedural cohesion.

Moderate Cohesion (Acceptable)

Temporal Cohesion Procedural Cohesion
A temporally cohesive module is one supporting tasks A module with (only) procedural cohesion is one supporting
that are all related in time e.g.: different and possibly unrelated activities, in which control
Wash the dishes
passes from one activity to the next.
 E.g.: ”Prepare for Christmas Lunch:''
Check the doors are locked
 Clean Utensils from Previous Meal
Turn off TV
 Prepare Turkey for Roasting
Brush Teeth
 Make Phone Call
These activities are (only) related by the fact that you
 Take Shower
do them all late at night, just before you go to bed.
 Chop Vegetables
 Might have a higher level of cohesion: procedural
 Set Table
cohesion.

13
 3/20/2023

Moderate Cohesion (Acceptable)

Procedural Cohesion Cohesion Levels
This is a bit better than temporal Communicational cohesion (medium)
cohesion, since we know that there's a
All the elements of a component operate on
fixed linear ordering of the
activities. the same input or produce the same output.
 E.g. a module with the entire interface to a stack
However, there's still not much
reason for putting all these activities - supporting the following activities:

together into one module. ◻ ``Push,'' ``Pop,'' an ``Empty?'' test, initialisation

of a new (empty) stack etc.

Communicational Cohesion
Cohesion Levels
A mod ule exhi bi ts co mmunic ati on al
cohesion if all the activities it supports use S e quential cohesion
the same input or output data - or access
and modi fy the same p art of a d ata (medium)
structure.
E.g. a module supporting the activities The output for one part of a
Find Title of Book
Find Price of Book
component is the input to
Find Publisher of Book another part.
Find Author of Book

14
 3/20/2023

Sequential Cohesion Cohesion Levels

A sequentially cohesive module is one whose elements are
involved in activities such that output data from one Functional cohesion (strong)
activity serves as input data to the next.
A module exhibits functional cohesion if
 E.g. a module supporting the following activities:
 Clean Car Body i t s u p po r ts a c t i vi ti e s n e e d e d f o r t h e
 Fill in Holes in Car
 Sand Car Body
execution for one and only one problem-
 Apply Primer related task.
 ...presumably, with the ``car'' being the input that is being
``passed'' as a parameter from task to task. Each part of a component is necessary for
the execution of a single function.

High Cohesion (Desirable)

Functional Cohesion Cohesion as a Design Attribute
E.g. modules with names such as: Not well-defined.
 Compute Cosine of Angle
 Verify Alphabetic Syntax  Often difficult to classify cohesion.
 Read Transaction Record
Inheriting attributes from super-classes
 Determine Customer Mortgage Repayment
 Compute Point of Impact of Missile weakens cohesion.
 Calculate Net Employee Salary
 To understand a component, the super-classes as
 Assign Seat to Airline Customer
well as the component class must be examined.

 Object class browsers assist with this process.

15
 3/20/2023

Key points Implementation issues

q Software design and implementation are inter-leaved q Focus here is not on programming, although this is obviously important, but
on other implementation issues that are often not covered in programming
activities. texts:
q Reuse Most modern software is constructed by reusing existing
q The level of detail in the design depends on the type of components or systems. When you are developing software, you should
make as much use as possible of existing code.
system and whether you are using a plan-driven or agile q Configuration management During the development process, you have
to keep track of the many different versions of each software
approach. component in a configuration management system.
q Host-target development Production software (software that has gone
q The process of object-oriented design includes activities to live, and is being used to accomplish the business purpose it was built
for) does not usually execute on the same computer as the software
design the system architecture, identify objects in the development environment.
system, describe the design using different object models q Rather, you develop it on one computer (the host system) and execute
it on a separate computer (the target system).
and document the component interfaces.
Chapter 7 Design and implementation 495 Chapter 7 Design and implementation 496

Implementation issues
Reuse Reuse levels
q From the 1960s to the 1990s, most new software was q The abstraction level
developed from scratch, by writing all code in a high-level At this level, you don’t reuse software directly but use
q
programming language. knowledge of successful abstractions in the design of
q The only significant reuse or software was the reuse of
your software.
functions and objects in programming language libraries. q The object level
q At this level, you directly reuse objects from a library
q Costs and schedule pressure mean that this approach
rather than writing the code yourself.
became increasingly unviable, especially for commercial
q The component level
and Internet-based systems.
q Components are collections of objects and object
q An approach to development based around the reuse of
classes that you reuse in application systems.
existing software emerged and is now generally used for
q The system level
business and scientific software.
q At this level, you reuse entire application systems.

Chapter 7 Design and implementation 497 Chapter 7 Design and implementation 498

16
 3/20/2023

Reuse costs Reusability

q The costs of the time spent in looking for software to
reuse and assessing whether or not it meets your needs.
q Where applicable, the costs of buying the reusable
software. For large off-the-shelf systems, these costs can
be very high.
q The costs of adapting and configuring the reusable
so ft wa r e c om p one n t s o r s y s t e m s t o r e f l e c t th e
requirements of the system that you are developing.
q The costs of integrating reusable software elements with
each other (if you are using software from different
sources) and with the new code that you have developed.
Chapter 7 Design and implementation 499
q A major obstacle to the production of cheap quality
software is the intractability (problematic nature) of the
reusability issue.
q Why isn’t writing software more like producing hardware? Why do
we start from scratch every time, coding similar problems time
after time after time?
q Obstacles:
q Economic;
q We can’t afford it (see costs of reuse in the previous slide)
q Organisational;
q Different organisations, different ways of going about things.
q Psychological.
q I want to build my own, I don’t think yours will do all I want it
to do.

Implementation issues
Configuration management
qConfiguration management is the name given
to the general process of managing a changing
software system.
qThe aim of configuration management is to
support the system integration process so that
q all developers can access the project code and
documents in a controlled way,
q find out what changes have been made, and
q compile and link components to create a system.
Chapter 7 Design and implementation
Software Change
q ‘Change is a fact of life in software development.’
q ‘No matter where you are in the system life cycle, the system will change.’
q ‘Most changes are justified.’
q Pressman
q Why does software continually change?
q Business growth, business downsizing, budget constraints
q New business, new markets, new customers
q Existing customers change requirements
q Project managers change strategy
q Developers learn of new technical solutions
q During the development of software change must be
managed and controlled in order to improve quality and
reduce error.
501

17
 3/20/2023

Configuration Management Configuration Management

q Configuration Managemen t is a term from conven tional q Once you have all of your software "parts", you have to
manufacturing. arrange them to produce your product.
q The dictionary definition of a configuration is something that q Each part may have to go through a number of steps or
results from a particular arrangement of parts or components. transformations before being assembled into the final
q In software, the parts include product.
q program source code q We are now talking about many thousands or million of
q images steps to build a software product.
q data files. q This combination of software parts plus processing steps is
q A big difference for software is that all of these parts are different. called a Software Configuration.
q When you make widgets you may use a million bolts, but q If you sell several versions of your product, for example,
they're all basically the same. If you lose one, you can easily get a domestic version, export versions or a "lite" version,
an equivalent part. In software, each part is unique and can't be
you will then have one Software Configuration for each
replaced.
Chapter 7 Design and implementation 503 version. Chapter 7 Design and implementation 504

Configuration Management Configuration Management

q Version systems also deal with another peculiar aspect of software
systems.
qA Version System is essentially an inventory
q A software component can change over time.

system for software components.
q Since a large number of parts go into a software
product, we need a version system
q to store all of these parts and
q record which part goes into which configuration of your
product.
Chapter 7 Design and implementation
q In the first version of a product, you might have an image with a blue background.
q In the next release, the marketing department requests that it have a red
background instead.
q The engineering department makes the change and records that change in the
version system.
q We are still talking about the same part but it's a different version of the same
part.
q When the person building the product requests the set of parts from the version
system for the new release, they will get the image with the red background.
q If there is a request to rebuild the older version of the product, then the builder
will request the set of parts for that version and gets the image with the blue
background.
505 Chapter 7 Design and implementation 506

18
 3/20/2023

Software Configuration Management (SCM)

Configuration management (CM) defined Defined
q Configuration management (CM) is the detailed
qA set of activities that have been developed to
recording and updating of information that describes
manage change throughout the life cycle of computer
an enterprise's computer systems and networks,
software. (Pressman)
including all hardware and software components.
q The art of identifying, organising and controlling
q Such information typically includes the versions and
modifications to the software being built by a project
updates that have been applied to installed software
team.
packages and the locations and network addresses
qA quality assurance activity that is applied throughout
of hardware devices .
Chapter 7 Design and implementation 507
the software process
Chapter 7 Design and implementation 508

Software Configuration Management Software Configuration Items ( SCIs)

q Configuration Management handles the control of all qComputer programs
products or configuration items and changes to those
q source
items
q Products or configuration items include:
q executable

q documents, software, source code, hardware, tapes, qDocuments describing the programs
disks, computer listings q technical manual
q Aims: q users manual
q uniquely identify every version of every product or
qData
configuration item
q within program
q retain historical versions of software / documents
q provide an audit trail of all changes q external
Chapter 7 Design and implementation 509 Chapter 7 Design and implementation 510

19
 3/20/2023

Software Configuration Items ( SCIs) Software Configuration Items ( SCIs)

 System Specification
 Asthe Software Process progresses more and more SCI’s
are spawned creating a hierarchy of information  Project Plan
 e.g. a Software Specification may spawn  Requirements Specs
 a Project Plan,
 graphical models
 a Quality Plan,
 Test Plans,  process specs
 Design Documents,  prototypes
 Programs,
 maths specs
 Test Reports,
 Metrics Reports,  Prelim User Manual
 Review Reports, etc.
 Source Code Listing
 Change may occur at any time for any reason
Chapter 7 Design and implementation 511 Chapter 7 Design and implementation 512

Software Configuration Items ( SCIs) Software Configuration Items ( SCIs)

 Operation and Installation Manuals
 Design Spec
 data design  Executable Program
 architectural design  module executable code
 module design
 linked modules
 interface design
 Database Description
 object descriptions
 Test Specs  schema and file structure

 test plan and procedures  initial content

 test cases and recorded results  User Manual

Chapter 7 Design and implementation 513 Chapter 7 Design and implementation 514

20
 3/20/2023

Software Configuration Items ( SCIs) SW Configuration Management ...

 Maintenance Documents  How does an organisation manage the many versions of a
 problem reports system or program (and its documentation)?
 How does an organisation control change before and after
 maintenance requests
release to customers?
 engineering change orders  How do we know which is the current version?
 Standards/Procedures  How is everybody informed of the latest changes?
 Software Tools  Through the SCM process whose tasks include:

 editors 1. Identification
2. Version Control
 compilers
3. Change Control
 CASE tools 4. Configuration Auditing
5. Reporting
Chapter 7 Design and implementation 515 Chapter 7 Design and implementation 516

Software Configuration Management Software Configuration Management

Process … Process …
1. Identification
If a change is made to one Configuration Object it is
 Each SCI must be named and identified as objects.
possible to determine which other Configuration Objects
 SCI’s can be organised to form a database or repository of
in the repository are affected by the change
Configuration Objects with:

» Name and Description e.g. a change in a screen design affects

» Attributes and reference pointer to the object in the database  which program(s)?
» Relationships to other configuration objects  which user manual?
 The configuration objects are either
 etc.
» Basic objects or Aggregate objects (components)

21
 3/20/2023

Software Configuration Management Software Configuration Management

Process … Process …
2. Version Control q Version Control combines procedures and tools to
 Configuration Objects are baselined manage different versions of configuration objects
» before object is baselined it changes many times
» at baseline it becomes Version 1.0 q whereas
» after baseline all modifications are controlled
q Configuration Management allows a user to
 Subsequent changes become new versions
 Version 1.1  Version 1.1.1 then 1.1.2 specify alternative configurations of a system through

 Version 1.2 etc. the selection of appropriate versions

 Version 2.0 etc.

Software Configuration Management Software Configuration Management

Process … Process …

3. Change Control
4. Configuration Audit
 ‘For a large software engineering project uncontrolled change rapidly  How to ensure change has been properly implemented:
leads to chaos.’ (Pressman)
1. Formal Technical Review
 Process:
 A Change Request initiates a change 2. Software Configuration Audit
 The configuration object is ‘checked-out’ of the database
 Conducted by the Software Quality Assurance group
 The changes are applied to the object

 The object is then ‘checked-in’ to the database where automatic version control is 5. Status Reporting
applied.
 Focuses on communication of the changes to all people in
 Note that in an organisation a formal change control process
involving many steps is instituted to control all changes an organisation involved with the changes.

22
 3/20/2023

Configuration management activities Configuration Management Tools

 Version management
Text - documents and code
 where support is provided to keep track of the different versions of software
components.
» IBM : Librarian, Panvalet, CCC
 Version management systems include facilities to coordinate development by
several programmers. » UNIX : SCCS (Source Code Control System), RCS
 System integration
» DEC : CMS
 where support is provided to help developers define what versions of components
are used to create each version of a system. » Aide-de-Camp
 This description is then used to build a system automatically by compiling and
linking the required components. » PC : PC-RCS, CVS
 Problem tracking
 where support is provided to allow users to report bugs and other problems, and Graphics
to allow all developers to see who is working on these problems and when they
are fixed. » not compatible with text management systems

Chapter 7 Design and implementation 523

Configuration Management Tools

Data Configuration Management Tools
SCM tools you may use are: PC-RCS and CVS
» any data dictionary product

Binary - Object and Executable Revision Control System (RCS)

» IBM - CCC  Functions
- Pansophic - Panvalet, Panexec
 Checking in & checking out
- CMS (Change Management Systems)
 Diagnostics
» UNIX - SCCS, CMTS
» SUN - DSEE, NSE  Further info & Summary
» DEC - MMS/CMS

23
 3/20/2023

Revision Control System Functions of an SCM Tool

 Stores & retrieves multiple revisions
A Unix tool
 Maintains a complete history of changes
Automatically manages revisions
 Resolves access conflicts
Useful for revisions of:  Maintains a tree of revisions
 programs  Merges revisions and resolves conflicts
 documents  Controls releases and configurations
 graphics  Automatic identification
 papers  Minimises secondary storage

Configuration Management Summary
q When a system needs a hardware or software
upgrade, a computer technician can accesses the
configuration management program and database to
see what is currently installed.
q The technician can then make a more informed
decision about the upgrade needed.
q An a dv anta ge of a c onf i gur a ti on mana g eme n t
application is that the entire collection of systems can
be reviewed to make sure any changes made to one
system do not adversely affect any of the other
systems.
Chapter 7 Design and implementation
Implementation issues
Host-target development
q Most software is developed on one computer (the host),
but runs on a separate machine (the target).
q More generally, we can talk about a development
platform and an execution platform.
q A platform is more than just hardware.
q It includes the installed operating system plus other
supporting software such as a database management
system or, for development platforms, an interactive
development environment.
q Development platforms usually have different installed
software than execution platforms; these platforms may
529
have different architectures.
Chapter 7 Design and implementation 530

24

Development platform tools
q An integrated compiler and syntax-directed editing
system that allows you to create, edit and compile
code.
q A language debugging system.
q Graphical editing tools, such as tools to edit UML
models.
q Testing tools, such as Junit that can automatically run
a set of tests on a new version of a program.
q Project support tools that help you organise the code
for different development projects.
Chapter 7 Design and implementation
Component/system deployment factors
qIf a component is designed for a specific
hardware architecture, or relies on some other
software system, it must obviously be deployed
on a platform that provides the required
hardware and software support.
qH i g h a v a i l a b i l i t y s y s t e m s m a y r e q u i r e
components to be deployed on more than one
platform.
q This means that, in the event of platform failure, an
alternative implementation of the component is
available. Chapter 7 Design and implementation 533
3/20/2023
Integrated development environments (IDEs)
q Software development tools are often grouped to create
an integrated development environment (IDE).
q An IDE is a set of software tools that supports different
aspects of software development, within some common
framework and user interface.
q IDEs are created to support development in a specific
programming language such as Java.
q The language IDE may be developed specially, or may be
an instantiation of a general-purpose IDE, with specific
language-support tools.
531 Chapter 7 Design and implementation 532
Component/system deployment factors
qIf there is a high level of communications
traffic between components, it usually
makes sense to deploy them on the same
platform or on platforms that are
physically close to one other.
qThis reduces the delay between the time
a message is sent by one component and
received by another.
Chapter 7 Design and implementation 534
25
 3/20/2023

Open source development Open source systems

q Open source development is an approach to software qThe best-known open source product is, of
development in which the source code of a software
system is published and volunteers are invited to course, the Linux operating system which is
participate in the development process
q Its roots are in the Free Software Foundation widely used as a server system and, increasingly,
(www.fsf.org), which advocates that source code should
not be proprietary but rather should always be available as a desktop environment.
for users to examine and modify as they wish.
q Open source software extended this idea by using the qOther important open source products are
Internet to recruit a much larger population of volunteer
developers. Java, the Apache web server and the mySQL
q Many of them are also users of the code.
database management system.
Chapter 7 Design and implementation 535 Chapter 7 Design and implementation 536

Open source issues Open source business

q More and more product companies are using an open
qS h o u l d the product you are
source approach to development.
developing make use of open source q Their business model is not reliant on selling a
components? software product but on selling support for that
product.
qShould an open source approach be q They believe that involving the open source community will

used for the software’s development? allow software to be developed more cheaply, more quickly
and will create a community of users for the software.
Chapter 7 Design and implementation 537 Chapter 7 Design and implementation 538

26

Open source licensing
qA fundamental principle of open-source development is that
source code should be freely available, this does not mean that
anyone can do as they wish with that code.
q Legally, the developer of the code (either a company or an
individual) still owns the code. They can place restrictions on
how it is used by including legally binding conditions in an open
source software license.
q Some open source developers believe that if an open source
component is used to develop a new system, then that system
should also be open source.
q Others are willing to allow their code to be used without this
restriction. The developed systems may be proprietary and
sold as closed source systems.
Chapter 7 Design and implementation 539
License management
q Establish a system for maintaining information about
open-source components that are downloaded and
used.
q Be aware of the different types of licenses and
understand how a component is licensed before it is
used.
q Be aware of evolution pathways for components.
q Changes in the components
q Educate people about open source.
q Have auditing systems in place.
q Check that policies are being followed
q Participate in the open source community.
Chapter 7 Design and implementation 541
3/20/2023
License models
q The GNU General Public License (GPL).
q This is a so-called ‘reciprocal’ license that means that if you use
open source software that is licensed under the GPL license,
then you must make that software open source.
q The GNU Lesser General Public License (LGPL) is a variant of the
GPL license
q where you can write components that link to open source code
without having to publish the source of these components.
q The Berkley Standard Distribution (BSD) License.
q This is a non-reciprocal license, which means you are not
obliged to re-publish any changes or modifications made to open
source code. You can include the code in proprietary systems
that are sold.
Chapter 7 Design and implementation 540
A Usable Quality System
q Whether you buy, build or acquire/modify open
source software, ensure the system is usable.
q Shackel proposes four usability dimensions for a
quality system, viz;
q Effectiveness
q Learnability
q Flexibility
q Attitude
Chapter 7 Design and implementation 542
27
 3/20/2023

A Usable Quality System A Usable Quality System

q Shackel’s usability guidelines for a quality system
q Effectiveness (or throughput)
q refers to levels of human performance, measured in terms of
speed/accuracy for a proportion of users or proportion of
tasks.
q e.g. speed or error rate when using a GUI as compared to
a CLI
q Learnability
q How easily can new or occasional users accomplish tasks?
q Could be measured in terms of the number of trials
required to complete a task with no training vs. with a
controlled amount of training, or number of times users
consults ‘help’. Chapter 7 Design and implementation 543
q Shackel’s usability guidelines for a quality system
q Flexibility
q refers to variations in task completion strategies supported
by a system.
q E.g. saving in a GUI by either using an icon, menu or
shortcut keys
q Often measured by differences in performance levels as a
function of the presence or absence of added features.
q E.g., if there was no menu would performance degrade?
q Attitude
q refers to the acceptability of the system by the users
q generally measured by users’ subjective opinions elicited
from interviews or questionnaires.
Chapter 7 Design and implementation 544

Key points
q When developing software, you should always consider the
possibility of reusing existing software, either as components,
services or complete systems.
q Configuration management is the process of managing
changes to an evolving software system. It is essential when a
team of people are cooperating to develop software.
q Most software development is host-target development.
You use an IDE on a host machine to develop the software,
which is transferred to a target machine for execution.
q Open source development involves making the source code of
a system publicly available. This means that many people can
propose changes and improvements to the software.
q Quality software is usable.
Chapter 7 Design and implementation 545

28