Design Concepts in Software Engineering-1.pptx

Design Concepts in Software
Engineering
Dr.S.Karthigai Selvi
Guest Teacher
Department of Computer Sceince and Applications
The Gandhigram Rural Institute – Deemed to be University
Gandhigram
India
1

What is Design in SE?
• It is the place where creativity rules—where
stakeholder requirements, business needs,
and technical considerations all come together
in the formulation of a product or system.
• The design model provides detail about
software architecture, data structures,
interfaces, and components that are
necessary to implement the system.
2

Why is it important?
• It allows you to model the system or product
that is to be built. This model can be assessed
for quality and improved before code is
generated, tests are conducted, and end users
become involved in large numbers. Design is
the place where software quality is
established.
3

What are the steps?
1. The architecture of the system or product must
be represented.
2. The interfaces that connect the software to end
users, to other systems and devices, and to its
own constituent components are modeled.
3. The software components that are used to
construct the system are designed.
4
Architecture Interface S/W Components

What is the work product?
• The design model that encompasses
architectural, interface, componentlevel, and
deployment representations is the primary
work product that is produced during
software design.
5

How do I ensure that I’ve done it
right?
• The design model is assessed by the software
team in an effort to determine whether it
contains errors, inconsistencies, or omissions;
whether better alternatives exist; and
whether the model can be implemented
within the constraints, schedule, and cost that
have been established.
6

Roman architecture critic Vitruvius
• Well-designed buildings were those which
exhibited firmness, commodity, and delight.
• Firmness: A program should not have any
bugs that inhibit its function.
• Commodity: A program should be suitable for
the purposes for which it was intended.
• Delight: The experience of using the program
should be a pleasurable one.
7

DESIGN WITHIN THE CONTEXT OF
SOFTWARE ENGINEERING
8

3.2.2. The Evolution of Software
Design
• Procedural aspects of design definition evolved
into a philosophy called structured
programming
• Newer design approaches (e.g., [Jac92],
[Gam95]) proposed an object-oriented
approach to design derivation.
• Growing emphasis on
– aspect-oriented methods (e.g., [Cla05], [Jac04]),
– model-driven development [Sch06], and
– test-driven development [Ast04]
• emphasize techniques for achieving more
effective modularity and architectural structure
in the designs that are created
10
Structured
Programming
Object Oriented
Programming

Each software design method characterizes design
quality
(1) a mechanism for the translation of the
requirements model into a design representation,
(2) a notation for representing functional components
and their interfaces,
(3) heuristics for refinement and partitioning, and
(4) guidelines for quality assessment.
11
you should apply a set of basic concepts to data,
architectural, interface, and component-level design.

3.3. DESIGN CONCEPTS
• You answer the following questions:
• What criteria can be used to partition software
into individual components?
• How is function or data structure detail
separated from a conceptual representation
of the software?
• What uniform criteria define the technical
quality of a software design?
12

overview of important software design
concepts that span both traditional and object-
oriented software development.
1. Abstraction
2. Architecture
3. Patterns
4. Separation of Concerns
5. Modularity
6. Information Hiding
7. Functional Independence
8. Refinement
9. Aspects
10. Refactoring
11. Object-Oriented Design Concepts
12. Design Classes
13

3.3.1.Abstraction
• Abstraction is used to hide background details or any
unnecessary implementation about the data so that
users only see the required information.
• At the highest level of abstraction, a solution is stated
in broad terms
• using the language of the problem environment. At
lower levels of abstraction, a
• more detailed description of the solution is provided.
14
•using the language of the problem
environment
High Level of
Abstraction
•Problem-oriented
•implementation-oriented
•Both are directly implemented
Low Level of
Abstraction

As different levels of abstraction:
• A Procedural abstraction : refers to a
sequence of instructions that have a specific
and limited function. The name of a
procedural bstractionimplies these functions,
but specific details are suppressed. Eg. Open
Door
• A data abstraction: is a named collection of
data that describes a data object. Eg. Door
(encompasses door type, swing direction,
opening mechanism, weight, dimensions)
15

3.3.2 Architecture
• “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system”
• architecture is
– the structure or organization of program components
(modules),
– the manner in which these components interact, and
– the structure of data that are used by the components.
• components can be generalized to represent major system
elements and their interactions.
• One goal of software design is to derive an architectural
rendering of a system. It serves as a software framework.
16

• A set of architectural patterns enables a software engineer
to solve common design problems . The Properties of S/W
are
– Structural properties. This aspect of the architectural design
representation defines the components of a system (e.g.,
modules, objects, filters) and the manner in which those
components are packaged and interact with one another. For
example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the
invocation of methods.
– Extra-functional properties. The architectural design
description should address how the design architecture
achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
– Families of related systems. The architectural design should
draw upon repeatable patterns that are commonly
encountered in the design of families of similar systems. In
essence, the design should have the ability to reuse
architectural building blocks.
17

• Architectural design can be represented using one or more
of a number of different models
• Structural models - represent architecture as an organized
collection of program components.
• Framework models - increase the level of design
abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in
similar types of applications.
• Dynamic models address the behavioral aspects of the
program architecture, indicating how the structure or
system configuration may change as a function of external
events.
• Process models focus on the design of the business or
technical process that the system must accommodate.
Finally,
• functional models can be used to represent the functional
hierarchy of a system.
18

• A number of different architectural description
languages (ADLs) have been developed to
represent these models
• provide mechanisms for describing system
components and the manner in which they
are connected to one another.
19

Patterns
• Brad Appleton defines a design pattern -
a design pattern describes a design structure that solves a
particular design problem within a specific context and
amid “forces” that may have an impact on the manner in
which the pattern is applied and used.
• design pattern is to provide a description that enables
a designer to determine
– (1) whether the pattern is applicable to the current work,
– (2) whether the pattern can be reused (hence, saving
design time), and
– (3) whether the pattern can serve as a guide for
developing a similar, but functionally or structurally
different pattern.
20

3.3.4 Separation of Concerns
• Separation of concerns is a design concept [Dij82] that
suggests that any complex problem can be more easily
handled if it is subdivided into pieces that can each be
solved and/or optimized independently.
• concern is a feature or behavior that is specified as
part of the requirements model for the software. By
separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and
time to solve.
• Separation of concerns is manifested in other related
design concepts: modularity, aspects, functional
independence, and refinement.
21

3.3.5 Modularity
• Software is divided into
separately named and
addressable components,
sometimes called modules,
that are integrated to satisfy
problem requirements.
• In Monolithic software
• The number of control paths,
span of reference, number of
variables, and overall
complexity would make
understanding close to
impossible.
22

3.3.6 Information Hiding
• How do I decompose a software solution to
obtain the best set of modules?
• Modules should be specified and designed so
that information (algorithms and data)
contained within a module is inaccessible to
other modules that have no need for such
information.
• Hiding implies that effective modularity can be
achieved by defining a set of independent
modules that communicate with one another
only that information necessary to achieve
software function.
• Abstraction helps to define the procedural (or
informational) entities that make up the
software.
23
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents
Functi
onal
compo
nents

3.3.7 Functional Independence
• It is the concepts of abstraction and information hiding.
• It is achieved by developing modules with “single minded” function and an
“aversion” to excessive interaction with other modules.
• you should design software so that each module addresses a specific subset of
requirements and has a simple interface when viewed from other parts of the
program structure. It is fair to ask why independence is important.
• Independence is assessed using two qualitative criteria: cohesion and coupling.
• Cohesion is an indication of the relative functional strength of a module. A
cohesive module performs a single task, requiring little interaction with other
components in other parts of a program.
• Coupling is an indication of the relative interdependence among modules. It is an
indication of interconnection among modules in a software structure. Coupling
depends on the interface complexity between modules, the point at which entry
or reference is made to a module, and what data pass across the interface
24

3.3.8 Refinement
• Refinement is actually a process of elaboration.
• You begin with a statement of function (or description
of information) that is defined at a high level of
abstraction.
• That is, the statement describes function or
information conceptually but provides no information
about the internal workings of the function or the
internal structure of the information.
• Abstraction enables
• you to specify procedure and data internally but
suppress the need for “outsiders” to have knowledge
of low-level details.
25

3.3.9 Aspects
• Concerns “include requirements, use cases,
features, data structures, quality-of-service
issues,variants, intellectual property
boundaries, collaborations, patterns and
contracts”
26

3.3.10 Refactoring
• Refactoring is a reorganization technique that
simplifies the design (or code) of a component
without changing its function or behavior.
• When software is refactored, the existing design
is examined for redundancy, unused design
elements, inefficient or unnecessary algorithms,
poorly constructed or inappropriate data
structures, or any other design failure that can be
corrected to yield a better design.
27

3.3.11 Object-Oriented Design
Concepts
• The object-oriented (OO) paradigm is widely
used in modern software engineering.
• OO -design concepts such as classes and
objects, inheritance, messages, and
polymorphism, among others.
28

3.3.12 Design Classes
• The requirements model defines a set of analysis classes.
• you will define a set of design classes that refine the analysis classes
– User interface classes define all abstractions that are necessary for
human computer interaction (HCI)
– Business domain classes are often refinements of the analysis classes
defined earlier. The classes identify the attributes and services
(methods) that are required to implement some element of the
business domain.
– Process classes implement lower-level business abstractions required
to fully manage the business domain classes.
– Persistent classes represent data stores (e.g., a database) that will
persist beyond the execution of the software.
– System classes implement software management and control
functions that enable the system to operate and communicate within
its computing environment and with the outside world
29

• Complete and sufficient. A design class
should be the complete encapsulation of all
attributes and
• Primitiveness. Methods associated with a
design class should be focused on
accomplishing one service for the class.
• High cohesion. A cohesive design class has a
small, focused set of responsibilities and
single-mindedly
• Low coupling. Within the design model, it is
necessary for design classes to Collaborate
with one another.
30

Design Concepts in Software Engineering-1.pptx

More Related Content

What's hot

Similar to Design Concepts in Software Engineering-1.pptx

More from KarthigaiSelviS3

Recently uploaded

Design Concepts in Software Engineering-1.pptx