Design and implementation

 Software design and implementation is the stage in the software engineering process
at which an executable software system is developed.
 Software design is a creative activity in which you identify software components and
their relationships, based on a customer’s requirements.
 Implementation is the process of realizing the design as a program.
Build or buy
 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.
 For example, if you want to implement a medical records system, you can buy
a package that is already used in hospitals. It can be cheaper and faster to use
this approach rather than developing a system in a conventional
programming language.
 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.
Process stages
 There are a variety of different object-oriented design processes that depend on the
organization using the process.
 Common activities in these processes include:
 Define the context and modes of use of the system;
 Design the system architecture;
 Identify the principal system objects;
 Develop design models;
 Specify object interfaces.
 Process illustrated here using a design for a wilderness weather station.
System context and interactions
 Understanding the relationships between the software that is being designed and its
external environment is essential for deciding how to provide the required system
functionality and how to structure the system to communicate with its environment.
 Understanding of the context also lets you establish the boundaries of the system.
Setting the system boundaries helps you decide what features are implemented in
the system being designed and what features are in other associated systems.
Architectural design
 Once interactions between the system and its environment have been understood,
you use this information for designing the system architecture.
 You identify the major components that make up the system and their interactions,
and then may organize the components using an architectural pattern such as a
layered or client-server model.
 The weather station is composed of independent subsystems that communicate by
broadcasting messages on a common infrastructure.

Design models
 Design models show the objects and object classes and relationships between these
entities.
 There are two kinds of design model:
 Structural models describe the static structure of the system in terms of
object classes and relationships.
 Dynamic models describe the dynamic interactions between objects.
Examples
 Subsystem models that show logical groupings of objects into coherent subsystems.
 Sequence models that show the sequence of object interactions.
 State machine models that show how individual objects change their state in
response to events.
 Other models include use-case models, aggregation models, generalisation models,
etc.

Sequence models
 Sequence models show the sequence of object interactions that take place
 Objects are arranged horizontally across the top;
 Time is represented vertically so models are read top to bottom;
 Interactions are represented by labelled arrows, Different styles of arrow
represent different types of interaction;
  A thin rectangle in an object lifeline represents the time when the object is
the controlling object in the system.
Implementation issues
 Focus here is not on programming, although this is obviously important, but on other
implementation issues that are often not covered in programming texts:
 Reuse Most modern software is constructed by reusing existing components
or systems. When you are developing software, you should make as much use
as possible of existing code.
 Configuration management During the development process, you have to
keep track of the many different versions of each software component in a
configuration management system.
 Host-target development Production software does not usually execute on
the same computer as the software development environment. Rather, you
develop it on one computer (the host system) and execute it on a separate
computer (the target system).
Reuse levels
 The abstraction level
 At this level, you don’t reuse software directly but use knowledge of
successful abstractions in the design of your software.
 The object level
 At this level, you directly reuse objects from a library rather than writing the
code yourself.
 The component level
 Components are collections of objects and object classes that you reuse in
application systems.
 The system level
 At this level, you reuse entire application systems.
Open source development
 Open source development is an approach to software development in which the
source code of a software system is published and volunteers are invited to
participate in the development process
 Its roots are in the Free Software Foundation (www.fsf.org), which advocates that
source code should not be proprietary but rather should always be available for users
to examine and modify as they wish.
 Open source software extended this idea by using the Internet to recruit a much
larger population of volunteer developers. Many of them are also users of the code.
 The best-known open source product is, of course, the Linux operating system which
is widely used as a server system and, increasingly, as a desktop environment.
 Other important open source products are Java, the Apache web server and the
mySQL database management system.

License models
 The GNU General Public License (GPL). 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.
 The GNU Lesser General Public License (LGPL) is a variant of the GPL license where
you can write components that link to open source code without having to publish
the source of these components.
 The Berkley Standard Distribution (BSD) License. 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.
CHP 8
Program testing
 Testing is intended to show that a program does what it is intended to do and to
discover program defects before it is put into use.
 When you test software, you execute a program using artificial data.
 You check the results of the test run for errors, anomalies or information about the
program’s non-functional attributes.
 Can reveal the presence of errors NOT their absence.
 Testing is part of a more general verification and validation process, which also
includes static validation techniques.
Verification vs validation
 Verification:
"Are we building the product right”.
 The software should conform to its specification.
 Validation:
"Are we building the right product”.
 The software should do what the user really requires.
V & V confidence
 Aim of V & V is to establish confidence that the system is ‘fit for purpose’.
 Depends on system’s purpose, user expectations and marketing environment
 Software purpose
• The level of confidence depends on how critical the software is to an
organisation.
 User expectations
• Users may have low expectations of certain kinds of software.
 Marketing environment
• Getting a product to market early may be more important than finding
defects in the program.
Inspections and testing
 Software inspections Concerned with analysis of
the static system representation to discover problems(static verification)
 May be supplement by tool-based document and code analysis.
  Discussed in Chapter 15.
 Software testing Concerned with exercising and
observing product behaviour (dynamic verification)
 The system is executed with test data and its operational behaviour is
observed.

Advantages of inspections
 During testing, errors can mask (hide) other errors. Because inspection is a static
process, you don’t have to be concerned with interactions between errors.
 Incomplete versions of a system can be inspected without additional costs. If a
program is incomplete, then you need to develop specialized test harnesses to test
the parts that are available.
 As well as searching for program defects, an inspection can also consider broader
quality attributes of a program, such as compliance with standards, portability and
maintainability.
Inspections and testing
 Inspections and testing are complementary and not opposing verification techniques.
 Both should be used during the V & V process.
 Inspections can check conformance with a specification but not conformance with
the customer’s real requirements.
 Inspections cannot check non-functional characteristics such as performance,
usability, etc.
A model of the software testing process
Stages of testing
 Development testing, where the system is tested during development to discover
bugs and defects.
 Release testing, where a separate testing team test a complete version of the system
before it is released to users.
 User testing, where users or potential users of a system test the system in their own
environment.
Development testing
 Development testing includes all testing activities that are carried out by the team
developing the system.
 Unit testing, where individual program units or object classes are tested. Unit
testing should focus on testing the functionality of objects or methods.
 Component testing, where several individual units are integrated to create
composite components. Component testing should focus on testing
component interfaces.
 System testing, where some or all of the components in a system are
integrated and the system is tested as a whole. System testing should focus
on testing component interactions.
Release testing
 Release testing is the process of testing a particular release of a system that is
intended for use outside of the development team.
 The primary goal of the release testing process is to convince the supplier of the
system that it is good enough for use.
 Release testing, therefore, has to show that the system delivers its specified
functionality, performance and dependability, and that it does not fail during
normal use.
 Release testing is usually a black-box testing process where tests are only derived
from the system specification.
User testing
 User or customer testing is a stage in the testing process in which users or customers
provide input and advice on system testing.
 User testing is essential, even when comprehensive system and release testing have
been carried out.
  The reason for this is that influences from the user’s working environment
have a major effect on the reliability, performance, usability and robustness
of a system. These cannot be replicated in a testing environment.

Types of user testing

 Alpha testing
 Users of the software work with the development team to test the software
at the developer’s site.
 Beta testing
 A release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system
developers.
 Acceptance testing
 Customers test a system to decide whether or not it is ready to be accepted
from the system developers and deployed in the customer environment.
Primarily for custom systems.

Testing strategies
 Partition testing, where you identify groups of inputs that have common
characteristics and should be processed in the same way.
 You should choose tests from within each of these groups.
 Guideline-based testing, where you use testing guidelines to choose test cases.
 These guidelines reflect previous experience of the kinds of errors that
programmers often make when developing components.
Partition testing
 Input data and output results often fall into different classes where all members of a
class are related.
 Each of these classes is an equivalence partition or domain where the program
behaves in an equivalent way for each class member.
 Test cases should be chosen from each partition.
Unit testing
 Unit testing is the process of testing individual components in isolation.
 It is a defect testing process.
  Units may be:
 Individual functions or methods within an object
 Object classes with several attributes and methods
 Composite components with defined interfaces used to access their
functionality.

Component testing
 Software components are often composite components that are made up of several
interacting objects.
 For example, in the weather station system, the reconfiguration component
includes objects that deal with each aspect of the reconfiguration.
 You access the functionality of these objects through the defined component
interface.
 Testing composite components should therefore focus on showing that the
component interface behaves according to its specification.
 You can assume that unit tests on the individual objects within the
component have been completed.
CHP 9
A spiral model of development and evolution

The software evolution process

Legacy systems
 Legacy systems are older systems that rely on languages and technology that are no
longer used for new systems development.
 Legacy software may be dependent on older hardware, such as mainframe
computers and may have associated legacy processes and procedures.
 Legacy systems are not just software systems but are broader socio-technical systems
that include hardware, software, libraries and other supporting software and
business processes.
The elements of a legacy system

Figure 9.13 An example of a legacy system assessment

Legacy system categories

 Low quality, low business value
 These systems should be scrapped.
  Low-quality, high-business value
 These make an important business contribution but are expensive to
maintain. Should be re-engineered or replaced if a suitable system is
available.
 High-quality, low-business value
 Replace with COTS, scrap completely or maintain.
 High-quality, high business value
 Continue in operation using normal system maintenance.
Software maintenance
 Modifying a program after it has been put into use.
 The term is mostly used for changing custom software. Generic software products
are said to evolve to create new versions.
 Maintenance does not normally involve major changes to the system’s architecture.
 Changes are implemented by modifying existing components and adding new
components to the system.
Types of maintenance
 Fault repairs
 Changing a system to fix bugs/vulnerabilities and correct deficiencies in the
way meets its requirements.
 Environmental adaptation
 Maintenance to adapt software to a different operating environment
 Changing a system so that it operates in a different environment (computer,
OS, etc.) from its initial implementation.
 Functionality addition and modification
 Modifying the system to satisfy new requirements.
Software reengineering
 Restructuring or rewriting part or all of a
legacy system without changing its
functionality.
 Applicable where some but not all sub-systems
of a larger system require frequent
maintenance.
 Reengineering involves adding effort to make
them easier to maintain. The system may be re-structured and re-documented.
Advantages of reengineering
 Reduced risk
 There is a high risk in new software development. There may be development
problems, staffing problems and specification problems.
 Reduced cost
 The cost of re-engineering is often significantly less than the costs of
developing new software.
CHP 10
The principal dependability properties

Principal properties
 Availability
 The probability that the system will be up and running and able to deliver
useful services to users.
 Reliability
 The probability that the system will correctly deliver services as expected by
users.
 Safety
 A judgment of how likely it is that the system will cause damage to people or
its environment.
 Security
 A judgment of how likely it is that the system can resist accidental or
deliberate intrusions.
 Resilience
 A judgment of how well a system can maintain the continuity of its critical
services in the presence of disruptive events such as equipment failure and
cyberattacks.
 Repairability
 Reflects the extent to which the system can be repaired in the event of a
failure
 Maintainability
 Reflects the extent to which the system can be adapted to new requirements;
 Error tolerance
  Reflects the extent to which user input errors can be avoided and tolerated.

Cost/dependability curve

The sociotechnical systems stack

Layers in the STS stack

 Equipment
 Hardware devices, some of which may be computers. Most devices will
include an embedded system of some kind.
 Operating system
  Provides a set of common facilities for higher levels in the system.
 Communications and data management
 Middleware that provides access to remote systems and databases.
 Application systems
 Specific functionality to meet some organization requirements.
 Business processes
 A set of processes involving people and computer systems that support the
activities of the business.
 Organizations
 Higher level strategic business activities that affect the operation of the
system.
 Society
 Laws, regulation and culture that affect the operation of the system.
CHP 13
CHP 15
COTS-solution and COTS-integrated systems

CHP 17
Distributed systems
 Virtually all large computer-based systems are now distributed systems.
“… a collection of independent computers that appears to the user as a single coherent
system.”
 Information processing is distributed over several computers rather than confined to
a single machine.
 Distributed software engineering is therefore very important for enterprise
computing systems.
Distributed system characteristics
 Resource sharing
 Sharing of hardware and software resources.
 Openness
 Use of equipment and software from different vendors.
 Concurrency
 Concurrent processing to enhance performance.
 Scalability
 Increased throughput by adding new resources.
 Fault tolerance
 The ability to continue in operation after a fault has occurred.
Distributed systems issues
 Distributed systems are more complex than systems that run on a single processor.
 Complexity arises because different parts of the system are independently managed
as is the network.
 There is no single authority in charge of the system so top-down control is
impossible.
Design issues
 Transparency To what extent should the distributed system appear to the user as a
single system?
 Openness Should a system be designed using standard protocols that support
interoperability?
 Scalability How can the system be constructed so that it is scaleable?
 Security How can usable security policies be defined and implemented?
 Quality of service How should the quality of service be specified.
 Failure management How can system failures be detected, contained and repaired?
Transparency
 Ideally, users should not be aware that a system is distributed and services should be
independent of distribution characteristics.
 In practice, this is impossible because parts of the system are independently
managed and because of network delays.
 Often better to make users aware of distribution so that they can cope with
problems
 To achieve transparency, resources should be abstracted and addressed logically
rather than physically. Middleware maps logical to physical resources.

Openness
 Open distributed systems are systems that are built according to generally accepted
standards.
 Components from any supplier can be integrated into the system and can inter-
operate with the other system components.
 Openness implies that system components can be independently developed in any
programming language and, if these conform to standards, they will work with other
components.
  Web service standards for service-oriented architectures were developed to be open
standards.
Scalability
 The scalability of a system reflects its ability to deliver a high quality service as
demands on the system increase
 Size It should be possible to add more resources to a system to cope with
increasing numbers of users.
 Distribution It should be possible to geographically disperse the components
of a system without degrading its performance.
 Manageability It should be possible to manage a system as it increases in size,
even if parts of the system are located in independent organizations.
 There is a distinction between scaling-up and scaling-out. Scaling up is more powerful
system; scaling out is more system instances.
Quality of service
 The quality of service (QoS) offered by a distributed system reflects the system’s
ability to deliver its services dependably and with a response time and throughput
that is acceptable to its users.
 Quality of service is particularly critical when the system is dealing with time-critical
data such as sound or video streams.
 In these circumstances, if the quality of service falls below a threshold value
then the sound or video may become so degraded that it is impossible to
understand.
Failure management
 In a distributed system, it is inevitable that failures will occur, so the system has to be
designed to be resilient to these failures.
“You know that you have a distributed system when the crash of
a system that you’ve never heard of stops you getting any work done.”
 Distributed systems should include mechanisms for discovering if a component of the
system has failed, should continue to deliver as many services as possible in spite of
that failure and, as far as possible, automatically recover from the failure.

Security
 When a system is distributed, the number of ways that the system may be attacked is
significantly increased, compared to centralized systems.
  If a part of the system is successfully attacked then the attacker may be able to use
this as a ‘back door’ into other parts of the system.
 Difficulties in a distributed system arise because different organizations may own
parts of the system. These organizations may have mutually incompatible security
policies and security mechanisms.

Types of attack
 The types of attack that a distributed system must defend itself against are:
 Interception, where communications between parts of the system are
intercepted by an attacker so that there is a loss of confidentiality.
 Interruption, where system services are attacked and cannot be delivered as
expected.
• Denial of service attacks involve bombarding a node with illegitimate
service requests so that it cannot deal with valid requests.
 Modification, where data or services in the system are changed by an
attacker.
 Fabrication, where an attacker generates information that should not exist
and then uses this to gain some privileges.
Models of interaction
 Two types of interaction between components in a distributed system
 Procedural interaction, where one computer calls on a known service offered
by another computer and waits for a response.
 Message-based interaction, involves the sending computer sending
information about what is required to another computer. There is no
necessity to wait for a response.

Remote procedure calls

 Procedural communication in a distributed system is implemented using remote
procedure calls (RPC).
 In a remote procedure call, one component calls another component as if it was a
local procedure or method. The middleware in the system intercepts this call and
passes it to a remote component.
 This carries out the required computation and, via the middleware, returns the result
to the calling component.
  A problem with RPCs is that the caller and the callee need to be available at the time
of the communication, and they must know how to refer to each other.
Message passing
 Message-based interaction normally involves one component creating a message
that details the services required from another component.
 Through the system middleware, this is sent to the receiving component.
 The receiver parses the message, carries out the computations and creates a
message for the sending component with the required results.
 In a message-based approach, it is not necessary for the sender and receiver of the
message to be aware of each other. They simple communicate with the middleware.
Middleware
 The components in a distributed system may be implemented in different
programming languages and may execute on completely different types of processor.
Models of data, information representation and protocols for communication may all
be different.
 Middleware is software that can manage these diverse parts, and ensure that they
can communicate and exchange data.
Client-server computing
 Distributed systems that are accessed over the Internet are normally organized as
client-server systems.
 In a client-server system, the user interacts with a program running on their local
computer (e.g. a web browser or mobile application). This interacts with another
program running on a remote computer (e.g. a web server).
 The remote computer provides services, such as access to web pages, which are
available to external clients.
Two-tier client server architectures
 In a two-tier client-server architecture, the system is implemented as a single logical
server plus an indefinite number of clients that use that server.
 Thin-client model, where the presentation layer is implemented on the client
and all other layers (data management, application processing and database)
are implemented on a server.
 Fat-client model, where some or all of the application processing is carried
out on the client. Data management and database functions are implemented
on the server.
Multi-tier client-server architectures
  In a ‘multi-tier client–server’ architecture, the different layers of the system, namely
presentation, data management, application processing, and database, are separate
processes that may execute on different processors.
 This avoids problems with scalability and performance if a thin-client two-tier model
is chosen, or problems of system management if a fat-client model is used.

Thin client model

 Used when legacy systems are migrated to client server architectures.
 The legacy system acts as a server in its own right with a graphical interface
implemented on a client.
 A major disadvantage is that it places a heavy processing load on both the server and
the network.
Fat client model
 More processing is delegated to the client as the application processing is locally
executed.
 Most suitable for new C/S systems where the capabilities of the client system are
known in advance.
 More complex than a thin client model especially for management. New versions of
the application have to be installed on all clients.
P2p architectural models
 The logical network architecture
 Decentralised architectures;
 Semi-centralised architectures.
 Application architecture
 The generic organisation of components making up a p2p application.
 Focus here on network architectures.

A decentralized p2p architecture

A semicentralized p2p architecture

CHP 22
Software project management
 Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
 Project management is needed because software development is always subject to
budget and schedule constraints that are set by the organisation developing the
software.
Factors influencing project management
 Company size
 Software customers
 Software size
 Software type
 Organizational culture
 Software development processes
  These factors mean that project managers in different organizations may work in
quite different ways.
Risk management
 Risk management is concerned with identifying risks and drawing up plans to
minimise their effect on a project.
 Software risk management is important because of the inherent uncertainties in
software development.
 These uncertainties stem from loosely defined requirements, requirements
changes due to changes in customer needs, difficulties in estimating the time
and resources required for software development, and differences in
individual skills.
 You have to anticipate risks, understand the impact of these risks on the project, the
product and the business, and take steps to avoid these risks.
The risk management process
 Risk identification
 Identify project, product and business risks;
 Risk analysis
 Assess the likelihood and consequences of these risks;
 Risk planning
 Draw up plans to avoid or minimise the effects of the risk;
 Risk monitoring
 Monitor the risks throughout the project;
Examples of different risk types

Strategies to help manage risk