Software design

Software Design
Design process, design strategies, design quality , system
structuring control models, modular decomposition , domain
specific architecture.
24 September 2016 NAVEENSAGAYASELVARAJ 1

Introduction
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
• Usually with graphical
diagrams or design, with the
intention to build from the
explanation
• The design is a
representation of a product
or a system with sufficient
detail for implementation

Analysis and Design Model
Data Dictionary
Entity-
Relationship
Diagram
Data Flow
Diagram
State-Transition
Diagram

Design Principle

Problem Partitioning
Divide and Conquer
Decompose System into smaller and smaller pieces
◦ Ideally, each pieces can be solved separately (“divide into smaller pieces, so that each piece can be conquered separately”)
◦ Ideally, each pieces can be modified independent of other pieces (Not all pieces are entirely independent)

Structural Partitioning
When the architectural style of a design follows a hierarchical nature, the structure of the
program can be partitioned either horizontally or vertically.

Abstraction
“Abstraction permits one to concentrate on a problem at some level of generalization without
regard to irrelevant low level details..”
1. During requirements definition and design, abstraction permits separation of the conceptual
aspects of a system from the (yet to be specified) implementation details
2. Any component or system provides some services to its environment. An abstraction of a
component describes the external behavior of that component without bothering with the
internal details that produce the behavior
3. Presumably, the abstract definition of a component is much simpler than the component
itself
4. Abstraction is an indispensable part of the design process and is essential for problem
partitioning
5. Abstraction is used for existing components as well as components that are being designed

Cont.. Procedural Abstraction
open
object that is associated with enter
• walk to the door
• reach out and grasp knob
• turn knob and pull door,
• step away from moving
door, etc..

Cont.. Data Abstraction
door
implemented as a data structure
• Door Type
• Swing direction
• Opening mechanism
• Weight
• Dimensions

Cont.. Control Abstraction
1. Control abstraction is the third form of abstraction used in software design
2. Like procedural and data abstraction, control abstraction implies a program control
mechanism without specifying internal details
3. An example of a control abstraction is the synchronization semaphore used to coordinate
activities in an operating system.

Abstraction Mechanism
Functional Abstraction:
a. In functional abstraction, a module is
specified by the function it performs
b. For example, a module to compute the log
of a value can be abstractly represented by
the function log
c. Functional abstraction is the basis of
partitioning in function-oriented
approaches
Data Abstraction:
a. Certain operations are required from a
data object, depending on the object and
the environment in which it is used.
b. Data is not treated simply as objects, but is
treated as objects with some predefined
operations on them
c. Data abstraction forms the basis for object-
oriented design

Top-Down Strategy
The top-down approach starts from the highest-level component of the hierarchy and proceeds
to lower levels.

Bottom- Up Strategy
A bottom-up approach starts with the lowest-level component of the hierarchy and proceeds
through progressively higher levels to the top-level component.
Agile

Design Process
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
Sy stem
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products
Various phases of design process are shown below

Design Strategies
Functional design
• The system is designed from a functional viewpoint
• The system state is centralized and shared between the functions operating
on that state.
Object-oriented design
• The system is viewed as a collection of interacting objects
• The system state is decentralized and each object manages its own state
• Objects may be instances of an object class and communicate by exchanging
methods.

Functional View of a Compiler

Object-oriented View of a Compiler

Important concepts of OOD
1. Objects
2. Classes
3. Encapsulation
4. Inheritance
5. Polymorphism

Mixed-strategy Design
1. Although it is sometimes suggested that one approach to design is
superior, in practice, an object-oriented and a functional-oriented
approach to design are complementary.
2. Good software engineers should select the most appropriate
approach for whatever sub-system is being designed.

Design Quality
Design quality is an elusive concept. Quality depends on specific organizational
priorities.
1. A “good” design may be the most efficient, the cheapest, the most
maintainable, the most reliable, etc.
2. The attributes discussed here are concerned with the maintainability of the
design.
3. Quality characteristics are equally applicable to function-oriented and object-
oriented designs.

Coupling measure of the strength of the inter-connections between system
components
28
Coupling

Factors Influencing coupling:
1. The type of connection between modules
2. The complexity of the interface
3. The type of information flow between modules

1. Object-oriented systems are loosely coupled because there is no
shared state and objects communicate using message passing
2. However, an object class is coupled to its super-classes. Changes
made to the attributes or operations in a super-class propagate to
all sub-classes
Coupling and Inheritance

Cohesion
1. A measure of how well a component “fits together”
2. A component should implement a single logical entity or function
3. Cohesion is a desirable design component attribute as when a
change has to be made, it is localized in a single cohesive
component
4. Coupling is reduced when the element in different modules have
little or no bounds between them

Cohesion Levels
Coincidental cohesion (weak)
Parts of a component are simply bundled together.
Logical association (weak)
Components which perform similar functions are
grouped.
Temporal cohesion (weak)
Components which are activated at the same time
are grouped.
Communicational cohesion (medium)
All the elements of a component operate on the
same input or produce the same output.
Sequential cohesion (medium)
The output for one part of a component is the
input to another part.
Functional cohesion (strong)
Each part of a component is necessary for the
execution of a single function.
Procedural cohesion(strong)
Each operation provides functionality which
allows object attributes to be modified or
inspected.

How does one determine the cohesion
level of a module?
The following tests can, then, be made:
1. If the sentence must be a compound sentence, if it contains a comma, or it
has more than one verb, the module is probably performing more than one
function, and it probably has sequential or communicational cohesion.
2. If the sentence contains words relating to time, like “first,” “next,” “when,”
and “after”, the module, probably, has sequential or temporal cohesion.
3. If the predicate of the sentence does not contain a single specific object
following the verb (such as “edit all data”), the module probably has logical
cohesion.
4. Words like “initialize,” and “cleanup” imply temporal cohesion.

Design Notation and Specification
Dynamic
1. Data flow diagrams (DFDs)
2. State transition diagrams
(STDs)
3. State charts
Static
1. Entity Relationship Diagrams
(ERDs)
2. Class diagrams
3. Structure charts
4. Object diagrams

Data Flow Diagram (DFD)
1. A notation developed in conjunction with structured systems
analysis/structured design (SSA/SD)
2. Used primarily for pipe-and-filter styles of architecture
3. Graph–based diagrammatic notation
4. There are extensions for real-time systems that distinguish control
flow from data flow

Representation of Components
DFDs only involve four symbols. They are:
1. Process -Transform of incoming data flow(s) to outgoing flow(s)
2. Data Object -Movement of data in the system
3. Data Store -Data repositories for data that are not moving. It may
be as simple as a buffer or a queue or a s sophisticated as a
relational database
4. External entity -Sources of destinations outside the specified
system boundary

Cont..
PROCESS
DATA FLOW
DATA STORE
EXTERNAL
ENTITY

Relationship and Rules
Context Diagram

Cont..
Level 1 DFD

Data Flow Diagram Tips and Cautions
Tips
1. Process labels should be verb phrases; data stores are represented by nouns
2. A data store must be associated to at least a process
3. An external entity must be associated to at least a process
4. Don't let it get too complex; normally 5 - 7 average people can manage processes
5. DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's useful
in identifying the processes when discussing with users
6. Data stores should not be connected to an external entity, otherwise, it would mean that
you're giving an external entity direct access to your data files
7. Data flows should not exist between 2 external entities without going through a process
8. A process that has inputs but no outputs is considered to be a black-hole process

Cont..
Cautions
Don't mix up data flow and process flow
Some designers may feel uncomfortable when seeing a connector connecting
from a data store to a process, without seeing the step of data request being
shown on the diagram somehow. Some of them will try to represent a request
by adding a connector between a process and a data store, labeling it "a
request" or "request for something", which is wrong.
Keep in mind that Data Flow Diagram was designed for representing the
exchange of information. Connectors in a Data Flow Diagram are for
representing data, not for representing process flow, step or anything else.

State Transition Diagram (STD)
One way to characterize change in a system is to say that its objects change
their state in response to events and to time
1. e.g. When you throw a switch, a light changes its state from off to on
2. e.g. The update mark method changes the state of the student subject object
A state diagram shows the various states of a single object
1. There must be a separate transition diagram for each object class
2. It helps analysts, designers and developer understand the behavior of the
objects in the system,
3. State diagrams ensure that they won't have to guess about what the object is
supposed to do

When do we care about States?
1. A class has a complex life cycle
2. Properties of the class may be updated at multiple points in the life cycle
3. When one class is dependent on the existence or behavior of other classes
4. When the behavior of a class depends on what previously happened
We can definitely say that state transition diagram show class state and the
events that cause them to transition between states.
1. An event happens at a specific time and place
2. Events cause a change of state for the object as the transition "fires"

When the Object state change?
Each time on object changes state, some of its attributes must change
1. There must be a method in the object class to change the attributes
2. Often there is a boundary or interface class ( a display screen or web form) for the actor to
enter the attributes and trigger the Event

Entity Relationship Diagrams (ERDs)
1976 proposed by Peter Chen
ER diagram is widely used in
database design
1. Represent conceptual level of a
database system
2. Describe things and their
relationships in high level
SALES ORDERS
INV. ITEMSORDER ITEMS
CLERKSCUSTOMERS

Basic Concepts
1. Entity set – an abstraction of similar things, e.g. cars,
students
• An entity set contains many entities
2. Attributes: common properties of the entities in a entity
sets
3. Relationship – specify the relations among entities from
two or more entity sets

An Example

Relationship
The degree of a relationship = the number of entity sets that
participate in the relationship
1. Mostly binary relationships
2. Sometimes more
Mapping cardinality of a relationship
1. 1 –1
2. 1 – many
3. many – 1
4. Many-many

One-One and One-Many

Many-one and many-many

Mandatory, Many-to-Many
INSTRUCTOR STUDENT
INSTRUCTOR STUDENT

Optional, Many-to-Many
DEPARTMENT STUDENT
DEPARTMENT STUDENT

Optional/Mandatory, Many-to-Many
INSTRUCTOR SKILL
INSTRUCTOR SKILL

Optional/Mandatory, One-to-Many
PRODUCT VENDOR
PRODUCT VENDOR

Mandatory, One-to-One
AUTOMOBILE ENGINE
AUTOMOBILE ENGINE

Recursive
EMPLOYEE
supervises
is supervised by

Notations

Cont..

Class Diagram
1. A Class Diagram is a diagram describing the structure of a
system
2. shows the system's
a. Classes
b. Attributes
c. Operations (or methods),
d. Relationships among the classes.

Essential Elements of a UML Class Diagram
1. Class
2. Attributes
3. Operations
4. Relationships
a. Associations
b. Generalization
c. Realization
d. Dependency
5. Constraint Rules and Notes
Window
size: Size
visibility: Boolean
display()
hide()
Class Name
Attributes
Operations

Class
Describes a set of objects having similar:
1. Attributes (status)
2. Operations (behavior)
3. Relationships with other classes
Attributes and operations may
1. have their visibility marked:
2. "+" for public
3. "#" for protected
4. "−" for private
5. "~" for package
Window
size: Size
visibility: Boolean
display()
hide()
Class Name
Attributes
Operations

Associations
An association between two classes indicates that objects at one end
of an association “recognize” objects at the other end and may send
messages to them.
Example: “An Employee works for a Company”
Employee Company

Cont..
Staff Member Student
1..* *instructs
instructor
Association
name
Role name
Multiplicity
Navigable
(uni-directional)
association
Courses
pre -
requisites
0..3
Reflexive
association
Role
*

Cont..
To clarify its meaning, an association may be named.
1. The name is represented as a label placed midway along the
association line.
2. Usually a verb or a verb phrase.
A role is an end of an association where it connects to a class.
1. May be named to indicate the role played by the class attached to the
end of the association path.
a. Usually a noun or noun phrase
b. Mandatory for reflexive associations

Cont..
Multiplicity
1. The number of objects that participate in the association
2. Indicates whether or not an association is mandatory
Exactly one 1
Zero or more (unlimited) * (0..*)
One or more 1..*
Zero or one (optional association) 0..1
Specified range 2..4
Multiple, disjoint ranges 2, 4..6, 8
Multiplicity Indicators

Aggregation
1. A special form of association that models a whole-part relationship
between an aggregate (the whole) and its parts.
2. Models a “is a part-part of” relationship.
Whole Part
Car Door House
1..*2..*

Cont..
Aggregation tests:
1. Is the phrase “part of” used to describe the relationship?
• A door is “part of” a car
2. Are some operations on the whole automatically applied to its parts?
• Move the car, move the door.
3. Are some attribute values propagated from the whole to all or some of its
parts?
• The car is blue, therefore the door is blue.
4. Is there an intrinsic asymmetry to the relationship where one class is
subordinate to the other?
• A door is part of a car. A car is not part of a door.

Composition
A strong form of aggregation
1. The whole is the sole owner of its part.
• The part object may belong to only one whole
2. Multiplicity on the whole side must be zero or one.
3. The life time of the part is dependent upon the whole.
• The composite must manage the creation and destruction of its parts.
Circle Point
3..*
1
Polygon
Point
Circle

Generalization
Indicates that objects of the specialized class (subclass) are substitutable for
objects of the generalized class (super-class).
• “is kind of” relationship
Shape
{abstract}
Circle
Super
Class
Sub Class
An abstract
class
Generalization
relationship
{abstract} is a tagged
value that indicates that
the class is abstract.
The name of an abstract
class should be italicized

Generalization
A sub-class inherits from its super-class
1. Attributes
2. Operations
3. Relationships
A sub-class may
1. Add attributes and operations
2. Add relationships
3. Refine (override) inherited operations
A generalization relationship may not be used to model interface
implementation.

Realization
1. A realization relationship indicates that one class implements a behavior
specified by another class (an interface or protocol).
2. An interface can be realized by many classes.
3. A class may realize many interfaces.
LinkedList
<<interface>>
List ArrayList

Dependency
1. Dependency is a weaker form of relationship which indicates that one class
depends on another because it uses it at some point in time.
2. One class depends on another if the independent class is a parameter
variable or local variable of a method of the dependent class.
3. This is different from an association, where an attribute of the dependent
class is an instance of the independent class.
Iterator Vector
<<friend>>

Constraint Rules and Notes
Constraints and notes annotate among other things associations,
attributes, operations and classes
Constraints are semantic restrictions noted as Boolean expressions.
• UML offers many pre-defined constraints
id: long { value > 0 }
Customer
Order
*1
{ total < $50 }
may be
canceled
Constraint Note

Example

Domain-Specific Architecture
1. The traditional view of software engineering shows us how to come up with
solutions for problems
2. But starting from scratch every time is infeasible
• This will involve re-inventing many wheels
3. Once we have built a number of systems that do similar things, we gain
critical knowledge that lets us exploit common solutions to common
problems
• In theory, we can simply build “the difference” between our new target
system and systems that have come before

Examples of Domains
1. Compilers for programming languages
2. Consumer electronics
3. Electronic commerce system/Web stores
4. Video game
5. Business applications
• Basic/Standard/“Pro”

Three Key Factors of DSSE
Domain
• Must have a domain to constrain the problem space and focus development
Technology
• Must have a variety of technological solutions—tools, patterns, architectures
& styles, legacy systems—to bring to bear on a domain
Business
• Business goals motivate the use of DSSE
• Minimizing costs: reuse assets when possible
• Maximize market: develop many related applications for different kinds of
end users

Domain
• Must have a domain to constrain
the problem space and focus
development
Domain Business
Technology
Cont..

Technology
• Must have a variety of
technological solutions—tools,
patterns, architectures &
styles, legacy systems—to
bring to bear on a domain
Domain Business
Technology
Cont..

Business
•Business goals motivate the
use of DSSE
1. Minimizing costs: reuse assets
when possible
2. Maximize market: develop many
related applications for different
kinds of end users
Domain Business
Technology
Cont..

Domain + Business
“Corporate Core Competencies”
• Domain expertise augmented by
business acumen and knowledge of
the market
Domain Business
Technology
Cont..

Domain + Technology
“Application Family
Architectures”
◦ All possible technological solutions to
problems in a domain
◦ Uninformed and unconstrained by
business goals and knowledge
Domain Business
Technology
Cont..

Business + Technology
“Domain independent
infrastructure”
• Tools and techniques for constructing
systems independent of any particular
domain
• E.g., most generic ADLs, UML, compilers,
word processors, general-purpose PCs
Domain Business
Technology
Cont..

Domain + Business + Technology
“Domain-specific
software engineering”
Applies technology to domain-
specific goals, tempered by
business and market knowledge
Domain Business
Technology
Cont..

Product-Line Architectures
1. A specific, related set of solutions
within a broader DSSE
2. More focus on commonalities and
variability between individual
solutions
Domain Business
Technology
Cont..

Domain Model
A domain model is a set of artifacts that capture information about a domain
1. Functions performed
2. Objects (also known as entities) that perform the functions, and on which
the functions are performed
3. Data and information that flows through the system
Standardizes terminology and semantics
Provides the basis for standardizing (or at least normalizing) descriptions of
problems to be solved in the domain

Cont..

Defines vocabulary for the domain
Cont..

Describes the entities and data in the domain
Cont..

Cont..
Defines how entities and data combine to provide features

Cont..
Defines how data and control flow through entities

• Example for Use Case Diagram
• Example for Entity Relationship Diagram
• Example for Data Flow Diagram
• Example for State Transition Diagram
Reference Links:

Example for Use Case Diagram:

Example for Entity Relationship diagram:

Example for Data Flow diagram:

Example for State Transition diagram:

Software design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (13)

Ähnlich wie Software design

Ähnlich wie Software design (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software design