IMS9001 - Systems Analysis and Design Designing system architecture; finalising design specifications

Design ideas/opinions Design (How?) Define how the system will be implemented System Requirements Specification Report Various Sources ANALYSIS Design ideas/opinions Select a design strategy and specify details Design Options System Vendors Hardware/Software deals Selected Design Option Design in Progress Report Technical Design Report SystemOwners/Users IMPLEMENTATION

System Architecture System architecture is concerned with the technical and organisational configuration of the design of an application system An 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 Components Processing Data Communication These components are interrelated and must be considered in conjunction with each other.

Architecture Components: Processing 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

Distributed versus Centralized Systems A 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.)

Distributed Computing Architecture 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. The pivotal architectural question is: how and where are computing resources distributed in this architecture ?

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

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.

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.

Host-based Processing disk host CPU (running application) terminals

Master-slave Processing disk host CPU (running application)

Shared-device Processing client application client application server with shared disk and printer LAN disk client application

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.

server with shared disk and printer Client-server client application client application server with shared disk and printer LAN or WAN disk client application

Peer-to-peer disk disk disk disk disk disk

File Server Architecture A 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.)

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

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

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

Distributed computing and systems See class handout

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

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

Co-operative computing 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 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.

Architecture Components: Communication 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.

Communications: Definitions 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.

Architecture Components: Data 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.

Data Architecture :Issues 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 : Distributed Data Objectives 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 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 (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.)

Data architectures A 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. (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.)

Types of Data(base) Distribution Most 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. (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.)

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

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

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

A Method for System Architecture Design Draw a physical DFD to represent the network architecture. Each physical process symbol will represent a client or server processor. 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. For appropriate processes on the above system DFDs, draw draw more detailed physical DFDs that factor the event into design units. Draw physical, primitive DFDs for appropriate processes from step 3. (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.)

A Method for System Architecture Design: Design units 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. (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.)

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

Finalising Design Specifications 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 from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design, (3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

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.

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.

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

Finalising design specifications Overall system description: Functions Operating environment Types of users Constraints Assumptions and dependencies Interface requirements User interfaces Hardware interfaces Software interfaces Communication interfaces

Finalising design specifications System features Feature 1 description…. Feature n description Non-functional requirements Performance Safety Security Software quality Business rules Other requirements Supporting diagrams and models

Finalising design specifications 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

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

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

Physical process design 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

Structured Design Partition the system into "black boxes" Organise the "black boxes" into hierarchies suitable for computer implementation Use diagrams to make the system structure easy to understand Use 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

Structure Charts A system is easier to write and test if we divide it into MODULES Each of these modules is coded separately GET VALID TRANSACTION MODULE: A named, bounded, set of statements to do a single task, having an identifier by which it can be referenced as a unit.

Structure charts Start and end here USE A HIERARCHY: input output • Top members (managers) co-ordinate and control • Subordinates process • A manager should have no more than 7+2 immediate subordinates reporting directly to it

Deriving structure charts 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).

Transform analysis 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 - an example 5 create X 6 Make Y 4 check M 3 Make M 2 check A 1 Make A input 1 A M B N X Y input 2 Put Y Get input2 Get input1 Create X Make B Make N Main Put X Get N Get B Get A Get M input1 input2 afferent legs efferent leg central transform

Finalising design specifications 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

Finalising design specifications 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

Design features 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)

User task design 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.

The human/computer boundary 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.

Humans vs Computers Humans Computers 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

Task dimensions cycle time: short long constraints: precise loose constraining discretionary routine non-routine skill level: low high skill count: few many Specialisation: few tasks varied tasks

Rational task design Sequence Grouping Repetition 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 points All these are important ... BUT ...

What really happens 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.

Poor task design 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)

Aims of task design 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

Changing task structure 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

Remember to design for the human in the job User task design Changes in: technology software capabilities expectations of work social 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

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