Analysis and Design of Client-Server Systems

Analysis and Design of Client/Server Systems
University of Maryland Baltimore County Module 6 for Bell Atlantic Michael Grasso grasso@cs.umbc.edu
UMBC, Slide 1
Objectives
Module Objective To acquaint the participant with software analysis and design, with an emphasis on applications in client/server environments. Textbook Software Engineering by Ian Sommerville, 5th Edition. Essential Client Server Survival Guide by Orfali In-Class Exercises As individuals or teams, create data flow and/or control flow models for a sample application, using the standard notations. As individuals or teams, given a design document for a small system, modify that diagram to suit a small set of new requirements. Module Completion Requirement The participant will be required to demonstrate familiarity with principles of systems analysis and design, including the ability to read and understand diagrams developed using one of the techniques listed.
Analysis and Design of Client/Server Systems UMBC, Slide 2
Page 1
Outline
Section 1: Introduction to Software Analysis and Design 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 Functional Approaches Data-Driven Approaches Behavioral Approaches Reading List Software Engineering Client Server Survival Guide
Slide 4
Slide 49
Chapters 4,7,8,12,13,15,16,25 Chapter 29

UMBC, Slide 3
Session 1: Analysis and Design
Introduction and basic principles Software methodologies Requirements specification CASE tools for analysis and design Client/Server systems Architectural design
UMBC, Slide 4
Page 2
A Software Crisis
A 1979 GAO report (FGMSD-80-4, 11/79) evaluated 7 million dollars worth of software development projects and discovered that as a percentage 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 system development projects never finish. (Controlling Software Projects, Prentice Hall, 1982) Capers Jones documented in 1991 the gloomy statistic that the average MIS development project is one year late and 100 percent over budget. (American Programmer, 6/91)
What is Analysis
Analysis is the process of extracting the needs of a system - what the system should do, not how the system will be implemented. It is the problem-oriented (not the solution-oriented) phase in the software 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 merely the symptoms and to provide an unbiased view of the situation. (George Wedberg, But First, Understand the Problem, ASM Journal of Systems Management, page 22-28, 6/90) The risk of mortality ... increases when treatment is begun before a specific diagnosis has been reached. (The Merck Manual, 13th Edition, page 765, 1977)
UMBC, Slide 6
Page 3
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 7
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 understand these 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 a manager 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 4
Factors Influencing Software Development

Walston and Felix compared several development efforts to identify those factors having the greatest impact on that process as a function of the 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 programming methodologies had a positive effect, but not as great. IBM Systems Journal, 1977, 16(1).
UMBC, Slide 9
Waterfall Life Cycle

Developed in the 1960s, the waterfall life cycle is still the most commonly 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. Requirements Analysis Design Code Test Finished Product
UMBC, Slide 10
Page 5
Variations on the Waterfall Approach

The traditional waterfall presumes a basic linear approach where one activity 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 subfunctions. 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 an indirect conversion that is highly volatile and sometimes arbitrary.
UMBC, Slide 12
Page 6
Functional Decomposition Model

Using functional decomposition, there is an indirect conversion from the problem 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.
Functional Decomposition
main() getSomething() processThis() calculateThat()

UMBC, Slide 13
Structured Analysis
The mapping of the problem domain to flows and transformations. This is an indirect conversion that has a strong function emphasis and is therefore highly volatile. This approach is not very useful in systems that primarily update and retrieve data. There are no useful bubbles (transformations). Traditionally, data and function are separated in this approach using data flow and entity relationship diagrams. This keeps critical issues too disjoint. Also, analysis results must be converted into another format for design.
UMBC, Slide 14
Page 7
Structured Analysis Model

Using structured analysis, there is an indirect conversion from the problem 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 and tranformations.
Structured Analysis
UMBC, Slide 15
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
UMBC, Slide 16
Page 8
Object Oriented Analysis

Real-world concepts are modeled as classes with corresponding state, behavior, and collaborations. No transformation. OOA directly maps the problem domain directly 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 correspondence between the problem domain and the analysis results. The same concepts found in the problem domain are also found in the analysis results, the design results and the software.
Object Oriented Analysis
class Airplane class Radar class AirTrafficController
UMBC, Slide 18
Page 9
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 the specification. This is especially important to identify user interface requirements. It often difficult - if not impossible - to model these requirements with abstract techniques.
UMBC, Slide 19
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 a build-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 10
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 21
Requirements Specification
The software requirements specification (SRS) is a complete description of 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 11
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 user has been issued by a subscribing bank, is in date, and contains appropriate 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-number matches account-format and expiration date >= todays-date for Cardstatus = OK else Card-status = invalid
Page 12
Requirements Validation
Once developed, requirements must be validated to show they meet the needs 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 25
Requirements Reviews
Validation should not 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 should walk the client through 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.
UMBC, Slide 26
Page 13
CASE Tools
Computer-aided software engineering (CASE) has come into use as a generic term for the automated support of software engineering. Tools are available for the following process activities (analysis, design, implementation, verification & validation).
Classification Planning and estimation Text editing Document preparation Configuration management Prototyping Diagram editing Data dictionary User interface management Method support Language processing Program analysis Interactive debugging Test data generation
A x x x x x x x x
D x x x x x x x x x x
I x x x x
V x x x x x
x x x x
x x
UMBC, Slide 27
CASE Tool Integration

While separate tools are useful in their own right, more leverage is obtained 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 a common interface. Activity integration, where a software process model is used to coordinate tools activation and use.
UMBC, Slide 28
Page 14
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 29
Distributing Computational Elements

Presentation Logic Business Logic Given the power of client workstations. Since presentation logic is on the client. Placed on the client Placed 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 15
Distributed Non-Functional Requirements

Distributing an application is a design or implementation decision which should not affect analysis. Following are several non-functional requirements 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 system into 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 16
Repository Model
All shared data is held in a central database that can be accessed by all subsystems. 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.
Design editor
Code generator
Project Repository
Design analyzer
Report generator
UMBC, Slide 34
Page 17
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
Database Server
Hypertext Server
Video Server
UMBC, Slide 36
Page 18
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.
Abstract Machine Model Example

An abstract machine model of a version management system.
Version Management Object Management Database System Operating System
UMBC, Slide 38
Page 19
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 39
Centralized Control Example

Call-return model. main program
routine 1 Centralized control model. sensor processes
routine 2
routine 3
user interface central controller
computation processes
fault handler
UMBC, Slide 40
Page 20
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 41
Broadcast Models
Broadcast models are used to integrate subsystems distributed across different 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 21
Broadcast Model Example
Subsystem 1
Subsystem 2
Subsystem 3
Event and message handler
UMBC, Slide 43
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 22
Interrupt-Driven Model Example
Interrupts Interrupt Vectors handler 4
handler 1
handler 2
handler 3
UMBC, Slide 45
Modular Decomposition
Once the architectural design has been specified, each subsystem must be 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 welldefined 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 data through transformations.
Page 23
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 47
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 railway station. A computer-controlled video conferencing system which allows video, audio, and computer data to be visible to several participants at the same time. A robot floor cleaner which is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.
UMBC, Slide 48
Page 24
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 49
Program Design Language Example

PDL for print queue initialize function. IF state <> busy initialize printer IF printer OK state := standby return success ELSE return failure ENDIF ELSE return failure ENDIF PDL for printNextJob function. IF state = standby state := busy build job from queue print job IF printer OK remove job from queue state := standby return success ELSE state := standby return failure ENDIF ELSE return failure ENDIF
UMBC, Slide 50
Page 25
Data Flow Diagram

Data flow diagrams (DFDs) show how input data is transformed to output 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 51
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 26
Data Flow Diagram Symbols
Transformation
Data Flow
Terminator
Data Store
UMBC, Slide 53
Context Diagram Example

Context diagram for printNextJob. file request User result print state print job printNextJob printQueue
Printer
UMBC, Slide 54
Page 27
Data Flow Diagram Example

Data Flow for printNextJob function. file request User result file name job result printJob print state print job Printer buildJob removeJob printQueue file
UMBC, Slide 55
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.
UMBC, Slide 56
Page 28
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 57
SADT
Structured Analysis and Design Technique (SADT) was developed in the 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 29
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 the left side of the box represent things that will be transformed by the box. Arrows pointing down to the box represent control information that affects the transformation. Arrows entering the bottom of the box represent supporting mechanisms, such as physical resources for the transformation. Arrows leaving from the right of the box represent outputs from the transformation.
SADT Context Diagram

SADT context diagram for printNextJob function.
need to print job
request
printNextJob
result
UMBC, Slide 60
Page 30
SADT Diagram Refinement

SADT decomposition for printNextJob function. need to print job request buildJob
1
result printJob
2
job
file name
removeJob
3
UMBC, Slide 61
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).
the calling module input parameters x,y
A p,q output parameters
the called module

B
UMBC, Slide 62
Page 31
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 job buildJob printJob job
status file name
status
removeJob
UMBC, Slide 63
Entity-Relationship Diagram
The entity-relationship (E-R) model is based on an abstraction of a real world which consists of a set of basic objects - entities and relationships. The ERD uses a network model to describe the stored data of a system at a high level of abstration. Implementation or physical considerations are deferred. It is quite different from DFD or SADT, which model the functions performed by a system. It is typically the primary model for data-driven design, especially when using relational databases.
UMBC, Slide 64
Page 32
ERD Notation
Entity Drawn as a rectangle. An entity is an object that exists and is distinguishable. Similar to a record in a programming language with attributes. Relationship Drawn as a diamond. An association among several entities. Relationships may have attributes. Relationships have cardinality (e.g., one-to-many) Arrow means one, no arrow means many. Attribute Drawn as ellipses. Similar to record fields in a programming language. Each attribute has a set of permitted values, called the domain. Primary key attributes may be underlined.
ERD Example
date amount tran# acct# balance interest-rate savings account
transaction
log
account
ISA
street cname ccity
custAcct
branchAcct bname
bcity assets
customer loan#
borrow amount
branch
UMBC, Slide 66
Page 33
Reducing ERD to Tables

Strong entity sets. Entity set converts directly into a table. Customer(cname, street, ccity) Weak and specialized entity sets (usually the many in a one-to-many). Include the key from the one as part of the key for the many. Assuming tran# is a discriminator. 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 67
Data Dictionary
A data dictionary (DD) is a repository in which to store information about 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.
UMBC, Slide 68
Page 34
State Transition Diagram

Real-time systems have to respond to events occurring at irregular intervals. 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 unmanageable number. Use a hierarchical approach with a system-level diagram and subdiagrams below it. Use separate diagrams for each key thread of execution. Use separate diagrams for each key software component.
UMBC, Slide 69
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.
UMBC, Slide 70
Page 35
STD Example
STD for print queue.
state = off initialize state = standby buildJob state = busy removeJob
UMBC, Slide 71
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
UMBC, Slide 72
Page 36
DFD with Control Flows

process satellite data satellite data
enable satellite processing control surveillance system
surveillance data
radar data enable radar processing process radar data
UMBC, Slide 73
Exercise: Small Library Database System Design Modification

The Small Library Database System will be used by the Biology Department of a local college to track the borrowing of books and other forms of media, such as video tapes, and software. A secretary will operate the system and will responsible for checking out books to students 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 37
Design Modification: Library DFD

Modify this diagram as necessary based on new requirements. Media Secretary book name borrower name media ID Borrower borrower ID
checkOut media ID borrower ID check out date check in date Borrow
book name checkIn
UMBC, Slide 75
Design Modification: Library ERD

Modify this diagram as necessary based on new requirements. office bname phone mname subject location
borrower ckOutDate
borrow ckInDate
media
UMBC, Slide 76
Page 38
Design Modification: Library STD

Modify this diagram as necessary based on new requirements.
initial checkOut borrowed checkkIn returned
UMBC, Slide 77
Exercise: Widget Retail Sales System Client/Server

A certain company maintains an inventory of widgets, which it sells to the general public. Widgets are identified by size, color, retail cost and the number currently in inventory. The system should also maintain information on the name, address, phone number and credit limit of customers and the name, address, phone number, social security number, salary, and job title of employees. For each sale, the system should keep track of the widgets purchased. A sale may include a number of line items. For example, a customer may purchase 5 big blue widgets and 3 little red widgets. The system should compute a subtotal for each line item, tax, and a final total. In addition we want to know the customer and employee involved in the sale. Along with any diagrams, discuss how to implement the system in a client/server architecture. Be sure to specify which parts of the system will fall into the key design components - presentation logic, business logic, database logic, database processing.
Page 39
Exercise: Buoys-At-Sea Distrubuted Architecture

There are a number of free-floating buoys that provide navigation and weather data to air and ship traffic at sea. These buoys uses a variety of sensors to collect air and water temperature, wind speed, and location data at 30 second intervals. If a sailor is able to reach the buoy, he or she may flip a switch on the side of the buoy to initiate an SOS broadcast. Some buoys are equipped with a red light, which may be activated by passing vessels during sea-search operations. Each buoy is equipped with a radio transmitter to broadcast weather and location information as well as an SOS message. A radio receiver in each buoy is used to receive requests from passing vessels to activate or deactivate the red light, for weather and location data over the last 24 hours, or for current data. Assume that each buoy has a unique identifier 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 80
Page 40
UMBC, Slide 81
UMBC, Slide 82
Page 41
UMBC, Slide 83
UMBC, Slide 84
Page 42
Widget Solution : Context Diagram
sizes,colors, numbers, customer id customers total cost employee id Sale
employees
UMBC, Slide 85
Widget Solution : DFD

sizes,colors, numbers, customer id customers total cost employee id compute total subtotal tax sizes,colors, numbers, customer id, employee id, widget costs, total cost widget cost compute line item widget cost update inventory widget types sales compute tax
employees
size, color, number
UMBC, Slide 86
Page 43
Widget Solution : ERD
cname
cid cost date color sale cost amount in stock widget types
customer
ename
eid
size
employee line item

UMBC, Slide 87
Buoy Solution : Context Diagram
red light request, current data request, summary data request vessels current data, summary data, SOS data Buoy
SOS request
sailor
UMBC, Slide 88
Page 44
Buoy Solution : DFD

red light request activate/ deactivate red light request vessels data request current data, summary data SOS data sailor SOS request build SOS message enable read read sensor process request build current data build summary data summary data
current data send message
data data sensor data

UMBC, Slide 89
sensor control
Buoy Solution : ERD
date/time sensor type value sensor data
UMBC, Slide 90
Page 45

Analysis and Design of Client-Server Systems

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analysis and Design of Client-Server Systems

Uploaded by

Copyright:

Available Formats

Analysis and Design of Client/Server Systems