Chapter 3 Model & Views of SSADM

1. Chapter 3Model & Views of SSADM Prepared by: [Miss SharifahRabeahSyedTaha] com3033

2. 3. Requirements Specification Stage 3: Definitions of Requirements How is SSADM Structured? 1. Feasibility Study Stage 0: Feasibility 2. Requirements Analysis Stage 1: Investigation of Current Environment Stage 2: Business Systems Options 4. Logical System Specification Stage 4: Technical System Options Stage 5: Logical Design Each step follows on from the previous complete step 5. Physical Design Stage 6: Physical Design

3. Module 1: Feasibility Study 1. Feasibility Study • Examine whether project is technically, financially and socially feasible • In other words – whether it is in concordance with the current business model • Determine whether the project is cost-effective (benefits vs. costs) Stage 0: Feasibility

4. Module 2:Requirements Analysis • Stage 1: Investigation of current Environment • Learn the terminology and function of the users’ environment • The current system forms the basis • Understand the data required • Set the system boundary clearly • Model the current system in terms of processes (DFD) and data structures (LDS) • Analyse the business operations for problems etc. • Users are involved in walk-through at the end of this stage • Stage 2: Business System Options • A decision is made by users as which option best meet their needs 2. Requirements Analysis Stage 1: Investigation of Current Environment Stage 2: Business Systems Options

5. 3. Requirements Specification Stage 3: Definitions of Requirements Module 3:Requirements Specification • A detailed specification of the required system is built up and checked extensively. • Requirements are defined for processes and data structures modelled in the previous step. • Both functional and non-functional requirements are defined • The selected way to go is developed and refined, ELHs introduced

6. Module 4: Logical System Specification 4. Logical System Specification • Stage 4: Selection of technical options Cost/benefit analysis is performed for each of the system’s hardware and software options • Stage 5: Logical design The specification developed in stage 3 is expanded to a high level of detail: • Define the logic of databases, user dialogues etc • Define update and operations processes • Define how enquiries are processed • Define the sequence of logical processes Stage 4: Technical System Options Stage 5: Logical Design

7. Module 5: Physical Design • The complete logical design - both data and processing is converted into a design that will run on the target environment. • Logical and Technical Specifications are used to produce a physical database design and a set of program specifications, i.e. how the programs should work • Create function component implementation map (FCIM) to document the logical to physical mapping • Optimise physical data design • Complete function specification • Consolidate process data interface • Assemble physical design 5. Physical Design Stage 6: Physical Design

8. 3 techniques / 3 viewpoints • SSADM uses a combination of three techniques: • Logical Data Modeling • Underlying structure of the data in the system: entities and their relationships • ERD • Data Flow Modeling • Data flows in / out of the system and any data transformation • DFD • Entity Behaviour Modeling • The way in which data in the system changes over time by events acting on entities • Sequence Diagram com3033

9. 1. Logical Data Modeling • Logical Data Modeling: is the process of identifying, modeling and documenting the data requirements of the system being designed. • The data is separated into entities (things about which a business needs to record information) and relationships (the associations between the entities). com3033

10. Entities • Entity - A thing that is of interest to an organisation about which information is stored • The items of interest are called ATTRIBUTES • Example • System = ACT Library • Entity 1 = Student • Example = Mohd Nizam Jatim • Entity 2 = Books • Example = System Analysis and Design • Attributes • ????

11. Logical Data Structure (LDS) • A diagram to show RELATIONSHIPS between entities • e.g. A TUTOR teaches many STUDENTS Tutor Students teaches • Alternative names • Data Model • Entity-Relationship Model • Bachman Diagram

12. University Student Building an LDS • Identify the entities • Find the RELATIONSHIPS between them • Decide the CARDINALITY University Student University Student 1 Many

13. Doctor Doctor Doctor Patient Patient Patient Optionality • Must, Must • May, Must • Must, May • May, May Doctor Patient

14. Relationship Link Phrases • Each…[must be/may be]….[one or more/one and only one] • e.g. Each DOCTOR may be responsible for one or more PATIENTS

15. To make a good LDS • Do not create ENTITIES from Attributes e.g. A Human has 2 ARMS (These are attributes) • Do not put in unnecessary links • Avoid Many-to-Many relationships These cause problems as it is difficult to trace which example of entity A refers to which of entity B. Put an extra entity in between. Flight Ticket Passenger

16. Example: BENCO plc • CUSTOMERS make sales ORDERS • A single order has several PRODUCTS • Each customer is in one of 621 AREAS • Each customer is serviced by one of 20 DEPOTS • Each customer is allocated a depot depending on their customer location • All products are stocked in depots Customer Order Product Area Depot

17. Example: BENCO plc • CUSTOMERS make sales ORDERS • A single order has several PRODUCTS • Each customer is in one of 621 AREAS • Each customer is serviced by one of 20 DEPOTS • Each customer is allocated a depot depending on their customer location • All products are stocked in depots Customer Order Order Line Product Area Depot

18. Example: BENCO plc • CUSTOMERS make sales ORDERS • A single order has several PRODUCTS • Each customer is in one of 621 AREAS • Each customer is serviced by one of 20 DEPOTS • Each customer is allocated a depot depending on their customer location • All products are stocked in depots Customer Order Order Line Product Stock Item Area Depot

19. More advanced notations Exclusivity Building Bank Society Account School Sub Types Private Public School School

20. SSADM LDM A Logical Data Model consists of: • Logical Data Structure • Entity description • Relationship description • Attribute descriptions

21. 2. Data Flow Modeling • Data Flow Modeling: is the process of identifying, modeling and documenting how data moves around an information system. • Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). com3033

22. Data Flow Diagram (DFD) • Maps the route of data around a system Data Source and Sink Data Store Flow Line Process • is easy to understand and communicate • does not show procedures and control as a flowchart does

23. Representing the process Person or entity Process responsible for process number 2.3.4 Sales Process customer order Process descriptor

24. Customer Payment Process Customer Customer Payment Deposit Bank 1 Process Payment Remittance data 1 Receivables information Credit manager 2 Accounts receivable 2 Update receivables

25. Basic rules for a DFD • Data does not flow directly between processes • Data does not flow directly between data stores • Data cannot be transferred directly from store to sink or source to store

26. What are the inputs? What are the outputs? How to get a DFD • Method by Tom De Marco • Identify all net input and output data flows of the system • Work your way from inputs to outputs, backward from outputs to inputs, or from the middle out • Label all the interface data flows • Label all the functions/processes From, input to output From output to input From middle out

27. Sales Dept. How to get a DFD Method by Geoff Cutts 1. Create a physical document flow diagram Use ‘Ellipse’ to represent a person or department/section Order form Picking notes Customer Warehouse Invoice Dispatch note Cheque Accounts Dept.

28. Sales Dept. How to get a DFD 2. Identify the boundary of the system. Draw dotted line to indicate the boundary. Anything outside the boundary will be the external entities (source and receipt of data). Order form Picking notes Customer Warehouse Invoice Dispatch note Cheque Accounts Dept.

29. How to get a DFD • Create the current physical DFD. Make processes of the ‘Ellipses’ inside the boundary Order form Process Order 1 Sales Dept. Picking notes Customer Warehouse Invoice Dispatch note Cheque Prepare Invoice 2 Accounts Dept.

30. How to get a DFD 4. Create the context diagram (Level 0), which shows the external interfaces with the outside world, i.e. the global view of a system. Sales & Accountancy System 0 Order form Picking notes Customer Warehouse Invoice Dispatch note Cheque

31. How to get a DFD 5. Create lower level diagrams. Each process can be expanded (decomposed) into lower levels and lower level DFDs show more details Level 1 1 After further investigations, process 1 may become 2 1.1 Level 2 – Reference ID is 1.1, 1.2 …. 1.2 Ensure inputs & outputs match 1.3

32. How to get a DFD • A system may have a set of DFDs with levels 0 to level N (3 to 4 is common). • Each level should have at the most 7 processes (easy to digest & to remember) • Those processes (functions) at the bottom level, which cannot be decomposed further, are called Primitive functions.

33. How to get a DFD • Ensure all data flows are given a name “A DFD cannot be considered to be completed unless all data flows and functions have been given a meaningful name” 7. Add Data Stores where needed

34. Signs of problems • Information sink – No output form a process • Write-only-files – File becomes larger • Overly complex interfaces - Octopus • Unnamable data flows • Unnamable processes

35. Types of DFDs • A physical DFD represents HOW things are happening. It contains the problems of the current system, and is people or machine dependent. It tends to contain redundant data stores/ processing. It tends to mention names of departments, people, forms, devices used and where data is stored • A logical DFD is extracted from a physical DFD. It is a logical representation of the system, which indicates WHAT the system accomplishes. It is implementation-independent: it focuses on the flow of data between processes without regard to the specific devices, storage location or people in the system.

36. Physical Logical Order form Order form Order Order Dispatch note Dispatch details Invoice Invoice Price information Price file Examples

37. Current Logical DFD Current SystemProblems Requirements for New System Current Physical DFD Required Logical DFD Sequence of building DFDs How the current system works What the current system accomplishes What the new system is required to accomplish

38. Required Logical DFD New Physical DFD Sequence of building DFDs (2) What the new system is required to accomplish Technical System Option chosen How the new system will work

39. From Physical to Logical DFD • Logicalise the data flowWhat data contents are required, remove physical descriptions e.g form/card • Remove time dependencies due to implementatione.g. The orders are not to be processed until the number is bigger than 20 • Logicalise the functionsRemove unnecessary processes, remove control information, functions which perform only physical tasks • Logicalise the data storesFor the data flows from or to a data store (physical), replace the data flow with the entity or entities referenced, and replace the physical data store with a logical data store

40. 3.Entity Behaviour Modeling • 3.Entity Behaviour Modeling: is the process of identifying, modeling and documenting the events that affect each entity and the sequence in which these events occur. com3033

41. Behavior Diagram • Behaviour diagrams emphasize what must happen in the system being modelled. Since behaviour diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems. • Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. • UML state machine diagram: describes the states and state transitions of the system. • Use case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases. com3033

42. Interaction Diagrams • Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of control and data among the things in the system being modelled: • Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system. • Interaction overview diagram: provides an overview in which the nodes represent communication diagrams. • Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages. • Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints. com3033

43. Activity Diagram • Activity Diagram • Describe the workflow behavior of a system.  • Activity diagrams are similar to state diagrams because activities are the state of doing something.  • The diagrams describe the state of activities by showing the sequence of activities performed.   com3033

44. com3033

45. State Machine • The behavior of an entity is not only a direct consequence of its input, but it also depends on its preceding state. • The history of an entity can best be modeled by a finite state diagram. • State Machine diagram can show the different states of an entity also how an entity responds to various events by changing from one state to another. com3033

46. State Machine com3033

47. Use case • A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. • It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. • It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. • The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. • Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. • A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system. com3033

48. com3033

49. Sequence Diagram • Sequence Diagram • displays the time sequence of the objects participating in the interaction.   • This consists of the vertical dimension (time) and horizontal dimension (different objects) com3033

50. com3033