Post on 12-Mar-2015
transcript
Page 1
UMBC, Slide 1Analysis and Design of Client/Server Systems
Analysis and Designof Client/ServerSystems
University of Maryland Baltimore CountyModule 6 for Bell Atlantic
Michael Grassograsso@cs.umbc.edu
UMBC, Slide 2Analysis and Design of Client/Server Systems
Objectives
Module ObjectiveTo acquaint the participant with software analysis and design, with anemphasis on applications in client/server environments.
TextbookSoftware Engineering by Ian Sommerville, 5th Edition.Essential Client Server Survival Guide by Orfali
In-Class ExercisesAs individuals or teams, create data flow and/or control flow models for asample application, using the standard notations. As individuals or teams,given a design document for a small system, modify that diagram to suit asmall set of new requirements.
Module Completion RequirementThe participant will be required to demonstrate familiarity with principles ofsystems analysis and design, including the ability to read and understanddiagrams developed using one of the techniques listed.
Page 2
UMBC, Slide 3Analysis and Design of Client/Server Systems
Outline
Section 1: Introduction to Software Analysis and Design Slide 4• Introduction and basic principles• Software methodologies• Requirements specification• CASE tools for analysis and design• Client/Server Systems• Architectural design
Section 2: Analysis and Design Techniques Slide 49• Functional Approaches• Data-Driven Approaches• Behavioral Approaches
Reading List• Software Engineering Chapters 4,7,8,12,13,15,16,25• Client Server Survival Guide Chapter 29
UMBC, Slide 4Analysis and Design of Client/Server Systems
Session 1: Analysis and Design
Introduction and basic principles
Software methodologies
Requirements specification
CASE tools for analysis and design
Client/Server systems
Architectural design
Page 3
UMBC, Slide 5Analysis and Design of Client/Server Systems
A Software Crisis
A 1979 GAO report (FGMSD-80-4, 11/79) evaluated 7 million dollarsworth of software development projects and discovered that as apercentage of cost:
• 47% were never used• 29% were never delivered• 19% required extensive reworking or were abandoned• 3% required additional modifications• 2% met its requirements
Tom DeMarco pointed out in 1982 that 25 percent of large systemdevelopment projects never finish. (Controlling Software Projects,Prentice Hall, 1982)
Capers Jones documented in 1991 the gloomy statistic that the averageMIS development project is one year late and 100 percent over budget.(American Programmer, 6/91)
UMBC, Slide 6Analysis and Design of Client/Server Systems
What is Analysis
Analysis is the process of extracting theneedsof a system -what thesystem should do, not how the system will be implemented.
It is theproblem-oriented (not the solution-oriented) phase in thesoftware engineering process.
Although we have a natural affinity toward results-oriented tasks (e.g.,design), we need to focus more on the problem to avoid treating merelythe symptoms and to provide an unbiased view of the situation. (GeorgeWedberg, But First, Understand the Problem, ASM Journal of SystemsManagement, page 22-28, 6/90)
The risk of mortality ... increases when treatment is begun before aspecific diagnosis has been reached. (The Merck Manual, 13th Edition,page 765, 1977)
Page 4
UMBC, Slide 7Analysis and Design of Client/Server Systems
Analysis vs. Design
Analysis
• Goal is understanding
• Activities• Problem analysis (activity is decomposition)• Writing the SRS (activity is behavior description)
Design
• Goal is optimization
• Activities• Preliminary design (activity is decomposition)• Detailed design (activity is behavior description)
UMBC, Slide 8Analysis and Design of Client/Server Systems
Analysis Challenges
Problem Domain Understanding• To design an accounting system, an analyst needs to become an
expert in accounting systems, and will probably need to understandthese systems better than the average user will.
Person-To-Person Communication• It is very difficult for people from different perspectives to share
ideas with each other. For example, an analyst and a user, or amanager and a worker.
Continual Change• Requirements will change. Your designs need to account for
change and should attempt to minimize their effect.
Reuse• Reuse of code as well as design and analysis results.
Page 5
UMBC, Slide 9Analysis and Design of Client/Server Systems
Factors Influencing Software Development
Walston and Felix compared several development efforts to identifythose factors having the greatest impact on that process as a function ofthe number of lines of code written per month.
1. Low User Interface Complexity.• 500 lines vs. 124 lines.
2. User Plays a Limited Role in Requirements Definition.• 491 lines vs. 205 lines.
3. Experienced Programming Team.• 410 lines vs. 132 lines.
Other factor such as design and programmingmethodologieshad apositive effect, but not as great. IBM Systems Journal, 1977, 16(1).
UMBC, Slide 10Analysis and Design of Client/Server Systems
Waterfall Life Cycle
Developed in the 1960s, the waterfall life cycle is still the mostcommonly practiced approach to software development.
Problems with the Waterfall approach.• Linear, with one activity at a time.• Based on paper.• No demonstrable results until code is produced.• Depends on stable, correct requirements.
RequirementsAnalysis
Design
CodeFinished Product
Test
Page 6
UMBC, Slide 11Analysis and Design of Client/Server Systems
Variations on the Waterfall Approach
The traditional waterfall presumes a basic linear approach where oneactivity must finish before the next begins.
The timing for these actives can be modified in the following way.• Conservative, linear approach with no overlap.• Less conservative, where some actives overlap.• Radical, where all actives overlap.• Incremental, where the activities are repeated in cycles.
Conservative approach is better ...• For familiar kinds of systems.• When you need accurate schedule, budget, and resource estimates.
Radical and Incremental approach is better ...• With new systems and changing requirements.• When you need to minimize risk.• When you need results (even partial results) fast.
UMBC, Slide 12Analysis and Design of Client/Server Systems
Functional Decomposition
The mapping of the problem domain to a set of functions and sub-functions.
The original and probably the still the most commonly used approach.
Analyst is required to map the problem domain (e.g., air traffic control)to functions and sub-functions.
This is anindirect conversion that is highlyvolatile and sometimesarbitrary .
Page 7
UMBC, Slide 13Analysis and Design of Client/Server Systems
Functional Decomposition Model
Using functional decomposition, there is an indirect conversion from theproblem domain to the analysis results.
For example, the concepts in an air traffic control system (aircraft, radar,air traffic control personnel) must be transformed into various functions.
FunctionalDecomposition
main()getSomething()processThis()calculateThat()
UMBC, Slide 14Analysis and Design of Client/Server Systems
Structured Analysis
The mapping of the problem domain to flows and transformations.
This is an indirect conversion that has a strong function emphasis and istherefore highly volatile.
This approach is not very useful in systems that primarily update andretrieve data. There are no useful bubbles (transformations).
Traditionally, data and function are separated in this approach usingdata flow and entity relationship diagrams. This keeps critical issues toodisjoint.
Also, analysis results must be converted into another format for design.
Page 8
UMBC, Slide 15Analysis and Design of Client/Server Systems
Structured Analysis Model
Using structured analysis, there is an indirect conversion from theproblem domain to the analysis results.
For example, the concepts in an air traffic control system (aircraft, radar,air traffic control personnel) must be converted into various flows andtranformations.
StructuredAnalysis
UMBC, Slide 16Analysis and Design of Client/Server Systems
Data Modeling
The mapping of the problems domain into the following.• Entities• Attributes• Relationships• Inheritance• Aggregation
This is a partial solution which is missing specific concepts.• Functions/Operations• Messages
Data Modeling
Page 9
UMBC, Slide 17Analysis and Design of Client/Server Systems
Object Oriented Analysis
Real-world concepts are modeled asclasseswith correspondingstate,behavior, andcollaborations.
No transformation.• OOA directly maps the problem domaindirectly into a model,
instead of mapping them indirectly into functions or data flows.• The same model is used throughout the software engineering
process during analysis, design and implementation.
Minimizes volatility and maximizes resiliency.• The focus is on classes, not function and data.
Reuse is enhanced.• Classification - Classes are relatively stable over time.• Encapsulation - Classes with well-defined state and behavior.• Inheritance - Specializing classes for specific applications.
UMBC, Slide 18Analysis and Design of Client/Server Systems
Object Oriented Model
With an object oriented approach, there is a direct correspondencebetween the problem domain and the analysis results. The sameconcepts found in the problem domain are also found in the analysisresults, the design results and the software.
Object OrientedAnalysis class Airplane
class Radarclass AirTrafficController
Page 10
UMBC, Slide 19Analysis and Design of Client/Server Systems
Software Prototyping
Rapid prototyping is an important requirements validation technique.
• Start with an outline specification.
• Develop prototype.
• Users experiment with prototype to refine and improve thespecification.
• This is especially important to identify user interface requirements.• It often difficult - if not impossible - to model these
requirements with abstract techniques.
UMBC, Slide 20Analysis and Design of Client/Server Systems
Exploratory Programming vs. Prototyping
Exploratory programming• Start with a vague understanding of the system requirements.• Augments the system as new requirements are discovered.• Dependence on system specification is minimized or eliminated.• Good for unspecifiable problems, such as in AI.
Prototyping• Start with a vague understanding of the system requirements.• The prototype is intended to discover additional requirements.• Output of this process is the detailed specification.
Life span of the prototype• The prototype may be used as abuild-one-to-throw-away.• The prototype may be used as the basis for incremental
development• Similar to a radical waterfall or top-down development
approach.
Page 11
UMBC, Slide 21Analysis and Design of Client/Server Systems
Prototyping Techniques
Executable specification languages.• Formal specification languages can be difficult to work with.
Very high-level languages.• LISP, Prolog, or Smalltalk.
Fourth-generation languages.• Visual Basic, Powerbuilder.
Composition of reusable components• Develop a library of application framework classes that can be
easily integrated.
UMBC, Slide 22Analysis and Design of Client/Server Systems
Requirements Specification
The software requirements specification (SRS) is a complete descriptionof the external behavior of the software system.
• It is often used as part of the system contract.• It is the basis for designing a system.
SRS notation.• Natural language.
• Good for novices, but inherently ambiguous.• Structured language.
• Use controlled natural language to minimize ambiguities.• Program design language (PDL).
• A language based on programming constructs.• May be too biased toward design.
Non-functional requirements (along with functional requirements).• Constraints based on cost, interoperability, performance, access,
safety, privacy, etc.
Page 12
UMBC, Slide 23Analysis and Design of Client/Server Systems
Attributes of Well-Written Requirements
Correct• Represents something required of the system to be built.
Nonambiguous• Only one interpretation.
Complete• Everything the software is supposed to do is included.
Verifiable• Can check that the products meets the requirements.
Consistent• No requirements conflict with each other.
Understandable• Balance this with verifiable, complete, etc.
Modifiable• Related to structure and style of the document.
Traceable• Origin and future use of each requirement is clear.
UMBC, Slide 24Analysis and Design of Client/Server Systems
Structured Requirement Example
Function: Check_card_validity
Description: This operation must ensure that the card input by a userhas been issued by a subscribing bank, is in date, and containsappropriate account information.
Source: Input data is read from the card magnetic stripe.
Outputs: Card-status = (OK, invalid).
Requires: Bank-list, account-format, todays-date
Pre-condition: Card has been input and stripe data read.
Post-condition: Bank-identifier is in bank-list and account-numbermatches account-format and expiration date >= todays-date for Card-status = OK else Card-status = invalid
Page 13
UMBC, Slide 25Analysis and Design of Client/Server Systems
Requirements Validation
Once developed, requirements must be validated to show they meet theneeds of the system procurer. This includes the following steps.
• The needs of the user should be shown to be valid.• Further thought may reveal requirements which are not needed.• Extremely difficult to do without prototyping.
• The requirements should be shown to be consistent, complete, etc.• Based on attributes of good requirements.
• The requirements should be realistic.• No point specifying requirements which are unrealizable.
UMBC, Slide 26Analysis and Design of Client/Server Systems
Requirements Reviews
Validation shouldnot be done only after the SRS has been completed.• It should be carried out by a series of reviews throughout the
development process.
These can be informal or formal.• Informal reviews simply involve contractors discussing
requirements with clients.
• In a formal review, the development team shouldwalk the clientthrough the system requirements.
• Explaining the implications of each requirement.• Pointing out conflicts and contradictions.• Identifying actions items to resolve problems.• This is typically a manual process, involving multiple readers
from both the contractor and client staff.
Page 14
UMBC, Slide 27Analysis and Design of Client/Server Systems
CASE Tools
Computer-aided software engineering (CASE) has come into use as ageneric term for the automated support of software engineering.
Tools are available for the following process activities (analysis, design,implementation, verification & validation).
Classification A D I VPlanning and estimation x x x xText editing x x x xDocument preparation x x x xConfiguration management x x x xPrototyping x xDiagram editing x xData dictionary x xUser interface management x xMethod support x xLanguage processing x xProgram analysis x xInteractive debugging x xTest data generation x
UMBC, Slide 28Analysis and Design of Client/Server Systems
CASE Tool Integration
While separate tools are useful in their own right, more leverage isobtained when CASE tools work together in an integrated way.
There are three types of integration.
• Data integration, where tools use a shared data model.
• User interface integration, where tools are integrated around acommon interface.
• Activity integration, where a software process model is used tocoordinate tools activation and use.
Page 15
UMBC, Slide 29Analysis and Design of Client/Server Systems
Client/Server Computing
Client/Server computing attriubutes.• A decentralized architecture.• Transparent access to information.• GUI front-end coupled to a server-based RDBMS.
There are four design components for client/server applications.
Presentation logic• End-user interaction.
Business logic• Carry out transactions using data from the user and the database.
Database logic• Manipulates data within the application (possibly with SQL).
Database processing• Actual processing of the database data.
UMBC, Slide 30Analysis and Design of Client/Server Systems
Distributing Computational Elements
Presentation Logic Placed on the client
Business Logic Placed on the client• Given the power of client workstations.• Since presentation logic is on the client.
Database Logic Placed on the client• If database logic is embedded in the business logic.• If clients maintain some low-interaction, quasi-static data.
Database Processing Placed on the server• Assuming all clients share a common database.
Move Logic to Server• Include shared fragments of business and database logic.• Move parts of business and database logic to server for cases where
server has most knowledge of the impact of this logic.
Page 16
UMBC, Slide 31Analysis and Design of Client/Server Systems
Distributed Non-Functional Requirements
Distributing an application is a design or implementation decision whichshould not affect analysis. Following are several non-functionalrequirements should be evaluated during the design process.
Which processors or threads to distribute various tasks to.• Database server, X server, etc.
Communication medium between tasks.• Shared memory, shared disk, sockets, etc.
Communication bottlenecks between tasks.• Network may be much slower.
How much logic to put on server.• Don't overload server and create a bottleneck.
State inconsistencies between tasks.• Different machines may have different representations.
Time inconsistencies between tasks.• Each machine has its own clock.
UMBC, Slide 32Analysis and Design of Client/Server Systems
Architectural Design
Architectural design is usually concerned with decomposing a systeminto a set of interacting sub-systems which model the following.
• How subsystems share data.• How they interface with each other.
System decomposition models include the following.• Repository models.• Client/server models.• Abstract machine models.
Control models include the following.• Centralized control.• Event driven systems.
Modular decomposition includes the following.• Object-oriented model.• Data-flow model.
Page 17
UMBC, Slide 33Analysis and Design of Client/Server Systems
Repository Model
All shared data is held in a central database that can be accessed by allsubsystems.
• Alternatively, each subsystem maintains its own database.
Advantages.• Efficient way to share data (no need to explicit transmit data
between subsystems).• Centralized control of backup, security, access control, and
recovery.• Can easily integrate new tools into the repository.
Disadvantages.• All subsystems must use the same repository model, which may
compromise their optimal data layout.• Different subsystems may have different administration policies.• Replication of a distribute repository may introduce problems with
data redundancy and inconsistency.
UMBC, Slide 34Analysis and Design of Client/Server Systems
Repository Model Example
The architecture of an integrated CASE toolset.
Project Repository
Designeditor
Codegenerator
Reportgenerator
Designanalyzer
Page 18
UMBC, Slide 35Analysis and Design of Client/Server Systems
Client/Server Model
The client/server architectural model is based on the following.• A set of stand-alone servers which offer services to other
subsystems.• A set of clients subsystems that call on the services offered by the
servers.• A network which allows the clients access to these services.
The repository model can be implemented as a client/server model,where the repository is the lone server.
Advantages.• Decoupling client with server allows transparent access and a
modular design which is easy modify and extend.
Disadvantages.• No shared data model.• No centralized control and administration.
UMBC, Slide 36Analysis and Design of Client/Server Systems
Client/Server Model Example
A client/server model showing various server subsystems.
Client 1 Client 2 Client 3
Network
DatabaseServer
HypertextServer
VideoServer
Page 19
UMBC, Slide 37Analysis and Design of Client/Server Systems
Abstract Machine Model
This is sometimes called the layered model.• Organize services into a series of layers, each of which provides a
set of services.• For example, the OSI and TCP/IP reference models of network
protocols.
Advantages.• Supports incremental development of systems.• Enhance portability by centralizing machine-specific code in a
specific layers.
Disadvantages.• The layered approach is not always natural.• Basic facilities, such as file management, may be required by all
other levels, but a level can only access its immediate predecessor.• Multiple layers of command interpretation may impact
performance.
UMBC, Slide 38Analysis and Design of Client/Server Systems
An abstract machine model of a version management system.
Abstract Machine Model Example
OperatingSystem
Database SystemObject Management
Version Management
Page 20
UMBC, Slide 39Analysis and Design of Client/Server Systems
Centralized Control
One subsystem has overall responsibility for control.• It may give control to another subsystem, but expects to have that
control responsibility returned to it.• There are two forms of this approach.
The call-return model.• Top-down, hierarchical control through subroutines.• Relatively simple to analyze and implement.• Exceptions to normal hierarchical control are awkward to handle.
The centralized management model.• Often used in quasi-real-time systems with soft time constraints.• The central controller manages the execution of a set of processes.• Typically implemented with a polling loop.
UMBC, Slide 40Analysis and Design of Client/Server Systems
Centralized Control Example
Call-return model.
Centralized control model.
mainprogram
routine 1 routine 2 routine 3
centralcontroller
userinterface
faulthandler
sensorprocesses
computationprocesses
Page 21
UMBC, Slide 41Analysis and Design of Client/Server Systems
Event-Driven Systems
Event driven control models are driven by externally generated events.• In centralize control models, control decisions are usually
determined by the values of some system state variables.
There are two event-driven control models.• Broadcast models.• Interrupt-driven models.
UMBC, Slide 42Analysis and Design of Client/Server Systems
Broadcast Models
Broadcast models are used to integrate subsystems distributed acrossdifferent computers on a network.
• Events are broadcast to all subsystems.• The subsystem designed to handle the event responds to it.• In the centralized model, the control policy is embedded in the
handler.• The subsystem may also be able to explicitly send a message to a
specific subsystem.
Advantages.• System modification and evolution is relatively simple.• Distributed subsystems are easy to support.
Disadvantages.• Subsystems don't know if or when events will be handled.• Multiple subsystems may handle the same event, causing conflicts.
Page 22
UMBC, Slide 43Analysis and Design of Client/Server Systems
Broadcast Model Example
Subsystem 1 Subsystem 2 Subsystem 3
Event and message handler
UMBC, Slide 44Analysis and Design of Client/Server Systems
Interrupt-Driven Models
Interrupt-driven models are used exclusively in real-time systems.• External interrupts are detected and handled by an interrupt handler
and passed to some component for processing.• There are a know number of interrupt types, each associated with
the memory location where its handler's address.• A hardware switch causes control to be transferred immediately to
its handler.
Advantages.• It allows very fast responses to events.
Disadvantages.• It is complex to program and difficult to validate.• Difficult to simulate patterns of interrupt timing during system
testing.• Hard to debug program errors.
Page 23
UMBC, Slide 45Analysis and Design of Client/Server Systems
Interrupt-Driven Model Example
Interrupt
handler 1 handler 2 handler 4
Interrupts
Vectors
handler 3
UMBC, Slide 46Analysis and Design of Client/Server Systems
Modular Decomposition
Once the architectural design has been specified, each subsystem mustbe decomposed into modules. This can follow two approaches.
• Object-oriented model.• A set of loosely coupled objects with well-defined interfaces.• Loose coupling with information hiding makes modifications
easier and enhances reuse.• May not work well if these software objects do not have well-
defined interfaces.
• Data-flow model.• Data flows through functional transformations in sequence.• Supports reuse of transformations• Uses an intuitive format that has been widely adopted.• May not work well with interactive systems or other
applications, which are difficult to represent as flows of datathrough transformations.
Page 24
UMBC, Slide 47Analysis and Design of Client/Server Systems
Exercise: Requirement Attributes
1. Identify and explain any problems with the following requirements.
2. Propose alternative requirements without the identified problems.• The system shall exhibit good response time.• All customers shall have the same control field.• The system shall be menu-driven.• The response time for the BUILD command shall be 5 seconds.• There shall exist twenty-five buttons on the control panel,
numbered PF1 to PF25.• The software size shall not exceed 128K of RAM.• The elevator shall move smoothly and without jerking.• The system shall be fail-safe.• The response time for all commands shall be less than 0.1 seconds.• The response time for the INIT command shall be less than 1
second.
UMBC, Slide 48Analysis and Design of Client/Server Systems
Exercise: Architectural Design
Giving reasons for your answer; suggest an appropriate structure model,control model, and modular decomposition for the following systems.
• An automated ticket issuing system used by passengers at a railwaystation.
• A computer-controlled video conferencing system which allowsvideo, audio, and computer data to be visible to several participantsat the same time.
• A robot floor cleaner which is intended to clean relatively clearspaces such as corridors. The cleaner must be able to sense wallsand other obstructions.
Page 25
UMBC, Slide 49Analysis and Design of Client/Server Systems
Section 2: Analysis and Design Techniques
Functional Approaches• PDL Example• Data Flow Diagrams• Structured Analysis and Design (SADT)• Structure Charts
Data-Driven Approaches• Entity-Relationship Models• Data Dictionaries
Behavioral Approaches• State Transition Diagrams
UMBC, Slide 50Analysis and Design of Client/Server Systems
Program Design Language Example
PDL for print queue initialize function.
IF state <> busyinitialize printerIF printer OK
state := standbyreturn success
ELSEreturn failure
ENDIFELSE
return failureENDIF
PDL for printNextJob function.
IF state = standbystate := busybuild job from queueprint jobIF printer OK
remove job from queuestate := standbyreturn success
ELSEstate := standbyreturn failure
ENDIFELSE
return failureENDIF
Page 26
UMBC, Slide 51Analysis and Design of Client/Server Systems
Data Flow Diagram
Data flow diagrams (DFDs) show how input data is transformed tooutput results through a sequence of functional transformation.
• The diagrams have a functional bias.• Intuitive and easy to understand.
Data flow diagrams can be composed of a hierarchy of diagrams.• The top-level diagram is the context diagram.• Each transformation can represent a sub-diagram.
A DFD is not a flowchart.• There is not implicit ordering of event.• There are not logical decision symbols.• There is only the flow of data, not the flow of control.
There is little uniformity in the industry concerning DFD notation.
UMBC, Slide 52Analysis and Design of Client/Server Systems
Data Flow Notation
Transformations.• Rounded rectangle or bubble.• Functional units, where an input data flow is transformed to an
output. Each is given a descriptive name.
Data stores.• A pair of parallel lines.• Persistent data or data at rest. Each is given a descriptive name.
Terminators.• A square.• External entities with which the system communicates.
Data Flows.• An arrow.• Data, which flows along a path.
Page 27
UMBC, Slide 53Analysis and Design of Client/Server Systems
Data Flow Diagram Symbols
TransformationData Flow
Terminator Data Store
UMBC, Slide 54Analysis and Design of Client/Server Systems
Context Diagram Example
Context diagram for printNextJob.
printNextJob
request
User
printQueue
Printer
print job
result
file
print state
Page 28
UMBC, Slide 55Analysis and Design of Client/Server Systems
Data Flow Diagram Example
Data Flow for printNextJob function.
buildJob
request
User
printQueue
printJob
job
result
file
result
removeJob
file
Printer
print job
print state
file name
UMBC, Slide 56Analysis and Design of Client/Server Systems
Transformations and Flows
Input Flows• Data being sent into a transformation.
Output Flows• Data transformed by a transformation.
Avoid Infinite Sinks• Transformations with inputs, but no outputs.
Avoid Spontaneous Generation• Transformations that have outputs, but no inputs.• There may be exceptions, such as a random number generator.
Page 29
UMBC, Slide 57Analysis and Design of Client/Server Systems
Stores and Flows
Flows From a Store• Reading or accessing information• May be one or more complete or partial records.
Flows To a Store• Writing one or more records into the store.• Deleting one or more records from the store.• Updating one or more records in the store.
Avoid Read-Only or Write-Only Stores• Similar to Transformations.• There may be exceptions, such as a store that serve as an interface
between the system and some external terminator.
UMBC, Slide 58Analysis and Design of Client/Server Systems
SADT
Structured Analysis and Design Technique (SADT) was developed inthe 1970s by Doug Ross at SofTech, Inc.
The SADT model is composed of a hierarchy of diagrams.• The uppermost diagram is the context diagram.• Lower-level diagrams refine the system into sub-problems.
SADT is requirements analysis technique.• The decomposition during analysis is to help you understand the
problem.• This may differ from implementation decisions during design to
determine the appropriate combination of performance, efficiency,reliability, maintainability, modifiability, etc.
Disadvantages of SADT.• Diagrams imply a linear progression between functions.• Position requirements of arrows can be awkward.
Page 30
UMBC, Slide 59Analysis and Design of Client/Server Systems
SADT Notation
Boxes.• Each diagram is composed of boxes and arrows.• Boxes are usually arranged along a diagonal with unique numbers.• In activity models, boxes represent functions with unique names
based on verb phrases and arrows as noun phrases.• In data models, boxes represent data with unique names based on
noun phrases and arrows are verb phrases.
Four Types of Arrows.• Arrows pointing to theleft side of the box represent things that will
be transformed by the box.• Arrows pointingdown to the box represent control information that
affects the transformation.• Arrows entering thebottomof the box represent supporting
mechanisms, such as physical resources for the transformation.• Arrows leaving from theright of the box represent outputs from the
transformation.
UMBC, Slide 60Analysis and Design of Client/Server Systems
SADT Context Diagram
SADT context diagram for printNextJob function.
printNextJobrequest
need toprint job
result
Page 31
UMBC, Slide 61Analysis and Design of Client/Server Systems
SADT decomposition for printNextJob function.
SADT Diagram Refinement
buildJob
printJob
removeJob
request
job
file name
need toprint job
1
2
3
result
UMBC, Slide 62Analysis and Design of Client/Server Systems
Structure Charts
The structure chart is typically used as a design tool.• Shows the hierarchical organization of modules within one task.• Must transform DFD (asynchronous, network) into a synchronous
hierarchy.• Module A calls module B one or more times.• Module A is suspended until module B finishes (synchronous).
A
B
x,y p,q
the calling module
the called module
output parametersinput parameters
Page 32
UMBC, Slide 63Analysis and Design of Client/Server Systems
Structure Chart Example
Each transformation from the DFD becomes a structure chart module.• This may vary some, depending on the level of detail in the DFD.
Other modules can be added for the following reasons.• To manage the activity.• Bring input to or output from the system.
printNextJob
request
buildJob printJob removeJob
job
job statusfilename
status
UMBC, Slide 64Analysis and Design of Client/Server Systems
Entity-Relationship Diagram
The entity-relationship (E-R) model is based on an abstraction of a realworld which consists of a set of basic objects - entities and relationships.
The ERD uses a network model to describe the stored data of a systemat a high level of abstration.
• Implementation or physical considerations are deferred.• It is quite different from DFD or SADT, which model thefunctions
performed by a system.
It is typically the primary model for data-driven design, especially whenusing relational databases.
Page 33
UMBC, Slide 65Analysis and Design of Client/Server Systems
ERD Notation
Entity• Drawn as a rectangle.• An entity is an object thatexistsand isdistinguishable.• Similar to a record in a programming language with attributes.
Relationship• Drawn as a diamond.• An associationamong several entities.• Relationships may have attributes.• Relationships have cardinality (e.g., one-to-many)• Arrow meansone, no arrow meansmany.
Attribute• Drawn as ellipses.• Similar to record fields in a programming language.• Each attribute has a set of permitted values, called thedomain.• Primary key attributes may be underlined.
UMBC, Slide 66Analysis and Design of Client/Server Systems
ERD Example
customer
account
ccity
street
cname
amount
savingsaccountISA
interest-rate
borrow
balanceacct#
transaction
date tran#amount
branch
assets
bcity
bname
loan#
custAcct branchAcct
log
Page 34
UMBC, Slide 67Analysis and Design of Client/Server Systems
Reducing ERD to Tables
Strong entity sets.• Entity set converts directly into a table.• Customer(cname, street, ccity)
Weak and specialized entity sets (usually themany in a one-to-many).• Include the key from theoneas part of the key for themany.• Assuming tran# is adiscriminator.
• It is unique only for a given account.• Transaction(acct#, tran#, amount, date)
Relationship sets.• Include the keys from the entity sets for this relationship set.• Assuming loan# is a discriminator.
• It is unique only for a given branch.• CustAcct(cname, bname, loan#, amount)
UMBC, Slide 68Analysis and Design of Client/Server Systems
Data Dictionary
A data dictionary (DD) is a repository in which to store informationabout all data items defined in the system.
The data dictionary may be derived from data in any of the following.• Requirements.• Data Flow Diagrams.• Entity-Relationship Diagrams.
The typical information in a data dictionary.• Name of the data item.• Description or purpose.• Data structure definition.• Related data items.• Range of values or other referential integrity information.• Diagrams where the item is referenced.
Page 35
UMBC, Slide 69Analysis and Design of Client/Server Systems
State Transition Diagram
Real-time systems have to respond to events occurring at irregularintervals.
• These events often cause the system to move to a different state.• State machine modeling is therefore widely used for these types of
systems.• A finite state machine is a hypothetical machine that can be in only
one of a given number of states at any specific time.• The most common notation is the state transition diagram (STD).
The number of possible states may increase to an unmanageablenumber.
• Use a hierarchical approach with a system-level diagram and sub-diagrams below it.
• Use separate diagrams for each key thread of execution.• Use separate diagrams for each key software component.
UMBC, Slide 70Analysis and Design of Client/Server Systems
STD Notation
States.• Represented as a rectangle.• A valid system state.
Events.• Drawn as a labeled arrow.• A signal that something has happened which forces a transition to
another state.
Inputs and Outputs (optional).• Drawn as input/output on the event arrow.• The input that triggers the transition and the output with which the
system responds.
Page 36
UMBC, Slide 71Analysis and Design of Client/Server Systems
STD Example
STD for print queue.
state = off
state = standby
state = busy
initialize
buildJob removeJob
UMBC, Slide 72Analysis and Design of Client/Server Systems
DFD Real-Time Extensions
Control flow.• Represented as a dashed arrow.• A pipeline that cancarry a binary signal (i.e., on or off).• The control flow is sent from one process to another as a way of
telling it to wake up and do its job.
Control process.• Represented as a dashed oval.• A supervisor or executive bubble whose job is to coordinate the
activities of the other bubbles in the diagram.• Outgoing flows are used to wake up other bubbles.• Incoming flows are used to indicate that a task has been completed.• Control processes are usually modeled as with a state transition
diagram
Page 37
UMBC, Slide 73Analysis and Design of Client/Server Systems
DFD with Control Flows
controlsurveillance
systemsurveillance data
processsatellite
data
processradardata
satellite data
radar data
enable satelliteprocessing
enable radarprocessing
UMBC, Slide 74Analysis and Design of Client/Server Systems
Exercise: Small Library Database SystemDesign Modification
The Small Library Database System will be used by the BiologyDepartment of a local college to track the borrowing of books and otherforms of media, such as video tapes, and software. A secretary willoperate the system and will responsible for checking out books tostudents and faculty members.
Modify the following diagrams to support these new requirements.• Add or remove a copy of a book from the library.• Get a list of books by a particular author or on a particular subject.• Find the list of books currently checked out by a particular
borrower.• Find out what borrower last checked out a particular book.• Enforce a borrow time of 4 weeks and assess fines of 10 cents per
day for overdue books.• No borrower may have more than 5 books checked out at one time.
(From IEEE Software, November 1998, pp 37-47)
Page 38
UMBC, Slide 75Analysis and Design of Client/Server Systems
Design Modification: Library DFD
Modify this diagram as necessary based on new requirements.
checkOut
checkIn check in date
book nameborrower name
Borrow
media IDborrower IDcheck out date
Media Borrower
media IDborrower ID
Secretary
book name
UMBC, Slide 76Analysis and Design of Client/Server Systems
Modify this diagram as necessary based on new requirements.
Design Modification: Library ERD
borrower mediaborrow
bname phone
office
mname location
subject
ckOutDate ckInDate
Page 39
UMBC, Slide 77Analysis and Design of Client/Server Systems
Design Modification: Library STD
Modify this diagram as necessary based on new requirements.
initial
borrowed
returned
checkOut
checkkIn
UMBC, Slide 78Analysis and Design of Client/Server Systems
Exercise: Widget Retail Sales SystemClient/Server
A certain company maintains an inventory of widgets, which it sells tothe general public. Widgets are identified by size, color, retail cost andthe number currently in inventory. The system should also maintaininformation on the name, address, phone number and credit limit ofcustomers and the name, address, phone number, social securitynumber, salary, and job title of employees.
For each sale, the system should keep track of the widgets purchased. Asale may include a number of line items. For example, a customer maypurchase 5 big blue widgets and 3 little red widgets. The system shouldcompute a subtotal for each line item, tax, and a final total. In additionwe want to know the customer and employee involved in the sale.
Along with any diagrams, discuss how to implement the system in aclient/server architecture. Be sure to specify which parts of the systemwill fall into the key design components - presentation logic, businesslogic, database logic, database processing.
Page 40
UMBC, Slide 79Analysis and Design of Client/Server Systems
Exercise: Buoys-At-SeaDistrubuted Architecture
There are a number of free-floating buoys that provide navigation andweather data to air and ship traffic at sea. These buoys uses a variety ofsensors to collect air and water temperature, wind speed, and locationdata at 30 second intervals. If a sailor is able to reach the buoy, he orshe may flip a switch on the side of the buoy to initiate an SOSbroadcast. Some buoys are equipped with a red light, which may beactivated by passing vessels during sea-search operations.
Each buoy is equipped with a radio transmitter to broadcast weather andlocation information as well as an SOS message. A radio receiver ineach buoy is used to receive requests from passing vessels to activate ordeactivate the red light, for weather and location data over the last 24hours, or for current data. Assume that each buoy has a uniqueidentifier so that a request from a vessel goes to the appropriate buoy.
(From IEEE Transactions of Software Engineering, 12, 2, pp 211-221)
UMBC, Slide 80Analysis and Design of Client/Server Systems
Page 41
UMBC, Slide 81Analysis and Design of Client/Server Systems
UMBC, Slide 82Analysis and Design of Client/Server Systems
Page 42
UMBC, Slide 83Analysis and Design of Client/Server Systems
UMBC, Slide 84Analysis and Design of Client/Server Systems
Page 43
UMBC, Slide 85Analysis and Design of Client/Server Systems
Widget Solution : Context Diagram
Sale
sizes,colors,numbers,customer id
total cost
customers
employees
employee id
UMBC, Slide 86Analysis and Design of Client/Server Systems
Widget Solution : DFD
computeline item
computetax
computetotal
sizes,colors,numbers,customer id
total costcustomers
size,color,number
widget cost
widget types
widget cost
updateinventory
subtotal
tax
employees
employee id
sales
sizes,colors, numbers,customer id, employee id,widget costs, total cost
Page 44
UMBC, Slide 87Analysis and Design of Client/Server Systems
Widget Solution : ERD
customer
widgettypes
sale
cname cid
sizeamountin stock
color
cost
cost
date
employee
ename eid
line item
UMBC, Slide 88Analysis and Design of Client/Server Systems
Buoy Solution : Context Diagram
Buoy
red light request,current data request,summary data request
current data,summary data,SOS data
vessels
sailor
SOS request
Page 45
UMBC, Slide 89Analysis and Design of Client/Server Systems
Buoy Solution : DFD
processrequest
red light request
current data,summary data
vessels
SOS request
sendmessage
activate/deactivatered light
sensorcontrol
readsensor
enable read sensor datadata
sailor
data request
buildsummary
datarequest
SOS data
summarydata
currentdata
build SOSmessage
data
buildcurrent
data
UMBC, Slide 90Analysis and Design of Client/Server Systems
Buoy Solution : ERD
sensor data
sensor typevalue
date/time