9.1 designing system architecture; finalising design specifications ims9001 - systems analysis and...

9.1

Designing system architecture;

finalising design specifications

IMS9001 - Systems Analysis and Design

9.2

Design (How?)

Define how the system will be implemented

Select a design strategy and specify

details

VariousSources

Design ideas/opinions

Design Options

System RequirementsSpecification

Report

IMPLEMENTATION

ANALYSIS

SystemVendors Hardware/

Softwaredeals

SystemOwners/Users

Selected Design Option

Design in ProgressReport

Technical DesignReport

9.3

System architecture is concerned with the technical and organisational configuration of the design of an application systemAn architecture defines the technologies to be used by the information systems in terms of its data, process interface and network components.The architecture must be consistent with:-

budget constraints organisational constraints existing technology requirements identified by analysis

System Architecture

9.4

Processing

Data

Communication

These components are interrelated and must be considered in conjunction with each other.

System Architecture Components

9.5

The evolution of computing environments has been largely determined by technological advances in computers and the convergence of computing and communications technologies

Processing can be: Centralised : e.g Host and terminals Distributed :

co-operative as in client/server functionally distributed as in regional processing and

centralised reporting

Architecture Components:Processing

9.6

Distributed versus Centralized SystemsA distributed system is one in which the DATA,

PROCESS, and INTERFACE components of an information system are distributed to multiple locations in a computer network. Accordingly, the processing workload is distributed across the network.

In centralized systems, a central, multi-user computer (ususally a mainframe) hosts all the DATA, PROCESS, and INTERFACE components of an information system. Users interact with the host via terminals (or PC terminal emulators), but virtually all of the processing is done on the host computer.

(From WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 11.)

9.7

Development of distributed computing involves two opposing trends:

1. to break up applications and push the resulting fragments towards the end user.

price/performance benefits of developing and executing applications on workstations;

demands from end users for local autonomy and additional functionality to improve their productivity.

2 to consolidate data to meet the end user’s need for corporate data

affects systems integration requirements and results in the centralisation of applications on large powerful mainframes;

increases the need for high levels of integrity, performance and availability.

Distributed Computing Architecture

The pivotal architectural question is:how and where are computing resources distributed in this architecture ?

9.8

Why Distributed Systems?

Modern business systems are already decentralized and distributed.

Distributed computing moves information and services closer to the customers and users who need them.

Distributed computing consolidates the power of personal computers across the enterprise.

Distributed computing solutions are more user-friendly because they utilize the PC as the end user interface.

Personal computers and network servers are cheaper than centralized mainframe computers


9.9

Architecture Components:Computers

Mainframe - a large, centralised computer (e.g. an IBM AS400, UNISYS, FUJITSU) normally interfacing large numbers of terminals with large, centralised databases, running many concurrent processes.

Server - a medium sized computer, normally providing services, particularly shared data resources and printing, to a number of PCs.

Terminal - usually a PC, but may be a less intelligent device. Typically running a GUI interface and interacting with a single user at a time.

9.10

Processing Architecture:Types

Host-based: all processing is performed on one computer system to which are attached unintelligent, “dumb”, character-based terminals. Processing is totally non-distributed.

Master-slave: slave computers are attached to a master computer and perform application processing functions but only as directed by their master. The minimal distribution is uni-directional from master to slave although slave has some limited local processing capability (eg. field editing).

Shared-device: PC workstations are attached to a system device, the server, that allows them to share common resources, files, disk and printer. All application processing is performed on the PC and only certain functions are distributed.

9.11

diskhost CPU

(running application)

terminals

Host-based Processing

9.12

disk

host CPU(running application)

Master-slave Processing

9.13

disk

LAN

server with shared disk and

printer

client application

client application

client application

Shared-device Processing

9.14

Processing Architecture:Types

“Co-operative Computing” Client-server: Workstations become clients as they request

servers to process significant parts of the application running on the workstation in addition to sharing resources. The application is now distributed and the client and server cooperate to successfully execute the application. The client initiates interaction but the server enforces control over what services and data the client can request and arbitrates conflict between clients.

Peer-to-peer: Each participating system is equal and can both request services from and provide services to all other systems. There is no distinction between client and server and in intelligent networks, the server workload can be distributed and shared between participating systems.

9.15

disk

LAN or WAN

server with shared disk and

printer

client application

client application

client application

Client-server

9.16

disk

disk

disk

disk

disk

disk

Peer-to-peer

9.17

File Server ArchitectureA local area network (LAN) is a set of client computers (PCs)

connected to one or more sever computers either through cable or wireless connections over relatively short distances.

A file server system is a LAN-based solution in which a server hosts only the data layers of an information system. All other layers are implemented on the client computers. Disadvantages include: Frequently excessive network traffic to transport data

between servers and clients. Client must be fairly robust (“fat”) because it does most

of the work Database integrity can be easily compromised.(From WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis

and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 11.)

9.18

Client/Server Architecture—The Clients

A client/server system is a solution in which the presentation, presentation logic, application logic, data manipulation, and data layers are distributed between client PCs and one or more servers.

A thin client is a personal computer that does not have to be very powerful (or expensive) in terms of processor speed and memory because it only presents the user interface to the user.

A fat client is a personal computer or workstation that is typically more powerful (and expensive) in terms of processor speed, memory, and storage capacity. Most PCs are considered to be fat clients.


9.19

Client/Server Architecture—The Servers

A database server hosts one or more shared databases but also executes all data manipulation commands.

A transaction server hosts services that ultimately ensure that all database updates for a single transaction succeed or fail as a whole.

An application server hosts the application or business logic and services for an information system.

A messaging or groupware server hosts services for e-mail, calendaring, and other work group functionality.

A web server hosts Internet or intranet web sites and services, communicating thorugh thin-client interfaces such as web browsers.


9.20

Distributed Computing Layers

Presentation layer—the user interface, the presentation of inputs and outputs to the user

Presentation layer logic— any processing required to generate the presentation, such as input editing

Application logic layer— the logic and processing to support the business application: the business rules, policies, and procedures, e.g. credit checking, calcualtions

Data manipulation layer—the commands and logic required to store and retrieve data to and from the database

Data layer—the actual stored business data(From WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems

Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 11.)

9.21

Distributed computing and systems

See class handout

9.22

Client/Server Solutions A distributed presentation client/server system is a solution in which the

presentation and presentation logic layers only are shifted from the server to reside on the client. The application logic, data manipulation, and data layers remain on the server (frequently a mainframe).

A distributed data client/server system is a solution in which the data and data manipulation layers are placed on the server(s), and the application logic, presentation logic, and presentation layers are placed on the clients. This is sometimes called two-tiered client/server computing.

A distributed data and application client/server system is a solution in which: (1) the data and data manipulation layers are placed on their own server(s), (2) the application logic is placed on its own server, and (3) the presentation logic and presentation layers are placed on the clients.This is sometimes called three- or n-tiered client/server computing. It requires design partitioning.

Partitioning is the art of determining how to best distribute or duplicate application components (DATA, PROCESS, and INTERFACE) across the network.


9.23

Client/Server Solutions: Internet- and Intranet-based Architectures

A network computing system is a multi-tiered solution in which the presentation and presentation logic layers are implemented in client-side Web browsers using content downloaded from a Web server. The presentation logic layer then connects to the application logic layer that runs on the application server, which subsequently connects to the database servers on the backside of the system.

The greatest potential of this approach is its applicability to redesign of traditional information systems to run on an intranet. An intranet is a secure network, usually corporate, that uses Internet technology to integrate desktop, work group, and enterprise computing into a cohesive framework.


9.24

Advantages: exploits the power and relative low cost of desktop

computing technology. increased software portability reduction in the application backlog allows processing to take place at the source of the

data thus reducing network traffic and response times and increasing the capacity and effective throughput of the network.

facilitates the use of GUIs encourages open systems as clients and servers are

independent of hardware and software platforms.

Co-operative computing

9.25

Disadvantages: bottlenecks at the server if significant

portion of the application resides there. distributed applications are more

complex thus increasing the cost of application development, maintenance and support in terms of the run-time environment and management of the distributed environment.

Co-operative computing

9.26

A communication system:

is a mechanism that allows distributed resources to exchange data and control information.

can be implemented as totally transparent or may be visible to the user.

requires physical connection between interacting nodes.

Architecture Components:Communication

9.27

A communication system is a collection of hardware and software that supports intersystem and interprocess communication between software components in distributed nodes.

A network provides a physical path between the nodes.

A link is the direct connection between two (or more) systems.

The name of an object indicates a system, process or a node.

An address indicates where the named object is.

A route tells how to get there.

Communications: Definitions

9.28

Data architecture requires additional information about the essential data model:

volumes locations events distribution

This additional information not only impacts the data but also the processing and the communication choices.

Architecture Components:Data

9.29

For distributed data architecture the following issues need to be considered: data ownership data transfer speeds network utilisation query processing catalogue management update propagation concurrency controls recovery controls

Similar issues arise in other architectures

Data Architecture :Issues

9.30

local autonomy non reliance on a central site continuous operations location independence fragmentation independence replication independence distributed query processing distributed transaction processing hardware independence operating systems independence network independence DBMS independence

C. J. Date 1995

Data Architecture :Distributed Data Objectives

9.31

Data architectures

Historically central control of data has been considered essential

Data is easier to manage as a shared resource: the only practical way used to be on a central computer

Client/server and network computing allow distribution of data without loss of control via advances in distributed relational database technology


9.32

Data architecturesA relational database stores data in tabular form. Each file is implemented as a table. Each field is a column in the table. Each record is a row. Related records between two tables are implemented by intentionally duplicated columns in the two tables.

A distributed relational database distributes or duplicates tables to multiple database servers located in geographically important locations, e.g. different sales regions

A distributed relational database management system (distributed RDBMS) is a software program that controls access to and maintenance of stored data in the relational format. It provides for backup, recovery and security.The processing of all commands executes on the database server, reducing data traffic on the network.


9.33

Types of Data(base) DistributionMost RDBMSs support two types of distributed data:

Data partitioning truly distributes rows and columns of tables to specific database servers with little or no duplication between servers. Vertical partitioning assigns different columns to

different servers. Horizontal partitioning assigns different rows to different

servers.

Data replication duplicates some or all tables (or parts of tables) on more than one database server. Database technology controls acces to, and manages consistecy of duplicated data across the servers.


9.34

Data architecture

The data architecture must specify the RDBMS technology and the partitioning or replication of data

It is selected based on the desired client/server or network computing model and the database technology needed to support that model

Many organisations have standardised on their PC RDBMS and their distributed, enterprise RDBMS, e.g. Microsoft Access and SQL Server

Technology decisions concerning data input and output technologies also need to be made


9.35

Advantages of Distributed Databases

Increased system reliability due to redundancy

Local control of data … helps with improved data integrity and administration

Lower communication costs by reducing traffic

Faster response since most applications use data at a local site

9.36

Disadvantages of Distributed Databases

Software cost and complexity for a distributed environment

Data integrity …control problems with multiple and dispersed sites

Slow response if data and software not distributed properly

9.37

A Method for System Architecture Design

1. Draw a physical DFD to represent the network architecture. Each physical process symbol will represent a client or server processor.

2. For each physical process on the above network architecture model, draw a physical DFD that shows the event processes that are assigned to (or duplicated on) that physical processor.

3. For appropriate processes on the above system DFDs, draw draw more detailed physical DFDs that factor the event into design units.

4. Draw physical, primitive DFDs for appropriate processes from step 3.


9.38

A design unit is a self-contained collection of processes, data stores, and data flows that share similar design characteristics. A design unit serves as a subset of the total system whose inputs, outputs, files and databases, and programs can be designed, constructed, and tested as a self-contained unit.

Ultimately, design units must be integrated into a whole system.

A Method for System Architecture Design: Design units


9.39

A Method for System Architecture Design: The Network Architecture DFD

A network architecture is documented as a physical DFD that allocates processors (clients and servers) and possibly devices (machines and robots) across a network and establishes:

the connectivity between clients and servers

where users will interface with the processors


9.40

Need for systems to be developed more quickly today

The lines between analysis and design and design and implementation are blurring

Traditional approaches allowed for a break between design and implementation

Other approaches, such as CASE and prototyping, have caused overlap between the two phases

Finalising Design Specifications

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design, (3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

9.41

The Process of Finalizing Design Specifications

Less costly to correct and detect errors during the design phase

Two sets of guidelines Writing quality specification statements The quality of the specifications themselves

Quality requirement statements Correct Feasible Necessary Prioritized Unambiguous Verifiable

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design, (3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

9.42

The Process of Finalizing Design Specifications

Quality requirements Completely described Do not conflict with other requirements Easily changed without adversely

affecting other requirements Traceable back to origin

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design,

(3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

9.43

Finalising design specifications

Key deliverable:A set of physical design specifications

Sample contents: Overall system description Interface requirements System features Non-functional requirements Other requirements Supporting diagrams and models

see Hoffer et al (2005) p 445

9.44


Overall system description: Functions Operating environment Types of users Constraints Assumptions and dependencies

Interface requirements User interfaces Hardware interfaces Software interfaces Communication interfaces

9.45


System features Feature 1 description…. Feature n description

Non-functional requirements Performance Safety Security Software quality Business rules

Other requirements

Supporting diagrams and models

9.46


Representing design specifications: Written document with diagrams and

models – traditional approach uses structure charts

Computer-based requirements/CASE tool to input and manage specifications

Working prototype to capture specifications

Combinations of the above

9.47

Finalising design specifications: data design

Physical file and database design requires: Normalised relations Attribute definitions Where and when data is entered, retrieved,

updated and deleted Response time and data integrity needs Implementation technologies to be used

Design physical tables and file structures according to performance factors and constraints of the particular application

9.48

Structure charts for process design

Structure charts show the hierarchical structure of the software modules in a system

Relationships between the modules, including data and messages passed, are made clear

Structured design principles are followed to ensure well-designed system structure

9.49

The data flow diagrams and process descriptions produced in the systems analysis phase need to be translated into processes (programs and procedures) during the systems design stage.

These need to be designed with quality criteria in mind: correctness, completeness, maintainability, etc.

A structure chart represents the flow and processing of data as a system structure

Physical process design

9.50

Partition the system into "black boxes" Organise the "black boxes" into hierarchies suitable for computer implementationUse diagrams to make the system structure easy to understandUse a set of strategies for developing a design solution from a well defined statement of a problem (e.g. a DFD)Use a set of criteria for evaluating the quality of a given design solution Produce systems that are easy to understand,

reliable, flexible, and efficient to maintain

Structured Design

9.51

A system is easier to write and test if we divide it into

MODULES

MODULE: A named,bounded, set of statementsto do a single task, havingan identifier by which it canbe referenced as a unit.

GET VALIDTRANSACTION

Each of thesemodules iscodedseparately

Structure Charts

9.52

Start and end here

• Top members (managers) co-ordinate and control• Subordinates process• A manager should have no more than 7+2 immediate subordinates reporting directly to it

USE A HIERARCHY:

input output

Structure charts

9.53

Each business process will generate its own structure chart, using a design strategy such as Transform Analysis.

Each box on the structure chart will be a module with its own specification.

Tie together all structure charts under a transaction monitor, so each structure chart can be 'fired' each time a transaction stimulus of its type arrives (or is selected from a menu).

Deriving structure charts

9.54

A design process which turns data flow diagrams into structure charts.

A transform-centred system has as its focus the derivation of new information from existing data

The input part of the system is known as the afferent part

The output part of the system is known as the efferent part

Transform analysis

9.55

5create

X

6Make

Y

4check

M

3Make

M

2check

A

1Make

A

input 1 A

M

B

N

X Y

input 2

6Put Y

Put YMake Y

Make MGet input2Make AGet input1

Create X

Make B Make N

B

A

Main

Put XGet NGet B

Get A Get M

input1

A

N

M

X

B

Ainput1

input2input2

M

NM

N

B

X

XY

Y

afferent legs

efferent legcentraltransform

Transform analysis - an example

9.56

Prototyping Construction of the model of a system Allows developers and users to

Test aspects of the overall design Check for functionality and usability

Iterative process Two types

Evolutionary Prototyping Throwaway Prototyping


9.57

Evolutionary Prototyping Begin by modeling parts of the target system If successful, evolve rest of the system from the prototype Prototype becomes actual production system Often, difficult parts of the system are prototyped first Exception handling must be added to prototype

Throwaway Prototyping Prototype is not preserved Developed quickly to demonstrate unclear aspect of

system design Fast, easy to use development environment aids this

approach


9.58

Design features that lead to systems that are easier to maintain and modify : Small module size Modular independence (decrease

coupling) Black box characteristics Module strength (increase cohesion)

Design features

9.59

Identifying and designing user tasks is a component of systems design that is frequently overlooked.User procedures are often considered to be defined by the user manual. Little, if any, thought may be given to the design of the interface (and user manual) to take human procedures into account. As a result, systems may be poorly accepted and some may not be used at all.

User task design

9.60

Where should this boundary be drawn?What are the activities that should be undertaken by humans and what undertaken by machines?In principle, a good system is one that makes best use of both human and machine characteristics in a co-operative activity.

The human/computer boundary

9.61

Humans slow at routine tasks make frequent errors capable of judgement can adapt to new

situations good at problem

solving creative can understand the

context of the work

Computers• fast at routine tasks• accurate in routine

tasks • incapable of

judgement• must be

reprogrammed for new situations

• must be programmed for specific problem types

• not creative• don’t understand

context

Humans vs Computers

9.62

cycle time: short longconstraints: precise loose

constraining discretionaryroutine non-routine

skill level: low highskill count: few manySpecialisation: few tasks varied

tasks

Task dimensions

9.63

Sequence handle data in a “natural” order human eye movement is left-to-right and top-to-

bottom (cultural differences?)Grouping

make use of groups of data to “chunk” tasks “chunking” helps humans reduce information load short term memory capacity ~ 7 plus or minus 2

Repetition repeated tasks need a break - make use of closure

pointsAll these are important ... BUT ...

Rational task design

9.64

concentration is affected by: interruptions

phone visitors events in the corridor equipment breakdowns, malfunctions

pressure deadlines pressure to achieve

personal problems problems with family problems with relationships problems with work relationships

Good design should minimise the impact.

What really happens

9.65

Too much attention to computing solutions often results in poor task design including:

highly detailed data entry procedures (too hard to remember)

intolerant error management (blaming the user for making mistakes)

inconsistent procedures (causing confusion) crowded screens (too hard to follow) ambiguous instructions and messages

(need to look them up in the manual - if they can be found at all)

Poor task design

9.66

fit the software to the user’s mental model of their organisational task, e.g. invoicing, controlling stock)

understand the user (build a profile of their skills and knowledge)

naive, casual, expert understand the role of the system in the task:

mainly data entry OR requests for information OR active dialogue

constant use, frequent use, infrequent use compulsory or discretionary use of the system

design the task to fit

Aims of task design

9.67

Many systems perform functions previously performed manually or with non-computer aids.

If the new system changes the way tasks are performed then:

users may need new ways of thinking about the task, i.e., new perceptual models

dialogs need to be designed to encourage appropriate perceptual models

additional training may be required

Changing task structure

9.68

Changes in:technologysoftware capabilitiesexpectations of worksocial structures

are likely to change our views of task design in future. However, human capabilities change little.

Remember to design for the human in the job

User task design

9.69

References

HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapters 13, 14

WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapter 11

9.1 designing system architecture; finalising design specifications ims9001 - systems analysis and...

Documents

distributed systems

design slide

system architecture

design option design

processing slide

distributed computing

design methods

design strategy