analysis and design of client-server systems

UMBC, Slide 1Analysis and Design of Client/Server Systems

Analysis and Designof Client/ServerSystems

University of Maryland Baltimore CountyModule 6 for Bell Atlantic

Michael [email protected]


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.


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


Session 1: Analysis and Design

Introduction and basic principles

Software methodologies

Requirements specification

CASE tools for analysis and design

Client/Server systems

Architectural design


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)


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)


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)


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.


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).


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


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.


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 .


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()


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.


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


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


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.


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


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.


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.


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.


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.


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.


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


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.


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.


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


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.


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.


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.


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.


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.


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.


Repository Model Example

The architecture of an integrated CASE toolset.

Project Repository

Designeditor

Codegenerator

Reportgenerator

Designanalyzer


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.


Client/Server Model Example

A client/server model showing various server subsystems.

Client 1 Client 2 Client 3

Network

DatabaseServer

HypertextServer

VideoServer


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.


An abstract machine model of a version management system.

Abstract Machine Model Example

OperatingSystem

Database SystemObject Management

Version Management


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.


Centralized Control Example

Call-return model.

Centralized control model.

mainprogram

routine 1 routine 2 routine 3

centralcontroller

userinterface

faulthandler

sensorprocesses

computationprocesses


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.


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.


Broadcast Model Example

Subsystem 1 Subsystem 2 Subsystem 3

Event and message handler


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.


Interrupt-Driven Model Example

Interrupt

handler 1 handler 2 handler 4

Interrupts

Vectors

handler 3


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.


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.


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.


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


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


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.


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.


Data Flow Diagram Symbols

TransformationData Flow

Terminator Data Store


Context Diagram Example

Context diagram for printNextJob.

printNextJob

request

User

printQueue

Printer

print job

result

file

print state


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


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.


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.


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.


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.


SADT Context Diagram

SADT context diagram for printNextJob function.

printNextJobrequest

need toprint job

result


SADT decomposition for printNextJob function.

SADT Diagram Refinement

buildJob

printJob

removeJob

request

job

file name

need toprint job

1

2

3

result


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


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


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.


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.


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


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)


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.


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.


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.


STD Example

STD for print queue.

state = off

state = standby

state = busy

initialize

buildJob removeJob


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


DFD with Control Flows

controlsurveillance

systemsurveillance data

processsatellite

data

processradardata

satellite data

radar data

enable satelliteprocessing

enable radarprocessing


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)


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



Design Modification: Library ERD

borrower mediaborrow

bname phone

office

mname location

subject

ckOutDate ckInDate


Design Modification: Library STD


initial

borrowed

returned

checkOut

checkkIn


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.


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)



Widget Solution : Context Diagram

Sale

sizes,colors,numbers,customer id

total cost

customers

employees

employee id


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


Widget Solution : ERD

customer

widgettypes

sale

cname cid

sizeamountin stock

color

cost

cost

date

employee

ename eid

line item


Buoy Solution : Context Diagram

Buoy

red light request,current data request,summary data request

current data,summary data,SOS data

vessels

sailor

SOS request


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


Buoy Solution : ERD

sensor data

sensor typevalue

date/time

analysis and design of client-server systems

Documents