Software Design and Implementation

 Software design and implementation is the stage in

the software engineering process at which an
executable software system is developed.
 For large systems, software design and
implementation is only one of a set of processes
(requirements engineering, verification and
validation, etc.) involved in software engineering.
 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.
 A design is in the programmer’s head or roughly
sketched on a whiteboard or sheets of paper.
Design and Implementation
 Design and implementation are closely linked
and you should normally take implementation
issues into account when developing a design.
 It can be cheaper and faster to use COTS
approach rather than developing a system in a
conventional programming language.
 COTS design process becomes concerned with
how to use the configuration features of that system
to deliver the system requirements.
 To introduce important implementation issues
that are not usually covered in programming
books. These include software reuse,
configuration management, and open source
development.
Object Oriented Design Using UML
 An object-oriented system is made up of interacting
objects that maintain their own local state and
provide operations on that state.
 Object-oriented design processes involve designing
object classes and the relationships between these
classes.
 When the design is realized as an executing
program, the objects are created dynamically
 from these class definitions.
 Object-oriented systems are easier to change than
systems developed using functional approaches.
 Objects include both data and operations to
manipulate that data.
Remember Following while developing system through UML
 Understand and define the context and the
external interactions with the system.
 Design the system architecture.
 Identify the principal objects in the system.
 Develop design models.
 Specify interfaces.
Object Oriented Design Process
 System Context and Interactions
 Architectural Design
 Object Class identification
 Design Models
 Interface Specification
System Context and Interactions
 It is the process to develop an understanding of the
relationships between the software that is being
designed and its external 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.
 The context model of a system may be represented
using associations.
 Associations simply show that there are some
relationships between the entities involved in the
association. The nature of the relationships is now
specified.
System Context and Interactions
Architectural Design
 System’s environment is used for designing the
system architecture.
 The key benefit of this architecture is that it is easy
to support different configurations of subsystems
because the sender of a message does not need to
address the message to a particular subsystem.
 To design the system, combine general knowledge
of the principles of architectural design and with
more detailed domain knowledge.
 Each subsystem listens for messages on that
infrastructure and picks up the messages that are
intended for them.
Architectural Design of Weather System
Object Class identification
 Use a grammatical analysis of a natural language
description of the system to be constructed.
Objects and attributes are nouns; operations or
services are verbs.
 Use tangible entities (things) in the application
domain such as aircraft, roles such as manager
or doctor, events such as requests, interactions
such as meetings and so on.
 Use a scenario-based analysis where various
scenarios of system use are identified and
analyzed in turn. As each scenario is analyzed,
the team responsible for the analysis must
identify the required objects, attributes, and
operations.
Object Class identification
 Use a grammatical analysis of a natural language
description of the system to be constructed.
Objects and attributes are nouns; operations or
services are verbs.
 Use tangible entities (things) in the application
domain such as aircraft, roles such as manager
or doctor, events such as requests, interactions
such as meetings and so on.
 Use a scenario-based analysis where various
scenarios of system use are identified and
analyzed in turn. As each scenario is analyzed,
the team responsible for the analysis must
identify the required objects, attributes, and
operations.
Design Models
 Design or system models show the objects or
object classes in a system.
 They also show the associations and relationships
between these entities.
 These models are the bridge between the system
requirements and the implementation of a system.
 Design models make close links between
requirements engineers, designers, and
programmers, then abstract models may be all
that are required.
 When the links between system specifies,
designers, and programmers are indirect then
more detailed models are likely to be needed.
Design Models
 Two kinds of UML Design.
 Structural models, which describe the static
structure of the system using object classes and
their relationships.
 Important relationships that may be documented at
this stage are generalization (inheritance)
relationships, uses/used-by relationship, and
composition relationships.
 Dynamic models, which describe the dynamic
structure of the system and show the interactions
between the system objects.
 Interactions that may be documented include the
sequence of service requests made by objects and
the state changes that are triggered by these object
interactions.
Useful models for use case and architectural design
 Subsystem models, which that show logical
groupings of objects into coherent subsystems.
 These are represented using a form of class
diagram with each subsystem shown as a package
with enclosed objects. Subsystem models are static
(structural) models.
 Sequence models, which show the sequence of
object interactions. These are represented using a
UML sequence or a collaboration diagram.
 State machine model, which show how individual
objects change their state in response to events.
These are represented in the UML using state
diagrams. State machine models are dynamic
models.
Interface Specification
 Interface design is concerned with specifying the
detail of the interface to an object or to a group of
objects.
 This means defining the signatures and semantics
of the services that are provided by the object or by
a group of objects.
 Interfaces can be specified in the UML using the
same notation as a class diagram.
 In interface design, include operations to access
and update data.
 The same object may have several interfaces, each
of which is a viewpoint on the methods that it
provides.
 a group of objects may all be accessed through a
single interface.
Design Pattern
 The pattern is a description of the problem and
the essence of its solution, so that the solution
may be reused in different settings.
 The pattern is not a detailed specification.
Rather, you can think of it as a description of
accumulated wisdom and experience, a well-
tried solution to a common problem.
 Patterns have made a huge impact on object-
oriented software design.
 Design patterns are usually associated with
object-oriented design. Published patterns often
rely on object characteristics such as
inheritance and polymorphism to provide
generality.
Design Pattern
 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.
 The general principle of encapsulating
experience in a pattern is one that is equally
applicable to any kind of software design.
 Patterns are a way of reusing the knowledge
and experience of other designers.
Four essential elements of design patterns by
Gang of Four
 A name that is a meaningful reference to the pattern.
 A description of the problem area that explains when
the pattern may be applied.
 A solution description of the parts of the design
solution, their relationships, and responsibilities.
 It is a template for a design solution that can be
instantiated in different ways. This is often expressed
graphically and shows the relationships between the
objects and object classes in the solution.
 A statement of the consequences—the results and
trade-offs—of applying the pattern. This can help
designers understand whether or not a pattern can
be used in a particular situation.
Design Pattern Continue
 Patterns support high-level, concept reuse.
 Design patterns in a design process often involves
developing a design, experiencing a problem, and
then recognizing that a pattern can be used.
 Based on your problem, you may find an
appropriate pattern amongst the hundreds of
different patterns that have been proposed.
 Patterns are a great idea but you need experience
of software design to use them effectively.
 Inexperienced programmers, even if they have read
the pattern books, will always find it hard to decide
whether they can reuse a pattern or need to
develop a special purpose solution.
Implementation Issues
 Implementation is a critical stage of this process
is, of course, system implementation, where you
create an executable version of the software.
 Implementation may involve developing programs
in high- or low-level programming languages or
tailoring and adapting generic, off-the-shelf systems
to meet the specific requirements of an
organization.
 Implementation is intended to offer a language-
independent approach.
Some aspects of Implementation: Reuse
 The abstraction level:
◦ At this level, software is not used directly but
rather use knowledge of successful abstractions
in the design of your software.
◦ Design patterns and architectural patterns are
ways of representing abstract knowledge for
reuse.
 The object level
◦ At this level, object use from a library rather
than writing the code yourself.
◦ For example, if you need to process mail
messages in a Java program, you may use
objects and methods from a JavaMail library.
Some aspects of Implementation: Reuse
 The Component Level:
◦ Components are collections of objects and object
classes that operate together to provide related
functions and services.
◦ An example of component-level reuse is where
you build your user interface using a framework.
 The System Level
◦ At this level entire application systems is reuse.
◦ Most commercial systems are now built in this
way where generic COTS systems are adapted
and reused.
Cost associated with reuse software
 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.
 The aim of configuration management is to
support the system integration process so that
all developers can access the project code and
documents in a controlled way.
 Three fundamentals configuration management
activities.
◦ Version Management
◦ System integration
◦ Problem Tracking
Host Target Management
 Most software development is based on a host-
target model. Software is developed on one
computer (the host), but runs on a separate
machine (the target).
 The development and execution platforms are the
same, making it possible to develop the software
and test it on the same machine.
 Simulators are often used when developing
embedded systems. You simulate hardware
devices, such as sensors, and the events in the
environment in which the system will be deployed.
 It may be impractical to install that software on your
development machine, even if it is the same as the
target platform, because of license restrictions.
Tools to support Software Engineering Process
 An integrated compiler and syntax-directed editing
system that allows you to create, edit, and compile
code.
 A language debugging system.
 Graphical editing tools, such as tools to edit UML
models.
 Testing tools, such as JUnit (Massol, 2003) 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.
Issues to be consider while developing
Component Model
 The hardware and software requirements of a
component.
 The availability requirements of the system
 Component communications
Open Source Document
 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,
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.
 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.
Open Source Document
 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.
 It is usually fairly cheap or free to acquire open
source software.
 The key benefit of using open source products is
that mature open source systems are usually very
reliable.
 Two issues in Open Source Software
◦ 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.
 General models of Open Source Licence
◦ The GNU General Public License (GPL).
◦ The GNU Lesser General Public License (LGPL).
◦ The Berkley Standard Distribution (BSD) License.
 Licensing issues are important because if you use
open-source software as part of a software product,
then you may be obliged by the terms of the license
to make your own product open source.
Ways to manage Open Source Project
 Establish a system for maintaining information
about open source components that are
downloaded and used.
 Be aware of the different types of licenses and
understand how a component is licensed before it is
used.
 You need to know a bit about the open source
project where components are developed to
understand how they might change in future.
 Educate people about open source.
 Have auditing systems in place.
 Participate in the open source community.