1 / 69

IMS9001 - Systems Analysis and Design

IMS9001 - Systems Analysis and Design. Designing system architecture; finalising design specifications. Design (How?). Define how the system will be implemented. System Requirements Specification Report. Various Sources. ANALYSIS. Design ideas/opinions. Select a design

dalmar
Télécharger la présentation

IMS9001 - Systems Analysis and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. System Architecture Components • Processing • Data • Communication These components are interrelated and must be considered in conjunction with each other.

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

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

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

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

  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.

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

  12. disk Master-slave Processing host CPU (running application)

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

  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.

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

  16. disk disk disk disk disk disk Peer-to-peer

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

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

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

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

  21. Distributed computing and systems • See class handout

  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 dataand 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-tieredclient/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.)

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

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

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

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

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

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

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

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

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

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

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

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

  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

  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

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

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

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

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

  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.

  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.

  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

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

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

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

  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

  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

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

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

More Related