SFDV Principles of Information Systems Lecture 5: Designing the Solution

2 Overview  Setting the context  What is the design phase?  Key design activities  Levels of abstraction (reification)  Benefits of modelling  An approach: The UML

3 # 6 # 5 # 7 Tut 3 # 8

4 Recall Simple Information System User InterfaceData/Processing

5 Here is an example of a building – Guggenheim Museum in Manhatten, New York Notes: Buildings are not simply built, they are designed first. So what tools can be used? Like the Civil vs Architecture engineering This is an example a sketch of the building This is elevation plan of the ground floor. Photograph shows Stakeholders, architect and 3D real-world model (from 1945) called a prototype

6  Objective:  Design solution system  Answers ‘how to do it?’ rather than ‘what to do?’  Main activities: 1. Design database 2. Design application 3. Design user interfaces 4. Design system interfaces 5. Create/evolve prototype 6. Design system controls SDLC Review: Design

7 Therefore, the aim of the design phase is to translate the requirements into a buildable solution.

8 Key Design Activities [Adapted: Satzinger et al., 2007] ActivityQuestion Network How will the various parts of the system communicate ? Architecture How will each system activity actually be carried out? User interface(s) How will users interact with the system? System interfaces How will the system will work with other systems? Database How and where will the system store the information? Prototype Have we created prototypes to clarify design decisions? System controls Can we be sure that the system will operate correctly and data is secure?

9 1.Network: Connecting system components and people with information. Typically preformed by a specialist such as a network engineer or systems engineer 2.Architecture: Describes how work will actually be carried out by people and computers. The kind of development environment and eventual deployment platform has a baring on how things work 3.User interfaces: Designed for optimal interactions with system. Recent roles such as usability specialists and human factor engineers used for this purpose 4.System interfaces: Define how system components and system can communicate with other parts of the system or other systems. Specify how system will exchange information between different services 5.Database: The underlying schema purposely designed for this system Lectures 7-9 will look at database in detail 6.Prototype: Confirm design choices and elicit feedback. 7.System controls: Protect data and ensure system works as it should Authenticaiton, authorised access and other protection measures. Design disaster recovery procedures and technology selection

10 Levels of Information Design High – Closer to Real World Low – Closer to Computer rep. Employ ee Salary EmployeeProjectRole Proje ct Budget 1: Specification 2: Implementation CREATE TABLE department ( dept_code CHAR(4), name VARCHAR2(30) NOT NULL, PRIMARY KEY (dept_code), UNIQUE (name) ); CREATE TABLE employee ( emp_id NUMBER(7), firstnames VARCHAR2(50) NOT NULL, surname VARCHAR2(50) NOT NULL, phone VARCHAR2(15), sex CHAR(1) DEFAULT 'F', dept_code CHAR(4) NOT NULL, PRIMARY KEY (emp_id), FOREIGN KEY (dept_code) REFERENCES department ); CREATE TABLE department ( dept_code CHAR(4), name VARCHAR2(30) NOT NULL, PRIMARY KEY (dept_code), UNIQUE (name) ); Abstraction spectrum ConceptualLogicalPhysical Business System Technology

11 1- Conceptual design: As close to the real world as possible  documenting the real world (ERDS, class diagrams etc.) Attempts to abstract or represent real-world information and relationships from domain Entirely independent of implementation concerns (i.e., No concern for the type of database to store resulting data) 2 - Logical design: More closely associated with documenting the real world in terms of corresponding, typically relational database structures (more specific). Specification: Applied to generic database solution Data model but not technology dependent Implementation: Technology chosen and database transformed to meet requirements of technology 3 - Physical design: Physical storage within the database Records, pointers, tracks, sectors, etc. As we will see handled by the DBMS and invisible to users.

12 Why use Models for Design?  Able to represent complex phenomena through abstraction  Represent intangible aspects of a system  A method of documenting the proposed system  An opportunity to clarify and refine design  Improve communication between stakeholders  Provide documentation for future maintenance  Add rigor to a project when used with CASE tools Approaches: Miniature replicas, Virtual 3D models (paper, wood, clay, wax, …), Blueprints, Diagrams on paper and Electronic designs

13 Modeling [Source: Stair and Reynolds, 2003]

14 Recall Source Documents [Source: Satzinger et al., 2004] CUSTOMER ADDRESS PRODUCT ORDER DETAIL PAYMENT ORDER HEAD

15 Resulting Conceptual Design

16 What Does Unified Mean?  Across historical methods and notations  Across the development lifecycle  Across application domains  Across implementation languages and platforms  Across development processes  Across internal concepts [Source: Rumbaugh et al., 2005]

17 Example UML Diagrams Class Collaboration Use Case State Machine

18 Example UML Diagrams (cont’) Activity Sequence Package

19 Class Shows Structure of system. Collaboration: Highlights how different parts of the system interact State machine: Represents potential life histories of an object of a class. (lifetime) Use Case: Models the functionality of the proposed system as perceived by people or things that interact with the system A use case itself is effectively a unit of functionality. Activity: Represents the flow of control for performing some task or computation Could tie to a Use Case diagram Sequence: Shows a set of message calls between objects over a time period Package: A way to organise models themselves by grouping in some way.

20 Summary  The design phase is concerned with how the solution will implement the requirements  Encompasses the transition from the requirements specification to the system blueprints  A variety of modelling approaches can be employed to visualise different aspects of the proposed system  The UML is a collection of inter-related diagramming notations for use primarily in design and analysis