The document discusses the design and analysis of real-time and distributed systems, highlighting important concepts such as modularity, information hiding, and state-oriented notations like Petri nets. It also emphasizes the significance of milestones, walkthroughs, and inspections in software development, detailing the roles of various testing methods, including functional, performance, stress, and structural tests. The document concludes with a focus on the necessity of a well-defined test plan to ensure software meets its requirements.

1. Submitted by,
M. Shanmugapriya, II-M.Sc.(CS & IT),
S. Suryakala, II-M.Sc. (CS & IT).
M. Surya, II-M.Sc.(CS & IT),
Nadar Saraswathi College of Arts & Science, Theni.
REAL TIME AND DISTRIBUTED
DESIGN & MILESTONES,
WALKTHROUGHS, AND
INSPECTIONS, TEST PLANS

2.  In Software Engineering, many of the popular
design “methodologies” were developed as design
techniques for application programs, operating
systems and utility programs(compilers, editors,
loaders, etc.).
 These methods support concepts such as
hierarchical decomposition, modularity, information
hiding, and data abstraction.
 These design concepts are important for real time
and distributed systems.
REAL TIME AND DISTRIBUTED
DESIGN

3.  A Distributed system consists of a collection of
nearly autonomous processors that communicate to
achieve a coherent computing system.
 Each processor possesses a private memory, and
processors communicate through an interconnection
network.

4. Major issues to be addressed in designing a
distributed system includes,
 Specifying the topology of the communication
network
 Establishing rules for accessing the shared
communication channel
 Allocating application processing functions to
processing nodes in the network
 Establishing rules for process communication and
synchronization.
ISSUES

5.  Real time systems must provide specified
amounts of computation within fixed time intervals.
 Real time systems typically sense and control
external devices, respond to external events, and
share processing time between multiple tasks.
 Real time systems often form distributed
networks; local processors may be associated with
sensing devices and actuators.
REAL TIME SYSTEMS

6.  A Real time network for process control may
consist of several minicomputers and
microcomputers connected to one or more large
processors.
 Each small processor may be connected to a
cluster of real time devices.
 Decomposition criteria for distributed real time
systems include the need to maintain process
simplicity and to minimize inter-process
communication bandwidths by communicating
simple processed messages rather than raw data.

7. Several notations have been developed to
support analysis and design of real time and
distributed systems.
They include RSL, SDLP, NPN, communication
ports
State Oriented
Most of these notations are state-oriented
because a real-time system can be thought of as
possessing a(perhaps large) number of processing
states, with the transitions between states triggered by
external stimuli.
NOTATIONS

8. Petri Nets
 Petri nets are a fundamental state-oriented notation
that can be used to specify requirements and high level
design of real-time and distributed systems.
 Petri nets were developed because traditional finite
state mechanisms are not adequate for specifying
parallel and concurrent system properties.

9.  The traditional considerations of hierarchy,
information hiding, and modularity are important
concepts for the design of real-time systems.
 However, these concepts are typically applied to the
individual components of a real-time system.
 Higher-level issues of networking, performance,
and reliability must be analyzed and designed before
the component nodes or processes are developed.
SUMMARY OF REAL TIME
SYSTEMS

10. Milestones,Walkthroughs,
And Inspections

11.  One of the most important aspects of a
systematic approach to software development is
the resulting visibility of the evolving product.
 The system becomes explicit, tangible and
accessible.
 The evolving User’s Manual, architectural
design specification, detailed design specification
and the test plan.
MILESTONES

12. Two major milestone during software design
(i) Preliminary Design Review(PDR)
(ii) Critical Design Review(CDR)
The PDR is typically held near the end of architectural
design and prior to detailed design.
CDR occurs at the end of detailed design and prior to
implementation.
Functional characteristics, performance attributes,
external interfaces, user dialogues, report formats, exception
conditions and exception handling product subsets, future
enhancement to the product should all be reviewed during the
PDR.
MAJOR PARTS OF
MILESTONE

13.  A structure walkthrough is an in-depth, technical review
of some aspect of a software system.
 Walkthrough can be used at any time, during any phase
of a software project.
 Thus, all or any part of the software requirement ,the
architecture design specification, the detailed design
specification.
 The test plan, the code ,supporting document, or a
proposed maintenance modification can be reviewed at any
stage of evolving
 Walkthrough term consists of four to six people .
WALKTHROUGHS

14.  Design inspections are conducted by terms of trained
inspectors who work from checklist of terms to examine
 A typical design inspection term consists of a
moderator/secretary, a designer, an implementer, and a tester.
 The designer ,implementer ,and tester may or may not
be the people responsible for actual design, implement and
testing of product inspection.
 Term member are trained for their specific roles and
typically conduct two 2-hour per day.
 In one experiment 67 percent of the error.
 Another experimenter reported 70 percent error.
INSPECTION

15.  The test plan is an important, but often
overlooked , product of software designs. A test plan
prescribes various kinds of activities that will be
performed to demonstrate that the software product
meets its requirements.
 The test plan specifies the objectives of testing.
The test completion criteria the system integration
plan methods to be used on particular modules and
particular test cases to be used.
TEST PLANS

16.  Functional Test
 Performance Test
 Stress Test
 Structural Test
FOUR TYPES OF TESTS THAT A
SOFTWARE PRODUCT MUST SATISFY.

17.  Functional tests and performance tests are based on
the requirements specifications; they are designed to
demonstrate that the system satisfies its requirements.
 Functional test cases specify typical operating
conditions, typing input values, and typical expected results.
 Functional tests should also be designed to test
boundary conditions just inside and just beyond the
boundaries.
e.g.., square root of negative numbers, inversion of one-
by –one matrices ,etc.
FUNCTIONAL TEST

18.  Performance tests should be designed to verify
response time, execution time, throughput, primary and
secondary memory utilization and traffic rates on data
channels and communication links.
 Each functional and performance test should specify the
machine configuration, assumptions concerning the system
status for the test case, the requirements being tested , the
test inputs and the expected results.
PERFORMANCE TEST

19.  Stress tests are designed to overload a system in various
ways, such as attempting to sign on more than the maximum
allowed number of terminals, processing more than the
allowed number of identifiers or static levels, or
disconnecting a communication link.
 The purpose of stress testing are to determine the
limitations of the system and, when the system fails, to
determine the manner in which the failure is manifest.
 Stress tests can provide valuable insight concerning the
strengths and weaknesses of a system.
 Stress tests are derived from the requirements, the
design, and the hunches and intuitions of the designers.
STRESS TEST

20.  Structural tests are concerned with examining the
internal processing logic of a software system.
 The particular routines called and the logical paths
traversed through the routines are the object of interest.
 The goal of structural testing is to traverse a
specified number of paths through each routines in the
system to establish thoroughness of testing.
STRUCTURAL TEST