Unit II - Software Design

UNIT II - SOFTWARE DESIGN
Unit II – Software Design

• Abstraction – Modularity – Software
Architecture – Cohesion – Coupling –
Various Design Concepts and notations –
Real time and Distributed System Design
– Documentation – Dataflow Oriented
design – Jackson System development –
Designing for reuse – Programming
standards – Case Study of Design of any
Application Project.
Software Design Concepts
Visualizing Design
modeling
Prototype
Spec
Design
An Important Quote
"Questions about whether design is
necessary or affordable are quite beside
the point; design is inevitable. The
alternative to good design is bad design,
[rather than] no design at all."
- Douglas Martin
Design Purpose
• Design is where customer requirements,
business needs, and technical considerations
all come together in the formulation of a
product or system
• The design model provides detail about the
software data structures, architecture,
interfaces, and components
• Software design is an iterative process
through which requirements are translated
into a blueprint for constructing the
software
Analysis Phase to Design Phase
Analysis Phase to Design Phase
• Each element of the analysis model
provides information that is necessary to
create the four design models
– The data/class design transforms
analysis classes into design classes along
with the data structures required to
implement the software
– The architectural design defines the
relationship between major structural
elements of the software; architectural
styles and design patterns help achieve the
requirements defined for the system
– The interface design describes how the
software communicates with systems
that interoperate with it and with
humans that use it
– The component-level design transforms
structural elements of the software
architecture into a procedural
description of software components
Component-level Design
(Class-based model, Flow-oriented model

Behavioral model)
Interface Design
(Scenario-based model, Flow-oriented model

Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Data/Class Design
(Class-based model, Behavioral model)

Design Model for Software
Functional Information
model model
Behavioral Data design

model
Design Architectural
design
Code
Other Procedural
requirements design Program Test
modules
Fundamental Design Concepts
1) Abstraction
– Procedural abstraction – a sequence of
instructions that have a specific and limited
function
– Data abstraction – a named collection of
data that describes a data object
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the

object that is associated with enter
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure

Step-wise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
2) Modularity
– Separately named and addressable
components (i.e., modules) that are
integrated to satisfy requirements (divide
and conquer principle)
– Makes software intellectually manageable
so as to grasp the control paths, span of
reference, number of variables, and overall
complexity
– A modular design always helps in building
applications easier, easier to change as
well as to fix errors faster
Trade-offs with Modularity
- What is the “right” number of modules
for a specific software design ?
module development cost
cost of
software
module
integration
cost
number of modules
Optimal number of modules
3) Software Architecture
Definition : IEEE 1471-2000
- Software architecture is the fundamental
organization of a system, embodied in
its components, their relationships to each
other and the environment, and the
principles governing its design and
evolution
- Structure should provide conceptual
integrity
- Consists of components, connectors,
and the relationship between them
Software Architecture addresses three
properties
a)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.
b)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.
c)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 blocks.
Models of Software Architecture
• Structural Models – represent architecture as an
organized collection of program components
• Framework Models – identify repeatable
architectural design frameworks (patterns) that
are encountered in similar types of applications
• Dynamic Models – address the behavioral aspects
of the program architecture
• Process Models – focus is on the design of the
business or technical process that the system must
be accommodate.
• Functional Models – represent the functional
hierarchy of a system
Patterns in Software Architecture
– A design structure that solves a particular
design problem within a specific context
– It provides a description that enables a

designer to determine whether the pattern
is applicable, whether the pattern can be
reused, and whether the pattern can serve
as a guide for developing similar patterns
Architecture:
where non-
functional
decisions are
non-functional architecture cast, and
requirements functional
requirements
are partitioned
functional
requirements design Design:
where
(domains) functional
requirements
are
accomplished
• Architecture is a set of well-identified

early design decisions
4) Functional Dependence and
Independence (Coupling &
Cohesion)
– Modules that have a "single-minded"
function and an aversion to excessive
interaction with other modules
– High cohesion – a module performs only a
single task
– Low coupling – a module has the lowest
amount of connection needed with other
modules
- A cohesive module is one where the

information within the module is
accessible only to a limited number of
modules and just performs a single
task
Definition : Cohesion
“The measure of the strength of functional
relatedness of elements within a module”
1 3 5 6 7 8
2 4
Coincident Logical Temporal Procedural Communic Sequential Functional Informati

al ational onal
Bad Good
1) Coincidental cohesion Function A
- Elements of a module Function Function

B C
perform functionality Function Function

D E
- Totally unrelated actions
with no meaningful relationship
- Cohesion involving multiple activities
which is not good
Problems
- Difficulty in understanding activities
- Maintainability is also difficult
Example for Coincidental Cohesion

module miscellaneous functions
use customer record
display customer record
calculate total sales
read transaction record
return transaction record
end module
2) Logical Cohesion
- Elements of a module contribute to
activities of the same general type
- A module that is logically related in
performing activities eg. I/O module,
borrow transaction module etc…
- Modules have better control coupling
here
Example for Logical Cohesion
module display record
use record-type, record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module
3) Temporal Cohesion
- Elements of the module perform activities
with time eg. initializations, startup
operations etc…
- If elements are unrelated, reusability will be
difficult
Example : module initialise
set counter to 0
open student file
clear error message variable
initialise array
end module
4) Procedural Cohesion
- Elements of a module related by
sequence
- Similar to sequential cohesion, except
for the fact that elements are
unrelated
- Mostly found at the top of the
hierarchy i.e. main module in ‘C’
Example for Procedural Cohesion

module write read and edit something
use out record
write out record
read in record
pad numeric fields with zeros
return in record
end module
5) Communicational Cohesion
- Elements contribute to activities that
use a) same i/p and b) output data
Example
module determine customer details
use customer account no
find customer name
find customer loan balance
return customer name, loan balance
end module
6) Sequential Cohesion
- Elements of the module are involved
in performing a sequence of actions
i.e. the output of one activity becomes
the input of another activity and so
on...
Advantages
- Achieving high levels of maintainability
- Reduces coupling
7) Functional Cohesion
- Contribution of all elements in the
execution of one and only one task
- No elements perform unrelated
activities
eg: writing a record to a database,
booking a rail ticket etc…
8) Informational Cohesion
- Occurs when a module contains
complex data structures and several
routines that manipulate that data
structure
- Techniques which support
informational cohesion are
a) ADTs
b) OOP
Types of Coupling and their impact
• Data coupling good
• Stamp coupling
• Control coupling
• Hybrid coupling
• Common coupling
• Content coupling bad
1) Data Coupling
- Parameter communication by modules
- Data is being sent as Process
parameters Results
- Data is needed for
communicating with other grade
modules
Problems Calculate
- Lot of parameters, interface Grade
understanding difficulties
- Data tramping
2) Stamp Coupling
- Moving composite data types between
modules Process
- A type of coupling where Results
bundling of data takes

place
record updated
record
Problems
Update
- Unrelated data getting stored Grade
in the modules
3) Control Coupling
- A module trying to control the logic
of other modules
Check
- Controlling module should record
know about the flexibility
of the other module(s) Error
Problems code
- If the controlled module is Display

not flexible, then problems error
may arise
4) Hybrid coupling
- Using a subset of data and code to
control other modules Main
- Eg: id numbers between program
0001-9999 Data
- If 1000-9099, send an
+
code
email to area-code,
Process
last two digits(00-99) account
5) Common Coupling
- Using global data for communication
between modules Process
Multiple Problems Results
1) Many people Global data

updated
accessing the same record
global variable record Update

2) Ripple effects found Grade
6) Content Coupling
- A module referring internally and
branching to another
module(s)
Problems
- Might sometimes change the
internal workings or operation
of another module(s)
(a) (b)
high coupling low coupling

Design Notations
Three levels of Design Specifications
a) External Design Specifications
b) Architectural Design Specifications &
c) Detailed Design Specifications
Design Notations
1) Data flow diagrams
2) Structure charts
3) HIPO diagrams
4) Procedure Templates/Specifications
Design Notations
5) Pseudocodes
6) Structured flowcharts
7) Structured English &
8) Decision tables
2) Structure Charts
- Describe the hierarchical structure of
the application that is to be designed
- Used to represent the architectural
design of an application
Design Notations
Example of a
structure
chart
Design Notations
3) HIPO(Hierarchy-Input-Process-
Output) diagrams
- Contains the following items
a) Visual table of contents
b) A set of overview diagrams &
c) A set of detailed diagrams
Example : Inventory System
Design Notations
1.0 Manage inventory
2.0 Update stock
2.1 Process sale
2.2 Process return
2.3 Process shipment
3.0 Generate report
3.1 Respond to query
3.2 Display status report
4.0 Maintain inventory data
4.1 Modify record
4.2 Add record
4.3 Delete record
Tasks to be performed by the inventory system
Design Notations
Fig : A hierarchy chart for an inventory

system
Design Notations
Fig : An Overview diagram for Process 2.0

Design Notations
Fig : A detail diagram for Process 2.0

Design Notations
4) Procedure Templates
- Decribes the method on how a
particular activity should be done
Example
PROCEDURE NAME :
PART OF  subsystem name and number
CALLED BY :
PURPOSE :
DESIGNER/DATE(s):
Design Notations
5) Psuedocode
initialize passes to zero
initialize failures to zero
initialize student to one
while student counter is less than or equal to ten
input the next exam result
if the student passed
add one to passes
else
add one to failures
add one to student counter
print the number of passes
print the number of failures
if eight or more students passed
print "raise tuition"
Design Notations
6) Structured Flowcharts
- Traditional ways of specifying and
documenting algorithmic details in a
software system
Design Notations
7) Structured English
- A step-by-step specification of an
algorithm
Example
Receive OT request
Get ETC from EF
If OT>0
Then calculate OTP Else OTP=0
EndIF
Send OTP
Design Notations
8) Decision Tables
- To represent complex decision logic
in a high-level software specification
Real-Time System Design
• A real-time system is a software system
where the correct functioning of the
system depends on the results produced
by the system and the time at which
these results are produced.
• Two types of real-time systems
a) Soft real-time &
b) Hard real-time
• A soft real-time system is a system
whose operation is degraded if results
are not produced according to the
specified timing requirements.
• A hard real-time system is a system
whose operation is incorrect if results
are not produced according to the timing
specification.
• Systems which monitor and control their
environment.
• Inevitably associated with hardware devices
– Sensors: Collect data from the system
environment
– Actuators: Change (in some way) the
system's environment
• Time is critical. Real-time systems MUST
respond within specified times.
A model of a real-time system
Sensor and Actuator processes
Elements of a real-time system
a)Sensor control processes
- collecting information from sensors
- buffer information collected in
response to a sensor stimulus
b) Data processor
- carries out processing of collected
information and computes the system
response
c) Actuator control processes
- generates control signals for the
actuators
Note :
d) Java can be used as a RT programming
language(soft real-time time only)
e) For hard real-time requirements, we
have to use assembly language
Real-time systems design process
• Identify the stimuli to be processed
and the required responses to these
stimuli.
• For each stimulus and response,
identify the timing constraints.
• Aggregate the stimulus and
response processing into concurrent
processes. A process may be associated
with each class of stimulus and
response.
• Design algorithms to process each
class of stimulus and response. These
must meet the given timing
requirements.
• Design a scheduling system which
will ensure that processes are started in
time to meet their deadlines.
• Integrate using a real-time operating
system.
Timeout
Card
inser ted
into reader Reading Initialising
do: get C C do: initialise

details display
Hose out of holster

Card removed
W aiting Card OK
do: display Validating Ready Delivering

welcome
do: validate
do:
credit card
Nozzle deliver fuel
update display
trigger on
Timeout Invalid card

Nozzle trigger off
Nozzle trigger on
Resetting Stopped
do: display C C
error
P aying
Payment ack.
Hose in
do: debit
CC account holster
Summary
• Real-time system correctness depends
not just on what the system does but
also on how fast it reacts.
• A general RT system model involves
associating processes with sensors and
actuators.
• Real-time systems architectures are
usually designed as a number of
concurrent processes.
Distributed System Design
Objective
- To understand the design of a
distributed system and the issues in
designing such systems
Definition
- A distributed system is a collection of
independent computers that appears to
its users as a single coherent system.
Andrew Tanenbaum
Can anyone give a commom example of

a distributed system ?
- By running a distributed system software
the computers are enabled to:
a) Coordinate their activities
b) Share resources: hardware, software,
data.
Fig : An Example of a distributed system

Fig : Another example of a distributed system

Advantages of distributed systems
a) Performance - A collection of
processors can give a better performance
than a centralized computer
b) Distribution – Almost all applications work
on spatially separated machines
c) Reliability – Building fault-tolerant systems
i.e. if some systems crash, the system can
still survive.
d) Incremental Growth – Incrementally adding
new machines as new requirements come
Advantages of distributed systems
Contd…
e) Sharing of data/resources
f) Communication
- Eases more human-to-human
communication
Disadvantages of distributed systems
a) Difficulties in developing distributed
software
- Operating Systems
- Programming languages &
- Applications
b) Networking problems
- Network Infrastructure
- Losing messages, packets etc..
- Overloading
Disadvantages of distributed systems
contd…
c) Security problems
- Sharing initiates problems of data and
information security
Issues in a nutshell
1) Transparency
2) Communication
3) Performance and Scalability
4) Heterogeneity
5) Openness
6) Reliability and Fault tolerance
7) Security
Documentation
Agenda
- What is documentation, its types, ways
to implement software documentation
and reasons as to why it is required
- Documentation requirements
- Process and Product documentation
- Document Quality
- Standards
- Document Preparation &
- Document Storage
Documentation
Documentation Requirements
General requirements of all software
documentation
1) Provide communication among
members of the team
2) Should act as an information repository
used by maintenance engineers
3) Provide enough information to the
management
Documentation
4) Explain to users as to how they should
operate and administer the system
5) Creating some documentation before
code is generated (Guess ???)
6) Documentation continued even after
code has been generated(Guess ???)
7) Two main types of documentation
- Process documents &
- Product documents
Documentation
Process documentation
- Generated for the purpose of recording
and tracking the development process
a) Planning documentation
b) Cost, Schedule, Fund tracking
c) Schedules
d) Standards etc…
- Process documentation allows
successful management of a software
product
Documentation
- Gets a relatively short life-span
- Very vital to have knowledge about the
internal development processes
Product documentation
- Describes the delivered product
- Should evolve with the development of
the software product
- Two main categories
1) System documentation &
2) User documentation
Documentation
1) System documentation
- Describes how the system/application
works but not how to operate it
Examples
a) Requirement Specs
b) Architectural design
c) Detailed design
d) Commented source code(includes output
such as javadoc)
e) Test plans(includes test cases)
Documentation
f) V & V plan and results
g) Known bugs and errors etc…
2) User documentation
- Two types
a) End user
b) System administrator
Documentation
Important areas that need to be
documented for a formal release of a
software application
1) Functional description of the software
2) Installation instructions
3) Introductory manual
4) Reference manual
5) System administrator’s guide
Documentation
Document Quality
- Deals with providing a thorough and
professional documentation
- Most of the software professionals lack
writing skills in creating professional
level documents
Documentation
Document Structure
- Good to always have a standard uniform
structure to represent documentation
- The IEEE standard for user
documentation is the most widely
accepted model which possesses all the
documents any software application
would require
- There are certain best practices for
authors who perform documentation
Documentation
Author’s Best Practices for
Documentation
1. Put a cover page on all documents
2. Divide documents into chapters with
sections and subsections
3. Add an index if there is lots of
reference information
4. Add a glossary to define ambiguous
terms
Documentation
Standards
- Play a pivotal role in development,
maintenance and usefulness of
documentation
- Act as a basis for quality documentation
Three types of documentation
standards
a) Process
b) Product &
c) Interchange
Documentation
a) Process Standards
- Defining the approach that is to be
used when creating the
documentation
- Not defining any of the contents of
the documents
Draft
Peer Reviews
Revise Check
Documentation
b) Product Standards
- The objective of having a product
standard is to make the specific
product attain a consistent
structure and appearance
- This can be prepared based on
organizational or contractually
required standards
Documentation
c) Interchange Standards
- Creating documents in a format which
allows others to effectively use
a) pdf format for end users
b) Using a word editor for text editing
c) Use of specialized case tools
- Not a problem within one specific
organization, but when data is shared
between organizations, integration
problems are manifold
Documentation
Other Standards
- IEEE template for user documentation
- Writing Style(Ten best practices)
Online documentation
- Internal to the application or web-based
- Change in presentation style since
presenting information on normal paper
is different from presenting on the
internet
- Would act as a supplement to paper
documentation
Documentation
Eg: Using Web-docs are beneficial as they
give current information about the
application
Document Preparation
a) Talks about the entire process of
creating and formatting the document
for publication
- Using specialized tools for document
preparation and publishing
- Vital for user documentation
Documentation
b) Hiring a professional writer or
document publisher to evaluate your
documents before it is published for quality
purposes i.e. would look well on paper
Document Storage
- Using file systems
- Good databases with metadata to help
searching and referencing
- Using a content management system like CVS
or subversion (Free/Open Source, easy to
maintain)
Documentation
- In order to use the developed software
properly and to maintain it effectively
over a period of time, documentation
becomes a mandatory component
Note :
Jackson System Development
Objective
- To understand the Jackson’s method of
system development
- Developed by Michael Jackson
- A systematic technique for mapping the
structure of a problem into a program
structure to solve a typical problem
Three Phases of JSD
a) The modeling phase
b) The network phase &
c) The implementation phase
a)Modeling Phase
- Identification of events and entities
- Forming entity structures and life
cycles
b) Network Phase
- Adding the necessary inputs and
outputs to the model identified in
phase (a).
c) The Implementation Phase
- Detailed design and coding
- Facilitating the specification(model
and function) to run on the hardware
Modelling phase – Analysis phase-SDLC
1. Entity/Action step
2. Entity structure step
3. Model process step
Networking phase – Design phase-SDLC
4. Initial model step
5. Function step
6. System timing step
Implementation phase – Coding-SDLC
7. Physical system specification step
Highlights of JSD
- Impact on teaching and practice of
commercial computer programming
- Designing effective and efficient well-
tested software
- Has links with formal methods of
software development
- Used in applications where efficiency is
top priority
Fundamental Principles of JSD
1) Describe and model the real world
2) Build models that follow the sequence
of the real world
3) Transforming the specification to
efficient set of processes
JSD - Example
• A university gives loans to students.
Before getting a loan, there is an
evaluation process after which agreement
is always reached. A TE transaction
records each step of the evaluation
process, and a TA transaction records the
overall loan agreement. A student can
take any number of loans, but only one
can be active at any time. Each loan is
initiated by a TI transaction.
JSD - Example
• Then, the student repays the loan with a
series of repayments. Each repayment
transaction is recorded by a TR
transaction. Finally, a loan is terminated
by a TT transaction.
• Two output functions are desired: (1) an
inquiry function that prints out the loan
balance for any student, and (2) a
repayment acknowledgment sent to each
student after payment is received by the
university.
JSD - Example
Modeling Phase
Step 1 : Entity/Action step
Entities in the Application
a) Student
b) System
c) University
d) Loan
e) Student-loan
JSD - Example
Actions/Attributes in the Application
a)Evaluate
- University performs the evaluation on
the student based on the following
attributes like student-id, loan-no,
date of evaluation, remarks etc…
b) Agree
- University agrees to give loan, student
also agrees to take loan based on
attributes like student-id,
JSD - Example
- loan-no, date of agreement, amount of
loan, interest rate and repayment
period etc…
c) Make loan
- Make a formal application to execute
the loan
d) Initiate
- University initiates loan, student also
initiates the loan with attributes like
student-id, date-initiated etc…
JSD - Example
e) Repay
- Loan in repaid, student repays the
loan with attributes like student-id,
date of repayment, amount of
repayment etc…
f) Terminate
- The loan gets terminated using
attributes like student-id, date of
termination, remarks etc…
JSD - Example
Step 2 : Entity Structure step
- This step expresses the constraints in
the ordering of an entity’s actions with a
structure diagram
JSD - Example
Step 3 : Model Process Step
- Creating an executable model process for each
entity in the system
- Each model process is described with a system
diagram
Note:
- JSD models each real-world entity i.e. modeling
each entity precisely as it exists in the real
world
- Have to establish a connection between the
entity in the real world and the entity model
process in the designed information system
JSD - Example
Suffixing a -0 to the student entity indicates that this entity is an

abstract one in the real world and suffixing -1 indicates the
realization of this abstraction in the information system that is
about to be designed.
The entity model process for the student entity should be

described by a simple program that reads a serial data stream
i.e. Use JSP(Jackson Structured Programming) to write the
program text for this process.
• STUDENT-1 seq
JSD - Example
read S;
EVAL iter (while TE)
process TE; read S
EVAL end
AGREE seq
process TA; read S
AGREE end
LOAN-PART iter (forever)
INIT seq
process TI; read S
INIT
REPAY iter (while TR)
process TR; read S
REPAY end
TERM seq
process TT; read S
TERM end
LOAN-PART end
STUDENT-1 end
JSD - Example
Network Phase
- Connecting model processes and
functions with a SSD(System
Specification Diagram)
- The student application that is about to
be designed has two functions as listed
below
a) Loan balance enquiry function &
b) Payment acknowledgement lister
function
JSD - Example
SV- State Vector ; DT- Daily Time; ACK – ACKnowledgment; PAL- Payment
Acknowledgment Lister ; S – Serial ; E- Enquiry; R- Result
Figure : System Specification Diagram

JSD - Example
Implementation Phase
- Identifying the timing constraints of the
system
- The inquiries to the student should be
answered on-line but repayment
acknowledgments should be presented
at the end of the day
- Look for possible hardware and software
for implementing the system
- Taking a few decisions like
JSD - Example
a) Implementing all student processes
on a single processor
b) Allocating each student process, a
dedicated processor if required
- Depending on the hardware and timing
constraints, we design the SID(System
Implementation Diagram) for the
application designed
JSD - Example
S – Serial; Enq – Enquiry; DT- Daily Time; SV- State Vector; PAL - Payment
Acknowledgment Lister
Fig : System Implementation Diagram

JSD - Example
Design for Reuse
Agenda
- Introduction to reuse
- Benefits and issues for reuse
- Layers/Levels of reuse
Design for Reuse
a) Defining reuse
b) Design for reuse and reuse of
design
c) Purpose and state of the practice in
software engineering
Design for Reuse
Design for Reuse
Design for Reuse
Design for Reuse
Design for Reuse
Approaches that support reuse at the
system Level
1) COTS(Commercial,Off-The-Shelf)
product reuse
2) ERP(Enterprise Resource Planning)
systems
3) Software product lines
4) Configurable vertical applications
Design for Reuse
Approaches that support reuse at
the architectural level
1)Architectural patterns
- used in standard software
architectures
2) Application frameworks
- packages and classes at the system
level
3) Legacy system wrapping
Design for Reuse
- providing interfaces to old code
4) Service-oriented systems
- shared services(third-party)
Reuse at design level
a) Object orientation
b) Design patterns
c) Model-driven programming
d) Aspect Oriented Software Development
e) Component-based development
Design for Reuse
Approaches that support reuse at
the implementation level
1) Program libraries and API’s(Application
Programming Interfaces)
- set of reusable artefacts
2) Program generators
- code generators
Programming Standards
Agenda
- Standards for Programming
- Guidelines for Re-use
- Using Design to frame the Code
- Internal Documentation
- External Documentation
Coding Issues
- Designers not addressing the
idiosyncrasies of the platform and
programming environment i.e.
structures and relationships that are
represented as charts and tables are
not straightforward to write as code
- Writing code understandable to us as
well as others while the software
evolves over time
• Use data structures and programming
language constructs as effectively as
possible to always create reusable code
Programming Standards and
Procedures
- Every organization has its own programming
standard. We need to know the standards
before we start writing code
- Every Organization insists that their code
conform to style, format and content
standards
i.e. making the code and the associated
documents written clearly for
everyone who reads them
Standards for Self
- The following are a few standards and
procedures which gives large benefits
a) Organizing one’s thoughts and avoiding
mistakes
- Good methods of documenting
code, clear and everyone follows
- Good documentation allows us to keep
track of our work and not losing out
- Using standardized documentation in
locating faults and making changes
b) Help in translating design to code
- Possibility of errors is minimized
Standards for Everyone
- Use of code by others in a variety of
ways
- Essential to organize, format and
document our code, make it easy for
others to understand i.e. what it does
and how it works
The most important standard
- Need for a direct correspondence between
the program design and the program code
The entire design process is of little value if the
design’s structure is not carried forward into
the code
The design characteristics , such as low
coupling, high cohesion, and well-defined
interfaces should also be program characteristics
Any change to the program should be made first
to the high-level design and then are traced
through lower design levels to the code
Programming Guidelines
Each program component involves
At least three major aspects: control
structures, algorithms, and data structures
1. Program structure should reflect
the design
Many of the control structures are suggested
by the architecture and design
In the more procedural designs, control depends
on the structure of the code itself
It is important for your program to reflect
the design’s control structure
Many guidelines and standards suggest that the
code be written so you can read it easily
It is helpful whenever possible to have the
required action follow soon after the decision that
generates it
2. Modularity is a good design attribute
By building a program from modular blocks,
we can hide implementation details at different
levels
Making the entire system easier to understand,
test and maintain
We can use macros, procedures,
subroutines, methods and inheritance to
hide details
While enhancing understandability
3. Generality is a virtue
In writing your code, keep in mind that
generality is a virtue
Do not make your code more specialized than it
needs to be
Do not make your components so general that
performance and understanding are affected
4. Naming Conventions
Use global variables as less as possible
Indicate clearly the parameters being passed to
and back
Dependence among components must be visible
Components should hide calculation details
5. Algorithms
• Take great discretion in performance
 Or efficiency of your implementation
 Making the code faster may involve hidden costs
The cost to write and modify the faster code
The cost and time to test the code
The cost of time for users to understand
you should balance execution time with
design quality, standards and customer
requirements
Compiler may make your seemingly faster
optimized code actually slow down
6. Data Structures
Make data format or store straightforward
Keeping the program simple
Data manipulation can influence your choice of
data structures
 The calculation are simplified just by changing the way
the data are defined
 This makes the program easier to understand, test and
modify
Using data structures to determine a
program structure
Data structures can influence the organization and
flow of a program, including the choice of language
7. Formatting Conventions
- Know all the rules for formatting code,
how, when etc…
8. Licensing guidelines
- Getting to know how to get rights for the
pieces of code created i.e. all proprietary
software have their code secure
9. Documentation
Program documentation
The written description that explain what the
programs do and how they do it
Internal documentation
The descriptive material written directly within
the code
External documentation
All other documentation
• Other program comments
Meaningful variable names and
statement labels
Formatting to enhance understanding
Proper indentation and spacing of
statements to reflect the basic control
structure
Documenting data
Case Study of Design of any
Application Project
Lemonade System Case Study

Unit II - Software Design

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unit II - Software Design

Hochgeladen von

Copyright:

Verfügbare Formate

UNIT II - SOFTWARE DESIGN

Unit II – Software Design

(Class-based model, Flow-oriented model

(Scenario-based model, Flow-oriented model

(Class-based model, Flow-oriented model)

(Class-based model, Behavioral model)

Behavioral Data design

implemented with a "knowledge" of the

implemented as a data structure

a)Structural properties. This aspect of

c)Families of related systems. The

– It provides a description that enables a

• Architecture is a set of well-identified

- A cohesive module is one where the

Coincident Logical Temporal Procedural Communic Sequential Functional Informati

- Elements of a module Function Function

perform functionality Function Function

Example for Coincidental Cohesion

Example for Procedural Cohesion

bundling of data takes

- If the controlled module is Display

1) Many people Global data

global variable record Update

high coupling low coupling

Fig : A hierarchy chart for an inventory

Fig : An Overview diagram for Process 2.0

Fig : A detail diagram for Process 2.0

do: get C C do: initialise

Hose out of holster

do: display Validating Ready Delivering

Timeout Invalid card

Can anyone give a commom example of

Fig : An Example of a distributed system

Fig : Another example of a distributed system

Suffixing a -0 to the student entity indicates that this entity is an

The entity model process for the student entity should be

Figure : System Specification Diagram

Fig : System Implementation Diagram

Lemonade System Case Study

Das könnte Ihnen auch gefallen