Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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)
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)
Vertical
Layers Domain
Technical Services
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()
...
: Cashier
actionPerformed( actionEvent )
UI Layer :SaleJFrame
: Register : Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered) : Payment
Collaboration Diagram
direction of message
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
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
endSale
Conditional Message
: Foo : Bar
xx
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.
: Foo : Bar
xx
loop(n)
calculate
Collaboration Diagram
Messages
msg1
1: msg2
2: msg3
3: msg4
: Register :Sale
3.1: msg5
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
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
Service
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
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.