Ch7-9 Compressed Discussion

SOFTWARE ENGINEERING:
IMPLEMENTATION, TESTING AND

EVOLUTION
A COMPREHENSIVE LECTURE
1
CHAPTER 7 – DESIGN AND IMPLEMENTATION
Object-oriented design using the UML

Design patterns
Implementation issues
Open source development
30/10/2014 Chapter 7 Design and Implementation 2

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 and implementation activities are invariably
inter-leaved.

An object-oriented design process
■ Structured object-oriented design processes involve

developing a number of different system models.
■ They require a lot of effort for development and maintenance
of these models and, for small systems, this may not be cost-
effective.
■ However, for large systems developed by different groups
design models are an important communication mechanism.

Process stages
■ 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

1. 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.
■ A system context model is a structural model that
demonstrates the other systems in the environment of the
system being developed.
■ An interaction model is a dynamic model that shows how the
system interacts with its environment as it is used.

System context and Use Case for the weather station

2. Architectural design
■ Once interactions between the system and its
environment have been understood, you use this
information for designing the system architecture.

3. Object class identification
■ Identifying object classes is often a difficult part of object

oriented design.
– Use a grammatical approach based on a natural
language description of the system.
– Base the identification on tangible things in the
application domain.
– Use a behavioural approach and identify objects based
on what participates in what behaviour.
– Use a scenario-based analysis. The objects, attributes
and methods in each scenario are identified.

Weather station object classes

4. 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 of design models
■ 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 diagram describing
data collection

Weather station state
diagram

5. Interface specification
■ Object interfaces have to be specified so
that the objects and other components
can be designed in parallel.
■ Designers should avoid designing the
interface representation but should hide
this in the object itself.
■ Objects may have several interfaces
which are viewpoints on the methods
provided.
■ The UML uses class diagrams for
interface specification but Java may also
be used.

Design patterns

Design patterns
■ A design pattern is a way of reusing abstract knowledge about

a problem and its solution.
■ A pattern is a description of the problem and the essence of
its solution.
“Patterns and Pattern Languages are ways to describe best

practices, good designs, and capture experience in a way that it
is possible for others to reuse this experience.”

Pattern elements
■ Name
– A meaningful pattern identifier.
■ Problem description.
■ Solution description.
– Not a concrete design but a template for a design
solution that can be instantiated in different ways.
■ Consequences
– The results and trade-offs of applying the pattern.

Design problems
■ To use patterns in your design, you need to recognize that any

design problem you are facing may have an associated pattern
that can be applied.
– Tell several objects that the state of some other object has
changed (Observer pattern).
– Tidy up the interfaces to a number of related objects that
have often been developed incrementally (Façade pattern).
– Provide a standard way of accessing the elements in a
collection, irrespective of how that collection is
implemented (Iterator pattern).
– Allow for the possibility of extending the functionality of an
existing class at run-time (Decorator pattern).


■ 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).

Software reuse

Reuse costs
■ The costs of the time spent in looking for software to reuse

and assessing whether or not it meets your needs.
■ Where applicable, the costs of buying the reusable software.
For large off-the-shelf systems, these costs can be very high.
■ The costs of adapting and configuring the reusable software
components or systems to reflect the requirements of the
system that you are developing.
■ 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.

Configuration management
■ Configuration management is the name given to the general

process of managing a changing software system.
– Version management
– System integration
– Problem tracking

Host-target development
■ Most software is developed on one computer (the host), but runs

on a separate machine (the target).
■ More generally, we can talk about a development platform and
an execution platform.
– A platform is more than just hardware.
– It includes the installed operating system plus other
supporting software such as a database management
system or, for development platforms, an interactive
development environment.
■ Development platform usually has different installed software
than execution platform; these platforms may have different
architectures.

Development platform tools
and IDEs
■ A language debugging system.
■ Graphical editing tools, such as tools to edit UML models.
■ Testing tools, such as Junit that can automatically run a set of
tests on a new version of a program.
■ Project support tools that help you organize the code for
different development projects.
■ Software development tools are often grouped to create an

integrated development environment (IDE).


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

Open source issues
■ Should the product that is being developed make use of open

source components?
■ Should an open source approach be used for the software’s
development?

Open source licensing
■ A 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.
– GNU General Public License (GPL)
– GNU Lesser General Public License (LGPL)
– Berkley Standard Distribution (BSD) License

CHAPTER 8 – SOFTWARE TESTING
Development testing
Test-driven development
Release testing
User testing
30/10/2014 Chapter 8 Software Testing 31

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.

Program testing goals
■ To demonstrate to the developer and the customer that the

software meets its requirements.
– Validation testing
■ To discover situations in which the behavior of the software is
incorrect, undesirable or does not conform to its specification.
– Defect testing

Testing process goals
■ Validation testing
– To demonstrate to the developer and the system customer
that the software meets its requirements
– A successful test shows that the system operates as
intended.
■ Defect testing
– To discover faults or defects in the software where its
behaviour is incorrect or not in conformance with its
specification
– A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

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.

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.
■ Software testing Concerned with exercising and
observing product behaviour (dynamic verification)
– The system is executed with test data and its operational
behaviour is observed.

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.

Automated testing
■ Whenever possible, unit testing should be automated so that

tests are run and checked without manual intervention.
■ In automated unit testing, you make use of a test automation
framework (such as JUnit) to write and run your program tests.
– A setup part, where you initialize the system with the test
case, namely the inputs and expected outputs.
– A call part, where you call the object or method to be
tested.
– An assertion part where you compare the result of the call
with the expected result. If the assertion evaluates to true,
the test has been successful if false, then it has failed.

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.

General testing guidelines
■ Choose inputs that force the system to generate all error

messages
■ Design inputs that cause input buffers to overflow
■ Repeat the same input or series of inputs numerous times
■ Force invalid outputs to be generated
■ Force computation results to be too large or too small.

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.

Interface testing
■ Objectives are to detect faults due to interface errors or

invalid assumptions about interfaces.
■ Interface types
– Parameter interfaces Data passed from one method or
procedure to another.
– Shared memory interfaces Block of memory is shared
between procedures or functions.
– Procedural interfaces Sub-system encapsulates a set of
procedures to be called by other sub-systems.
– Message passing interfaces Sub-systems request
services from other sub-systems

Interface errors
■ Interface misuse
– A calling component calls another component and makes
an error in its use of its interface e.g. parameters in the
wrong order.
■ Interface misunderstanding
– A calling component embeds assumptions about the
behaviour of the called component which are incorrect.
■ Timing errors
– The called and the calling component operate at different
speeds and out-of-date information is accessed.

System testing
■ System testing during development involves integrating

components to create a version of the system and then
testing the integrated system.
■ The focus in system testing is testing the interactions between
components.
■ System testing checks that components are compatible,
interact correctly and transfer the right data at the right time
across their interfaces.
■ System testing tests the emergent behaviour of a system.


■ Test-driven development (TDD) is an approach to program

development in which you inter-leave testing and code
development.
■ Tests are written before code and ‘passing’ the tests is the
critical driver of development.
■ You develop code incrementally, along with a test for that
increment. You don’t move on to the next increment until the
code that you have developed passes its test.
■ TDD was introduced as part of agile methods such as
Extreme Programming. However, it can also be used in plan-
driven development processes.


TDD process activities
■ Start by identifying the increment of functionality that is

required. This should normally be small and implementable in
a few lines of code.
■ Write a test for this functionality and implement this as an
automated test.
■ Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
■ Implement the functionality and re-run the test.
■ Once all tests run successfully, you move on to implementing
the next chunk of functionality.

Benefits of test-driven
development
■ Code coverage
■ Regression testing
■ Simplified debugging
■ System documentation

Regression testing
■ Regression testing is testing the system to check that

changes have not ‘broken’ previously working code.
■ In a manual testing process, regression testing is expensive
but, with automated testing, it is simple and straightforward.
All tests are rerun every time a change is made to the
program.
■ Tests must run ‘successfully’ before the change is committed.

Release testing

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.

Requirements based testing
■ Requirements-based testing involves examining each

requirement and developing a test or tests for it.
■ Mentcare system requirements:
– If a patient is known to be allergic to any particular
medication, then prescription of that medication shall
result in a warning message being issued to the system
user.
– If a prescriber chooses to ignore an allergy warning, they
shall provide a reason why this has been ignored.

Performance testing
■ Part of release testing may involve testing the emergent

properties of a system, such as performance and reliability.
■ Tests should reflect the profile of use of the system.
■ Performance tests usually involve planning a series of tests
where the load is steadily increased until the system
performance becomes unacceptable.
■ Stress testing is a form of performance testing where the
system is deliberately overloaded to test its failure behaviour.

User testing

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.

Stages in the acceptance
testing process
■ Define acceptance criteria
■ Plan acceptance testing
■ Derive acceptance tests
■ Run acceptance tests
■ Negotiate test results
■ Reject/accept system

Agile methods and
acceptance testing
■ In agile methods, the user/customer is part of the
development team and is responsible for making decisions on
the acceptability of the system.
■ Tests are defined by the user/customer and are integrated
with other tests in that they are run automatically when
changes are made.
■ There is no separate acceptance testing process.
■ Main problem here is whether or not the embedded user is
‘typical’ and can represent the interests of all system
stakeholders.

CHAPTER 9 – SOFTWARE EVOLUTION
Evolution processes
Legacy systems
Software maintenance
30/10/2014 Chapter 9 Software Evolution 62

Software change
■ Software change is inevitable

– New requirements emerge when the software is used;
– The business environment changes;
– Errors must be repaired;
– New computers and equipment is added to the system;
– The performance or reliability of the system may have to
be improved.
■ A key problem for all organizations is implementing
and managing change to their existing software
systems.

Importance of evolution
■ Organisations have huge investments in their software

systems - they are critical business assets.
■ To maintain the value of these assets to the business, they
must be changed and updated.
■ The majority of the software budget in large companies is
devoted to changing and evolving existing software rather
than developing new software.

Evolution and servicing
■ Evolution
– The stage in a software system’s life cycle where it is in
operational use and is evolving as new requirements are
proposed and implemented in the system.
■ Servicing
– At this stage, the software remains useful but the only
changes made are those required to keep it operational i.e.
bug fixes and changes to reflect changes in the software’s
environment. No new functionality is added.
■ Phase-out
– The software may still be used but no further changes are
made to it.

Evolution processes

Evolution processes
■ Software evolution processes depend on

– The type of software being maintained;
– The development processes used;
– The skills and experience of the people involved.
■ Proposals for change are the driver for system evolution.
– Should be linked with components that are affected by
the change, thus allowing the cost and impact of the
change to be estimated.
■ Change identification and evolution continues throughout the
system lifetime.

Change identification and
evolution processes

The software evolution
process

Change implementation

The emergency repair
process

Agile methods and evolution
■ Agile methods are based on incremental development so the

transition from development to evolution is a seamless one.
– Evolution is simply a continuation of the development
process based on frequent system releases.
■ Automated regression testing is particularly valuable when
changes are made to a system.
■ Changes may be expressed as additional user stories.

Handover problems
■ Where the development team have used an agile approach but

the evolution team is unfamiliar with agile methods and prefer a
plan-based approach.
– The evolution team may expect detailed documentation to
support evolution and this is not produced in agile
processes.
■ Where a plan-based approach has been used for development
but the evolution team prefer to use agile methods.
– The evolution team may have to start from scratch
developing automated tests and the code in the system
may not have been refactored and simplified as is expected
in agile development.

Legacy systems

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.

Legacy system components
■ System hardware
■ Support software
■ Application software
■ Application data
■ Business processes
■ Business policies and rules

Legacy system replacement
■ Legacy system replacement is risky and expensive so

businesses continue to use these systems
■ System replacement is risky for a number of reasons
– Lack of complete system specification
– Tight integration of system and business processes
– Undocumented business rules embedded in the legacy
system
– New software development may be late and/or over
budget

Legacy system change
■ Legacy systems are expensive to change for a number of

reasons:
– No consistent programming style
– Use of obsolete programming languages with few people
available with these language skills
– Inadequate system documentation
– System structure degradation
– Program optimizations may make them hard to
understand
– Data errors, duplication and inconsistency

Legacy system management
■ Organisations that rely on legacy systems must

choose a strategy for evolving these systems
– Scrap the system completely and modify business
processes so that it is no longer required;
– Continue maintaining the system;
– Transform the system by re-engineering to improve its
maintainability;
– Replace the system with a new system.
■ The strategy chosen should depend on the system
quality and its business value.

Issues in business value
assessment
■ The use of the system
– If systems are only used occasionally or by a small number of
people, they may have a low business value.
■ The business processes that are supported
– A system may have a low business value if it forces the use of
inefficient business processes.
■ System dependability
– If a system is not dependable and the problems directly affect
business customers, the system has a low business value.
■ The system outputs
– If the business depends on system outputs, then the system has a
high business value.
System quality assessment
■ Business process assessment

– How well does the business process support the current
goals of the business?
■ Environment assessment
– How effective is the system’s environment and how
expensive is it to maintain?
■ Application assessment
– What is the quality of the application software system?

Factors used in environment
assessment
Factor Questions
Supplier stability Is the supplier still in existence? Is the supplier financially
stable and likely to continue in existence? If the supplier is
no longer in business, does someone else maintain the
systems?
Failure rate Does the hardware have a high rate of reported failures?
Does the support software crash and force system
restarts?
Age How old is the hardware and software? The older the
hardware and support software, the more obsolete it will
be. It may still function correctly but there could be
significant economic and business benefits to moving to a
more modern system.
Performance Is the performance of the system adequate? Do
performance problems have a significant effect on system
users?

Factors used in environment
assessment
Factor Questions
Support requirements What local support is required by the hardware and

software? If there are high costs associated with this
support, it may be worth considering system replacement.
Maintenance costs What are the costs of hardware maintenance and support
software licences? Older hardware may have higher
maintenance costs than modern systems. Support software
may have high annual licensing costs.
Interoperability Are there problems interfacing the system to other systems?
Can compilers, for example, be used with current versions
of the operating system? Is hardware emulation required?

Factors used in application
assessment
Factor Questions
Understandability How difficult is it to understand the source code of the current
system? How complex are the control structures that are used?
Do variables have meaningful names that reflect their function?
Documentation What system documentation is available? Is the documentation
complete, consistent, and current?
Data Is there an explicit data model for the system? To what extent is
data duplicated across files? Is the data used by the system up to
date and consistent?
Performance Is the performance of the application adequate? Do performance
problems have a significant effect on system users?

Factors used in application
assessment
Factor Questions
Programming language Are modern compilers available for the programming

language used to develop the system? Is the programming
language still used for new system development?
Configuration Are all versions of all parts of the system managed by a
management configuration management system? Is there an explicit
description of the versions of components that are used in
the current system?
Test data Does test data for the system exist? Is there a record of
regression tests carried out when new features have been
added to the system?
Personnel skills Are there people available who have the skills to maintain the
application? Are there people available who have experience
with the system?

System measurement
■ You may collect quantitative data to make an assessment of the

quality of the application system
– The number of system change requests; The higher this
accumulated value, the lower the quality of the system.
– The number of different user interfaces used by the system;
The more interfaces, the more likely it is that there will be
inconsistencies and redundancies in these interfaces.
– The volume of data used by the system. As the volume of
data (number of files, size of database, etc.) processed by
the system increases, so too do the inconsistencies and
errors in that data.
– Cleaning up old data is a very expensive and time-
consuming process


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

Maintenance effort
distribution

Maintenance costs
■ Usually greater than development costs (2* to

100* depending on the application).
■ Affected by both technical and non-technical
factors.
■ Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
■ Ageing software can have high support costs
(e.g. old languages, compilers etc.).

Maintenance prediction

Change prediction
■ Predicting the number of changes requires and

understanding of the relationships between a
system and its environment.
■ Tightly coupled systems require changes whenever
the environment is changed.
■ Factors influencing this relationship are
– Number and complexity of system interfaces;
– Number of inherently volatile system requirements;
– The business processes where the system is used.

Complexity metrics
■ Predictions of maintainability can be made by

assessing the complexity of system components.
■ Studies have shown that most maintenance effort
is spent on a relatively small number of system
components.
■ Complexity depends on
– Complexity of control structures;
– Complexity of data structures;
– Object, method (procedure) and module size.

Process metrics
■ Process metrics may be used to assess maintainability

– Number of requests for corrective maintenance;
– Average time required for impact analysis;
– Average time taken to implement a change request;
– Number of outstanding change requests.
■ If any or all of these is increasing, this may indicate a decline
in maintainability.

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.

Reengineering process
activities
■ Source code translation
– Convert code to a new language.
■ Reverse engineering
– Analyse the program to understand it;
■ Program structure improvement
– Restructure automatically for understandability;
■ Program modularisation
– Reorganise the program structure;
■ Data reengineering
– Clean-up and restructure system data.

Reengineering cost factors
■ The quality of the software to be reengineered.

■ The tool support available for reengineering.
■ The extent of the data conversion which is required.
■ The availability of expert staff for reengineering.
– This can be a problem with old systems based on
technology that is no longer widely used.

Refactoring and
reengineering
■ Re-engineering takes place after a system has been
maintained for some time and maintenance costs are
increasing. You use automated tools to process and re-
engineer a legacy system to create a new system that is more
maintainable.
■ Refactoring is a continuous process of improvement
throughout the development and evolution process. It is
intended to avoid the structure and code degradation that
increases the costs and difficulties of maintaining a system.

‘Bad smells’ in program code
■ Duplicate code
■ Long methods
■ Switch (case) statements
■ Data clumping
■ Speculative generality

THANK YOU!
Questions?
30/10/2014 100

Ch7-9 Compressed Discussion

Uploaded by

Copyright:

Available Formats

You might also like

Ch7-9 Compressed Discussion

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch7-9 Compressed Discussion

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING:

IMPLEMENTATION, TESTING AND

Object-oriented design using the UML

30/10/2014 Chapter 7 Design and Implementation 2

■ Software design and implementation is the stage in the

30/10/2014 Chapter 7 Design and Implementation 3

■ Structured object-oriented design processes involve

30/10/2014 Chapter 7 Design and Implementation 4

■ Define the context and modes of use of the system

30/10/2014 Chapter 7 Design and Implementation 5

30/10/2014 Chapter 7 Design and Implementation 6

30/10/2014 Chapter 7 Design and Implementation 7

30/10/2014 Chapter 7 Design and Implementation 8

■ Identifying object classes is often a difficult part of object

30/10/2014 Chapter 7 Design and Implementation 9

30/10/2014 Chapter 7 Design and Implementation 10

■ Design models show the objects and object classes and

30/10/2014 Chapter 7 Design and Implementation 11

■ Subsystem models that show logical groupings of

30/10/2014 Chapter 7 Design and Implementation 12

30/10/2014 Chapter 7 Design and Implementation 13

30/10/2014 Chapter 7 Design and Implementation 14

30/10/2014 Chapter 7 Design and Implementation 15

30/10/2014 Chapter 7 Design and Implementation 16

■ A design pattern is a way of reusing abstract knowledge about

“Patterns and Pattern Languages are ways to describe best

30/10/2014 Chapter 7 Design and Implementation 17

30/10/2014 Chapter 7 Design and Implementation 18

■ To use patterns in your design, you need to recognize that any

30/10/2014 Chapter 7 Design and Implementation 19

30/10/2014 Chapter 7 Design and Implementation 20

■ Focus here is not on programming, although this is obviously important,

30/10/2014 Chapter 7 Design and Implementation 21

30/10/2014 Chapter 7 Design and Implementation 22

■ The costs of the time spent in looking for software to reuse

30/10/2014 Chapter 7 Design and Implementation 23

■ Configuration management is the name given to the general

30/10/2014 Chapter 7 Design and Implementation 24

■ Most software is developed on one computer (the host), but runs

30/10/2014 Chapter 7 Design and Implementation 25

■ Software development tools are often grouped to create an

30/10/2014 Chapter 7 Design and Implementation 26

30/10/2014 Chapter 7 Design and Implementation 27

■ Open source development is an approach to software

30/10/2014 Chapter 7 Design and Implementation 28

■ Should the product that is being developed make use of open

30/10/2014 Chapter 7 Design and Implementation 29

■ A fundamental principle of open-source development is that

30/10/2014 Chapter 7 Design and Implementation 30

30/10/2014 Chapter 8 Software Testing 31

■ Testing is intended to show that a program does what it is

30/10/2014 Chapter 8 Software Testing 32

■ To demonstrate to the developer and the customer that the

30/10/2014 Chapter 8 Software Testing 33

30/10/2014 Chapter 8 Software Testing 34

30/10/2014 Chapter 8 Software Testing 35

30/10/2014 Chapter 8 Software Testing 36

30/10/2014 Chapter 8 Software Testing 37