Analysis and Design of Client/Server Systems

University of Maryland Baltimore County Module 6 for Bell Atlantic Michael Grasso grasso@cs.umbc.edu

Analysis and Design of Client/Server Systems

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
Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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)
Analysis and Design of Client/Server Systems UMBC, Slide 5

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)

Analysis and Design of Client/Server Systems

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)

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 8

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 11

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.

Analysis and Design of Client/Server Systems

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

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 17

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

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 20

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 22

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.
Analysis and Design of Client/Server Systems UMBC, Slide 23

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
Analysis and Design of Client/Server Systems UMBC, Slide 24

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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
Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 30

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.
Analysis and Design of Client/Server Systems UMBC, Slide 31

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.
Analysis and Design of Client/Server Systems UMBC, Slide 32

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.
Analysis and Design of Client/Server Systems UMBC, Slide 33

Repository Model Example
The architecture of an integrated CASE toolset.

Design editor

Code generator

Project Repository

Design analyzer
Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 35

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

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 37

Abstract Machine Model Example
An abstract machine model of a version management system.

Version Management Object Management Database System Operating System

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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
Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 42

Page 21

Broadcast Model Example

Subsystem 1

Subsystem 2

Subsystem 3

Event and message handler

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 44

Page 22

Interrupt-Driven Model Example

Interrupts Interrupt Vectors handler 4

handler 1

handler 2

handler 3

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 46

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 52

Page 26

Data Flow Diagram Symbols

Transformation

Data Flow

Terminator

Data Store

Analysis and Design of Client/Server Systems

UMBC, Slide 53

Context Diagram Example
Context diagram for printNextJob. file request User result print state print job printNextJob printQueue

Printer

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 58

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.
Analysis and Design of Client/Server Systems UMBC, Slide 59

SADT Context Diagram
SADT context diagram for printNextJob function.

need to print job

request

printNextJob

result

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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
Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 65

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#
Analysis and Design of Client/Server Systems

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)

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

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.

Analysis and Design of Client/Server Systems

UMBC, Slide 70

Page 35

STD Example
STD for print queue.

state = off initialize state = standby buildJob state = busy removeJob

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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)
Analysis and Design of Client/Server Systems UMBC, Slide 74

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

UMBC, Slide 76

Page 38

Design Modification: Library STD
Modify this diagram as necessary based on new requirements.

initial checkOut borrowed checkkIn returned

Analysis and Design of Client/Server Systems

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.
Analysis and Design of Client/Server Systems UMBC, Slide 78

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)
Analysis and Design of Client/Server Systems UMBC, Slide 79

Analysis and Design of Client/Server Systems

UMBC, Slide 80

Page 40

Analysis and Design of Client/Server Systems

UMBC, Slide 81

Analysis and Design of Client/Server Systems

UMBC, Slide 82

Page 41

Analysis and Design of Client/Server Systems

UMBC, Slide 83

Analysis and Design of Client/Server Systems

UMBC, Slide 84

Page 42

Widget Solution : Context Diagram

sizes,colors, numbers, customer id customers total cost employee id Sale

employees

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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
Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

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

Analysis and Design of Client/Server Systems

Buoy Solution : ERD

date/time sensor type value sensor data

Analysis and Design of Client/Server Systems

UMBC, Slide 90

Page 45

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times