0% found this document useful (0 votes)
7 views51 pages

Unit 7_ Design and Implementation

The document outlines the design and implementation of software, emphasizing the importance of architectural design and various architectural patterns. It discusses the process of converting conceptual models into physical models, the significance of software reuse, and the implications of open-source development. Additionally, it covers implementation issues, configuration management, and licensing models in the context of software development.

Uploaded by

sunilstha68
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views51 pages

Unit 7_ Design and Implementation

The document outlines the design and implementation of software, emphasizing the importance of architectural design and various architectural patterns. It discusses the process of converting conceptual models into physical models, the significance of software reuse, and the implications of open-source development. Additionally, it covers implementation issues, configuration management, and licensing models in the context of software development.

Uploaded by

sunilstha68
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 51

Unit 7.

Design and Implementation

1
Architectural Design {Review}

 Need of Architecture
 Architectural Patterns
 Box and Line Diagram
 MVC
 Layered Architecture
 Repository Architecture
 Client Server Architecture
 P2P architecture
 Multiprocessor Architecture
 Application Architecture

2
3
Design and implementation

 Software design is the stage at which the conceptual/logical model is


converted to physical model
 Software design is the process by which an agent creates a specification of a
software artifact intended to accomplish goals, using a set of primitive
components and subject to constraints.
 Software design may refer to either "all the activity involved in
conceptualizing, framing, implementing, commissioning, and ultimately
modifying complex systems"
 the activity following requirements specification and before programming

4
Design and implementation

 A product software implementation method is a systematically structured


approach to transform the design model into a working product

 Software design and implementation activities are invariably inter-leaved.


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

5
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.
 Re-use oriented software engineering
 Application system reuse
 Component reuse
 Object and function reuse

6
Software reuse landscape

Approach Description

Architectural patterns Standard software architectures that support common types of


application systems are used as the basis of applications.

Design patterns Generic abstractions that occur across applications are represented
as design patterns showing abstract and concrete objects and
interactions.
Component-based Systems are developed by integrating components (collections of
development objects) that conform to component-model standards

Application frameworks Collections of abstract and concrete classes are adapted and
extended to create application systems.
Legacy system wrapping Legacy systems are ‘wrapped’ by defining a set of interfaces and
providing access to these legacy systems through these interfaces.
7
O
b
j An object-oriented design process
e
c
t
-
o
r
i
e
n
t
e
d

d
e
s
i 8
g
T
h
e Process stages
r
e

a
r
e

v
a
r
i
e
t 9
y
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.

10
Context and interaction models

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

11
System context for the weather station

12
Weather station use cases

13
O
n
c Architectural design
e

i
n
t
e
r
a
c
t
i
o
n
s
14
b
High-level architecture of the weather station

15
Architecture of data collection system

16
I
d
e Object class identification
n
t
i
f
y
i
n
g

o
b
j
e
c
t 17
U
s
e Approaches to identification

g
r
a
m
m
a
t
i
c
a
l
18
a
Weather station description

A weather station is a package of software controlled instruments which collects


data, performs some data processing and transmits this data for further processing.
The instruments include air and ground thermometers, an anemometer, a wind vane,
a barometer and a rain gauge. Data is collected periodically.

When a command is issued to transmit the weather data, the weather station
processes and summarises the collected data. The summarised data is transmitted to
the mapping computer when a request is received.

19
C
l
a Weather station Classes
s
s

i
d
e
n
t
i
f
i
c
a
t
i 20
o
Weather station object classes

21
D
e
s Design models
i
g
n

m
o
d
e
l
s

s
h
o
w 22
S
u
b Examples of design models
s
y
s
t
e
m

m
o
d
e
l
s

t 23
h
S
h
o Subsystem models
w
s

h
o
w

t
h
e

d
e
s
i 24
g
S
e
q Sequence models
u
e
n
c
e

m
o
d
e
l
s

s
h
o
w 25
Sequence diagram describing data collection

26
S
t
a State diagrams
t
e

d
i
a
g
r
a
m
s

a
r
e

u 27
s
Weather station state diagram

28
O
b
j Interface specification
e
c
t

i
n
t
e
r
f
a
c
e
s
29
h
Weather station interfaces

30
A

d Design patterns
e
s
i
g
n

p
a
t
t
e
r
n

i 31
s
A

d Design patterns
e
s
i
g
n

p
a
t
t
e
r
n

c 32
a
Design patterns

Creational Design Patterns


Manage the way objects are created

• Singleton - Ensures that only one instance of a class is created


and Provides a global access point to the object

• Factory - A software factory produces objects. And not just that


— it does so without specifying the exact class of the object to
be created. To accomplish this, objects are created by calling a
factory method instead of calling a constructor.
Design patterns

Creational Design Patterns (contd..)

• Builder - Defines an instance for creating an object but letting


subclasses decide which class to instantiate and Allows a finer
control over the construction process.

• Prototype - Specify the kinds of objects to create using a


prototypical instance, and create new objects by copying this
prototype.
Design patterns

Structural Design Patterns


Define structures of objects and classes that can work together and define how the
relations can be defined between entities.

• Adapter - Convert the interface of a class into another interface


clients expect

• Bridge - Compose objects into tree structures to represent part-


whole Hierarchies
Design patterns

Structural Design Patterns (contd..)

• Flyweight - use sharing to support a large number of objects that


have part of their internal state in common where the other part
of state can vary

• Memento - capture the internal state of an object without


violating encapsulation and thus providing a mean for restoring
the object into initial state when needed
Design patterns

Behavioral Design Patterns


Define the interactions and behaviors of classes

• Chain of Responsibility - The objects become parts of a chain and the request is sent from one
object to another across the chain until one of the objects will handle it.

• Interpreter - Given a language, define a representation for its grammar along with an
interpreter that uses the representation to interpret sentences in the language

• Iterator - Provide a way to access the elements of an aggregate object sequentially without
exposing its underlying representation

• Mediator - Define an object that encapsulates how a set of objects interact


Design patterns

Behavioral Design Patterns (contd..)

• Observer - Define a one-to-many dependency between objects so that when one object
changes state, all its dependents are notified and updated automatically

• Strategy - Define a family of algorithms

• Template Method - Define the skeleton of an algorithm

• Visitor - Visitor lets you define a new operation without changing the classes of the elements on
which it operates.
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.

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

40
Reuse

 From the 1960s to the 1990s, most new software was developed from
scratch, by writing all code in a high-level programming language.
 The only significant reuse or software was the reuse of functions and objects in
programming language libraries.
 Costs and schedule pressure mean that this approach became increasingly
unviable, especially for commercial and Internet-based systems.
 An approach to development based around the reuse of existing software
emerged and is now generally used for business and scientific software.

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

42
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, find out what changes have been made, and compile and
link components to create a system.

43
Configuration management activities

 Version management, where support is provided to keep track of the different


versions of software components. Version management systems include facilities to
coordinate development by several programmers.
 System integration, where support is provided to help developers define what
versions of components are used to create each version of a system. This
description is then used to build a system automatically by compiling and linking the
required components.
 Problem tracking, where support is provided to allow users to report bugs and other
problems, and to allow all developers to see who is working on these problems and
when they are fixed.

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

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

46
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?

47
Open source business

 More and more product companies are using an open source approach to
development.
 Their business model is not reliant on selling a software product but on
selling support for that product.
 They believe that involving the open source community will allow software to
be developed more cheaply, more quickly and will create a community of
users for the software.

48
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.
 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.
 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.
 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.

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

50
License management

 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.
 Be aware of evolution pathways for components.
 Educate people about open source.
 Have auditing systems in place.
 Participate in the open source community.

51

You might also like