Sei sulla pagina 1di 80

Introduction to Software

Design
Design is Important
• It provides the basic framework in which the program
code are to be written and personnel are to be assigned
to the work.
• Design error outweigh coding errors; i.e., they are more
in number than the coding error.
• They take more time to detect and correct than the
coding.
• Compared to coding they are costlier to correct.
• They provide a basis for monitoring the progress.
• Good design helps in creating reliable, flexible and
maintainable software.
• The larger the system and the larger the number of
developers involved, the more important the design
becomes
Design and Coding Errors
(Boehm et al., based on a study of 220 errors)

Design Errors Coding Errors

Total 64% 36%

Average 3.1 hours 2.2 hours


Diagnostic Time
Average 4 hours 0.8 hours
Correction Time
Objectives of a good
design architecture
• The functional objective: Deliver the functionality
required by the user.
• Non-functional (quality) objectives:
– Directly quantifiable requirements
• Performance Parameters such as response time, throughput time,
down time
• Crudely quantifiable quality characteristics such as coupling and
cohesion.
• Difficult to quantify requirements, such as safety and security.
– Non-quantifiable requirements
• User interface related and quality attribute, such a user friendliness,
robustness and reliability
• Long-term behavior related properties such as maintainability,
modifiability, extensibility, reusability.
Design Consists of
• Program Design
– Structured Design
– Object Oriented Design
• Database Design
• User Interface Design
Basic Principles of Program Design
• Abstraction
• Divide and conquer concepts
• Control Hierarchy
• Principle of Information Hiding
• Principle of Localization
Abstraction
• The process of forming a general concept as
separate from the particular instance.
• Levels of Design
– The architectural design
• High level : only general structure
• Decomposition into subsystems with interfaces
• Verification against the software specification
• Architectural review and design baseline
– The detailed design
• Allocation of requirements to modules
• Specific algorithms and data structures for each module
(subsystem)
• Verification against requirements and baselined architectural
design
• Baselining the detailed design
Divide and Conquer
• Dividing a problem to smaller and
independent sub-problems.
– Functional decomposition
– Module interfaces
• Parameter passing
• Protocol governing the communication between
the modules
Control Hierarchy
• Control flow among the modules
• The idea behind structured design
Information Hiding
• Independent modules communicating only for
that information that is necessary for the
software function
• Advantages
– Ease of coding
– Ease of Testing
– Avoidance of error propagation
– Multilevel functional decomposition
• Stepwise refinement: The process of hierarchical
decomposition
– Modularity
• Module: The basic unit of in software architecture
Principles of Localization
• All logically related items should be placed
physically close to one another
• Principle applies to both data sets and the
program sets.
Top-down design
• Stepwise refinement
• Most general to special sub-functions
• Guidelines
– While breaking components into parts, the
components within each part should be
logically related
– Alternative designs are considered
– As little decision as possible at each step.
Principles of Top-Down Design
• Specification of input, process, and output
for each module at each design step
• Implementation issues are not addressed
till late in design process
• Brief description for each module
• Careful specification of interfaces
Introduction to Object
Oriented Design
Analysis Phase Revisited
• Defining use cases
• Use case diagram
• System sequence diagram
• Conceptual Model (Analysis Class
Diagram)
• CRC Cards
• Operation Contracts
• State Diagrams
Sample UP Artifact Relationships
Domain Model

Sale 1 1..* Sales


Business ...
LineItem
Modeling
date
...
... quantity

Vision
Use-Case Model

Process Sale
Process
Sale
use 1. Customer
case arrives ...
Cashier
names 2. ...
3. Cashier
enters item
identifier. Glossary
Require-
Use Case Diagram Use Case Text
ments
ideas for system
the domain events requirements
the post-
objects, that must be
conditions
attributes, satisfied by
: System
and the software
associations Operation: : Cashier
that undergo enterItem(…) make Supplementary
changes system NewSale() Specification
Post-conditions: operations
enterItem
-...
(id, quantity)

Operation Contracts System Sequence Diagrams


starting events to
design for, and
more detailed
requirements that Design Model
must be satisfied : Register : ProductCatalog : Sale
by the software
enterItem
Design (itemID, quantity)

spec = getProductSpec( itemID )

addLineItem( spec, quantity )


Activities Carried out in OOD
• Developing real use
• Drawing interaction diagrams
• Assigning responsibility to objects
• Determining visibility
• Drawing design class diagrams
• Deciding on architectural issues
Developing Real Use cases
• A real use case describe the real or actual
design of the use case in terms of
concrete input and output technology and
its over all implementation
• Diagrams, story boards,
• Interface widgets (window objects)
Drawing Interaction Diagrams
• Interaction Diagrams
– Collaboration diagrams
– Sequence diagrams
• Drawn on the basis of conceptual model
(analysis class diagram)
• Show the choices in assigning responsibility to
objects
• Decision for assigning the responsibilities are
based on the flow of massages between the
interacting objects.
• Use of patterns
Responsibilities and Methods
• Responsibility is defined as a contract or obligation of a
type or a class
• Responsibilities are related to the obligations of an
object in terms of its behaviour
• Two types of responsibility
– Doing
• Doing something itself
• Initiating action in other objects
• Controlling or coordinating the activities in other objects
– Knowing
• Knowing about private encapsulated data
• Knowing about related objects
• Knowing about the things it can derive or calculate
– Ex: Sale is responsible for printing itself (doing)
Sale is responsible for knowing its date
Transition from Analysis to Design
• Iterative analysis and design
• Early identification of changes in
requirements
Logical Architecture, Layers and partitions
• The logical architecture is the large scale organization of the
software classes into packages (or namespace), subsystems and
layers.
– It is called logical architecture because at this stage there is no decision
about how these elements are deployed across different operating
systems processes or across physical computers in the network.

• A layer is a very coarse grained grouping of classes, packages, or


subsystems that has cohesive responsibility for the major part of the
system

Typical layers in an OO system includes


– User interface
– Application logic and domain objects
– Technical service
• The layers of an architecture represent vertical slices, while
partitions represent a horizontal division of the relatively parallel
subsystems of a layer.
An UML Package Diagram
UI

not the Java


Swing Swing libraries, but Web
our GUI classes
based on Swing

Vertical
Layers Domain

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Horizontal Partitions
Model View Separation Principle
• MVS Principle states that model objects
should not have direct knowledge of view
objects (User Interface).
Relationship between SSD and
Layers
• SSD illustrates specific system operation
but hide specific UI layer of the system
that captures this system operation
requests.
• UI objects actually delegates these
requests to the domain layer for handing.
UI

Swing makeNewSale()
:System enterItem()
Cashier ProcessSale endSale()
...
Frame
makeNewSale()
: Cashier
enterItem(id, quantity)
makeNewSale()
description, total enterItem()
endSale()
Domain

endSale()
... Register

makeNewSale()
enterItem()
...

the system operations handled by the system in an SSD represent the


operation calls on the Application or Domain layer from the UI layer
presses button

: Cashier

actionPerformed( actionEvent )

UI Layer :SaleJFrame

system operation message


enterItem(itemID, qty)

Which class of object should be responsible for receiving this


Domain system event message?
: ???
Layer
It is sometimes called the controller or coordinator. It does not
normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from


the interface layer.
Dynamic Object Modeling
• Modeling communication between the
objects
• Identifying methods
• UML Interaction Diagrams
– Sequence diagram
– Collaboration diagrams (communication
diagrams)
Sequence Diagram

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)
create(cashTendered) : Payment

Collaboration Diagram

direction of message

makePayment(cashTendered) :Register 1: makePayment(cashTendered) :Sale

1.1: create(cashTendered)

:Payment
Messages

: Register : Sale

doX
doA

doB
a found message
whose sender will not
be specified doC

doD

execution specification
bar indicates focus of
control typical sychronous message
shown with a filled-arrow line
Reply OR Return

: Register : Sale

doX
d1 = getDate

getDate
aDate
Message to self/This

: Register

doX
clear
Creation

note that newly created


: Register : Sale
objects are placed at their
creation "height"

makePayment(cashTendered)
create(cashTendered) : Payment

authorize
Object Destruction

: Sale

create(cashTendered)
: Payment
the «destroy» stereotyped
... message, with the large
X and short lifeline
«destroy» indicates explicit object
X destruction
Frame
loop :A :B
makeNewSale

a UML loop loop [ more items ]


enterItem(itemID, quantity)
frame, with a
boolean guard
expression description, total

endSale
Conditional Message

: Foo : Bar
xx

opt [ color = red ]


calculate

yy
Mutually Exclusive Conditional Message

:A :B :C

doX

alt [ x < 10 ]
calculate

[ else ]
calculate
Iteration over a collection

lineItems[i] :
: Sale This lifeline box represents one
SalesLineItem
instance from a collection of many
t = getTotal SalesLineItem objects.

lineItems[i] is the expression to


loop select one element from the
[ i < lineItems.size ]
st = getSubtotal collection of many
SalesLineItems; the ‘i” value
refers to the same “i” in the guard
i++
in the LOOP frame

an action box may contain arbitrary language


statements (in this case, incrementing ‘i’)

it is placed over the lifeline to which it applies


Nesting of Frames

: Foo : Bar
xx

opt [ color = red ]

loop(n)
calculate
Collaboration Diagram
Messages

msg1
1: msg2
2: msg3
3: msg4
: Register :Sale
3.1: msg5

all messages flow on the same link


Design Class Diagram
Domain Model Sale
Register Captures 1
1
time
conceptual
... isComplete : Boolean
perspective
/total

Register Sale
Design Model ... time
1
isComplete : Boolean
DCD; software endSale() currentSale /total
perspective enterItem(...)
makePayment(...) makeLineItem(...)
Association in DCD
the association name, common when drawing a
domain model, is often excluded (though still legal)
when using class diagrams for a software
perspective in a DCD

Register Sale
Domain Model 1 Captures-current-sale 1
conceptual perspective id : Int time : DateTime

Design Model Register Sale


DCD 1
id: Int time: DateTime
software perspective currentSale
... ...
How to show methods
Register
«method»
// pseudo-code or a specific language is OK ...
public void enterItem( id, qty )
{ endSale()
ProductDescription desc = catalog.getProductDescription(id); enterItem(id, qty)
sale.makeLineItem(desc, qty); makeNewSale()
} makePayment(cashTendered)
A more complete DCD reflecting most
design decisions
Store

address : Address
catalog 1
name : Text
ProductDescription
ProductCatalog descriptions
addCompleteSale(...)
{Map} description : Text
... price : Money
1 1..* itemID: ItemID
catalog getProductDesc(...)
...

description 1
register 1 Sale
Register isComplete : Boolean
time : DateTime lineItems SalesLineItem
... currentSale {ordered}
becomeComplete() quantity : Integer
endSale() 1 1..*
makeLineItem(...)
enterItem(...) getSubtotal()
makePayment(...)
makeNewSale()
getTotal()
makePayment(...)
completedSales
{ordered} * Payment
payment
amount : Money
1
...
Three tier architecture and packaging
• The three tier architecture
– Presentation Layer
• Windows, reports etc.
– Application Layer
• Tasks or rules that governs the process
– Storage Layer
• Persistent storage mechanism
• Physical deployment
– Client-server environment
• Decomposition of Application Layer
– Domain Objects (Ex. Sale)
– Services (Ex. Database interface)
Packages
• Group of elements that provide a common
service (or a family of related services),
with relatively high coupling and
collaboration.
• At a higher level of abstraction the
elements are highly cohesive (strongly
correlated responsibility)
Architecture Package Diagram

Presentation
Presentation

Domain

Application

Service

Storage Database
Layers and Partitions of Packages
Domain

Core Sales Product


Elements
Layers

Service

Database Communic Security Reporting


Interface ation

partitions
Visibility between the packages
• Presentation packages have visibility into
many of the domain packages
• Presentation and domain packages have
visibility into only one or few classes in
each particular service package
• No domain or service package have direct
visibility into presentation layer (Indirect
Communication)
No Direct Visibility to Windows
The Model View Separation Pattern
• Problem: It is desirable to de-couple domain
(model) object from the windows (view) objects,
to support increased reuse of domain object and
minimize the impact of changes in the user
interface on the domain object. What to do?
• Solution: Define domain (model) classes so that
they do not have direct visibility to the windows
(view) classes, and the application data and
functionality remains with the domain classes,
not with window classes.
Motivation for Model-View separation model
• To support cohesive model definitions that focus on the
domain processes, rather than computer interfaces.
• To allow separate development of the model and the
user interface layers
• To minimize the impact of requirements changes on the
interfaces upon the domain layer
• To allow new views to be easily connected to an existing
domain layer, without affecting the domain layer.
• To allow multiple simultaneous views on the same model
object.
• To allow the model layer independent of the user
interface layer, such as in in a message processing and
batch mode system.
• To allow easy porting of the model layer to another user
interface framework.
How do the windows get the data?
• Polling or pull from above
– It is the responsibility of a window object to ask for the
relevant information from the other objects whenever
necessary.
– Most common form
– But fails when the information gets updated as a
result of the state change of the domain object (Ex.
stock price, Network monitoring system)
– Push-from-below model
• Publish Describe pattern
Indirect Communication in a System
Publish-Subscribe Pattern
• Problem: A change in state (an event) occurs
within a Publisher of the event and the other
objects are dependent on or are interested in
this event (Subscribed to the event). However,
the publisher should not have the direct
knowledge of its subscribers. What to do?
• Solution: Define an event notification system so
that the publisher can indirectly notify subscriber.
• Ex. Mouse Listener, Keyboard listener
Coding
Coding
• Input to the coding phase is the design
document.
• IEEE Recommended Practice for Software
Design Descriptions
IEEE Std 1016-1998
Coding Standards
• Uniform appearance of codes
• Encourages good programming practice
• Provides sound understanding of the code
• Increases maintainability
• Organizations develop their standards
Representative standards
• Rules for limiting use of the globals.
• Contents of the headers preceding codes for different
modules
– Name of the module
– Date when the module is created
– Author’s name
– Modification history
– Synopsis of the module
– Different functions supported, along with their input and output
parameters
– Global variables accessed/modified by the module.
• Naming conventions for global variables, local variables,
and constant identifiers
• Error return conventions and exception handling
mechanism
Representative coding guidelines
• Do not use a coding style that is too clever
or too difficult to understand.
• Avoid obscure side effects
• Do not use an identifier for multiple
purposes
• Code should be well documented
• Do not use goto statements
Code Review
• Carried out after the module is successfully
compiled and all the syntax errors are
eliminated.
• Code Walk-Through
– Discovering algorithmic and logical errors in the code
– Trace execution of the code using test cases
– Performed by some team members
• Code Inspection
– Discovering common types of errors caused due to
oversight and improper programming.
– Ex: Use of un-initialized variables, array indices out of
bound, allocation and deallocation of memory etc.
Software Testing
What is Software Testing
• Testing is an activity to uncover the errors
made during the analysis, design and coding
phases of the software development lifecycle
• Testing is a subset of a broader topic known
as verification and validation
• Debugging is the process of locating and
correcting the code during testing
Verification and validation
• The Checking processes which ensure that the software
confirms to its specification and meets the need of the
customer
– Validation: Are we building the right product?
– Verification: Are we building the product right?
• Verification and Validation also Includes
– formal technical review, quality and configuration audit,
performance monitoring , feasibility study, documentation review,
database review, algorithm analysis, development testing,
usability testing, qualification testing, installation testing
Testing Strategy
• The testing strategy is a road map that
describes the steps to be conducted as
part of testing.
• It must incorporate test planning, test case
design, test execution, result data
collection and evaluation.
Example: Program & test cases
• Program - Sort
• Specification
– Input: p - array of n integers, n > 0
– Output: q - array of n integers such that
• q[0]  q[1]  …  q[n]
• Elements in q are a permutation of elements in p,
which are unchanged
– Description of requirements of a program
Tests
• Test input (Test case)
– A set of values given as input to a program
– Includes environment variables
– {2, 3, 6, 5, 4}
• Test set
– A set of test cases
– { {0}, {9, 8, 7, 6, 5}, {1, 3, 4, 5}, {2, 1, 2, 3} }
Testing Strategy for Software

Area Where Conventional and


Object oriented software differ
Testing Strategies for
Conventional Software
Unit Test Environment

Driver
Test case
Module

Stub Stub

Results
Test case design considerations
• To uncover common type of computational
errors
• Error during comparison and control flow
• Boundary testing
• Evaluation of anti-debugging and error-
handling codes.
Integration Testing
• Testing the software architecture
• Incremental Vs Non-Incremental
• Incremental Approaches
– Top-down
– Bottom-up
– Regression Testing
Top-down Integration
Top-down Integration
• Advantages
– Early recognition of major control and decision points
– Early demonstration of functional characteristic
• Disadvantages
– No significant data flow upward in the program
structure
• Solution
– Delay many tests until stubs are replaced with real
modules
– Develop stubs that do limited functions
– Bottom-up approach
Bottom-up Integration
Regression Testing
• re-execution of some subset of tests that
have already been conducted to ensure
that changes have not been propagated
unintended side effects
• conducted manually, or by re-executing of
the subset of all test cases or using
automated capture and playback tools
Object-Oriented Software
Class Testing
• The concept unit testing in conventional
software is equivalent to class testing in
object-oriented system.
• During class testing each operation is unit
tested in the context of other operations of
the class.
• In conventional unit testing the focus is on
the algorithmic details of a module. In
class testing the focus is on the state
behavior of the class

Integration Testing
Object-oriented systems do not have a hierarchical structure hence
the concept of top-down and bottom up testing is not applicable.
• Integration of the methods within a class one at a time is also
impossible.
• Thread testing
– integrates the sets of classes required to respond to one input or event
for the system.
– Each thread is integrated and tested individually.
– Regression testing is applied to ensure that no side effect occurs.
• Use-based testing
– begins construction of the system by testing those classes (called
independent classes) that use very few server classes.
– After the independent classes are tested, the next layer of classes
called the dependent classes (which uses independent classes) are
tested.
– This process continues till the entire system is build.
• In cluster testing-
– a cluster or collaborating classes (determined by CRC and object
relationship model) is exercised by designing test cases that attempt to
uncover errors in the collaboration.
Integration Test Document
• Test Plan:
– Overall testing strategy
– dividing testing to phases and builds (clusters) that addresses
specific functional and behavioral characteristics
• Schedule for Integration
• Brief description of overhead software and special efforts
required
• Test environment & resources
– Hardware, simulators, tools and techniques
• Test Procedures
– Order of integration and specific tasks
– List of test cases
• Test Reports
Validation Testing
• Validation testing focuses on user visible
actions and user recognizable output from
the system.
• Reasonable expectations of the customers
are validated as specified in the SRS.
• Alpha testing is carried out by the
customer at developer site.
• Beta testing is carried out by the customer
at his site and not in a controlled
environment.
System Testing
• Testing the software product with other system
elements. ( H/W , people, into )
• Recovery testing
– Fault tolerance
– mean-time-to-repair (MTTR)
• Security testing
– For systems that handle sensitive information.
– To verify protection mechanism of the system.
– Making the penetration cost more than the cost of information.
• Stress testing
– Executing the system in a manner that demands the resources in
an abnormal quantity, frequency or volume.
• Performance testing
– For real time and embedded system
– Testing run time performance of a system in the context of
integrated system.

Potrebbero piacerti anche