1. CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Analysis Techniques Basic Structured Modelling Techniques

2. CC20O7N - Software Engineering 1 Contents Introduction Functional Sub-model Data Sub-model Dynamic/Behavioural Sub-model Relationship between these (Sub)Models

3. CC20O7N - Software Engineering 1 Sub-models Functional Model describes the functionality of the systems from the user’s point of view. (DFD, use case diagram, etc.) Data Model consists of three interrelated pieces of information: the data object, the attributes that describe the data objects, and the relationships that connect data objects to one another. (ERD) Dynamic/Behavioural Model describes the components of the systems that have interesting behaviour. (DFD, statechart diagrams, sequence diagrams, activity diagrams, etc.)

4. CC20O7N - Software Engineering 1 Different Systems/Applications- Different Emphasis Information Systems – the emphasis on data and functional sub-models Process Control Systems – the emphasis on functional and dynamic sub-models

5. CC20O7N - Software Engineering 1 Functional Sub-model Functional Model describes the functionality of the systems from the user’s point of view. (DFD, use case diagram, etc.) The main basic modelling technique is Data Flow Modelling. It involves the development of Data Flow Diagrams (DFDs) and (in addition) Elementary Process Specifications and Data Flow and Data Store definitions (part of Data Dictionary) In SSADM this is followed by Function Definition and Conceptual Process Modelling (ECDs, EAPs, UPMs, EPMs - to specify elementary processes in more detail). ECD:Effect Correspondence Diagram, EAP: Enquiry Access Path, UPM: Unconstrained Process Model, EPMs: Entity Process Models

6. CC20O7N - Software Engineering 1 Data Flow Diagrams (DFDs) - Main Elements (notation) Yourdon SSADM name

7. CC20O7N - Software Engineering 1 DFDs Main Elements (meaning) PROCESS - processes show what systems do. Each process has one or more data inputs and produces one or more data outputs (there are some exceptions but very rare!) DATA FLOWS model the passage of data in the system DATA STORE (FILE) is a repository of data. It contains data that is retained in the system (persistent data). Processes can enter data into a data store or retrieve data from the data store. TERMINATORS are outside the system, but they supply input data into the system and/or use the system output e.g other systems, other organisations, system users, departments outside the system, etc

8. CC20O7N - Software Engineering 1 DFDs - Basic Rules 1 Data flows can be drawn between: two processes (only when they are ‘tightly’ coupled i.e. they are ‘executed’ in the same, relatively short time ‘frame’) a data store and a process a process and a terminator Data flows must not be drawn between two data stores !!! Avoid (if possible) flows between terminators and data stores, and between two terminators.

9. CC20O7N - Software Engineering 1 DFDs - Basic Rules 2 ‘Dodgy’ Situations (to be double checked) are: processes with inputs only processes with outputs only data stores with inputs only data stores with outputs only does each process receive all the data it requires? are all main data flows labelled?

10. CC20O7N - Software Engineering 1 Simple DFD - Example (Yourdon’s Notation)

11. CC20O7N - Software Engineering 1 DFD - SSADM Notation

12. CC20O7N - Software Engineering 1 DFDs - ‘Leveling’ The idea of ‘levelling’ is to present the system at different levels of detail. The top-level diagram (level 0) is known as the context diagram (it models the whole system as a single process). The level 1 DFD gives an overview of the whole system, identifying the major processes, data flows and data stores. Processes from level 1 can be expanded to show more detail (if necessary) at level 2. Processes from level 2 can be further expanded, etc.

13. CC20O7N - Software Engineering 1 ‘Leveling’ (cont.) In the classical approach DFDs are built in a top-down fashion. First of all the context diagram is produced, next it is refined/partitioned into lower-level DFDs. In a lower-level DFD, a process (from a higher level) is expanded to reveal more details. The numbering convention for ‘parent’ and ‘child’ processes is as follows: if the parent’s no is e.g. 5 then its ‘children have numbers 5.1, 5.2, 5.3, etc. Typically when we get to the point at which the operation of a process can be described in about half page using a pseudo code/structured English, We can stop partitioning. Processes which have not been partitioned (decomposed) are called ‘atomic’ or elementary processes. They belong to a ‘bottom’ level.

14. CC20O7N - Software Engineering 1 ‘Levelling’ - Balancing Rules Balancing rules require that data flows entering or leaving a parent diagram (i.e. a process at a higher level) must be equivalent to those on the ‘child’ diagram. It means that new flows may not be arbitrarily introduced at lower, more detailed levels !

15. CC20O7N - Software Engineering 1 Simple Bank - Context DFD i.e. Level 0

16. CC20O7N - Software Engineering 1 Simple Bank -Level 1 DFD

17. CC20O7N - Software Engineering 1 Simple Bank - Level 2 DFD

18. CC20O7N - Software Engineering 1 Example of Process Specification using Structured English/pseudocode for Register customer i.e. Process 1 Get Reg_details Generate Account No Customer Record = Cust Name, Cust Addr, Cust Tel No. Write Customer Record to Customers Balance = 0 Account Record = Account No., Balance, Curr Date Write Account Record to Accounts

19. CC20O7N - Software Engineering 1 Structured English/pseudocode Notation It combines the precision of a formal programming language (e.g. C, Pascal, Java) with the casual informality and readability of the English language (or any natural language) It means that it provides the keywords to structure process specification logic (e.g. IF, ELSE, WHILE, etc) while leaving some freedom when describing the activities and data used in the process

20. CC20O7N - Software Engineering 1 Structured English/pseudocode Notation (cont.) Possible notation Boolean and arithmetic operators = assignment operator Control structures such as: WHILE, IF ELSE, DO WHILE, etc Indentation is used to show groups/blocks of statements/ activities e.g. within WHILE structure Get, Display (or Input, Output) to input/output data Read, Write to read and write records of data (from and to data stores)

21. CC20O7N - Software Engineering 1 The Data Dictionary The data dictionary is an organised listing of all the data that are pertinent to the system with precise, rigorous definitions. A typical data dictionary includes definitions/ descriptions of: data flows, data stores and entities (from the data sub-model) As data flows and data stores are ‘made up’ of data structures and data elements, these data structures and elements also should be described/defined!

22. CC20O7N - Software Engineering 1 Data Dictionary- notations There are many different ‘data dictionary notations’. All are ‘structured’ notations i.e. they allow to specify sequences, iterations and ‘selections’ of data elements and data structures Examples of some notations: Jackson diagrams, BNF (Backus Naur Form ) notation, etc

23. CC20O7N - Software Engineering 1 Data Dictionary – BNF Notation The notation is summarised below: =is composed of (definition) +and (sequence of data) { }iteration/repetition of data [ | ]selection (either or) of data * *comment ()optional data

24. CC20O7N - Software Engineering 1 Data Dictionary Examples of BNF definitions: Reg_Details = Cust Name + Cust Addr + Cust Tel No. + Account No. * data flow* Cust_Details = Cust Name + Cust Addr + Cust Tel No. Accounts = {Account} *data store* Account = Account No. + Balance + Date Opened *entity*

25. CC20O7N - Software Engineering 1 Data Sub-model Data Model consists of three interrelated pieces of information: the data object, the attributes that describe the data objects, and the relationships that connect data objects to one another. (ERD) The main modelling technique is Entity Relationship modelling (Logical Data Modelling - LDM in SSADM). It involves the development of Entity Relationship Diagrams (E-R diagrams, ERDs, LDS in SSADM) and Entity Definitions/Descriptions (part of Data Dictionary)

26. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Entity Entity (or an Entity type) – any object or concept about which a system needs to hold information. Examples of entities; Library system: Book, Reader, Loan, Reservation, etc Doctor’s surgery system: Doctor, Nurse, Patient, Appointment, etc Each entity (Entity type) must have a number of real-world occurrences (instances). For example in a typical Library system (see above) there are many instances of Book, Reader, Loan, etc.

27. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Entity (Cont.) An entity must have a number of properties to qualify as such: 1.There must be more than one occurrence/instance of the entity. 2.Each occurrence/instance should be uniquely identifiable. 3.There must be data that we want to hold about the entity. 4.It should be of direct interest to the system.

28. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Entity (Cont.) Each data item that we hold about an entity is known as an ATTRIBUTE. For example some of the attributes of Book might be: Book Number, Title, Year, etc The symbol for an entity in an ERD is a round-cornered rectangle with the entity’s name Book

29. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Relationships Relationship – a logical association between two entities (or between an entity and itself) In physical data structures these relationships are represented by physical links such as pointers, etc In logical models relationships represent business associations or rules and NOT physical links!

30. CC20O7N - Software Engineering 1 Entity Relationship Modelling – Relationships (Cont.) Relationships have two important properties: – Degree – Optionality Degree – the number of occurrences of each entity type participating in a given relationship Optionality – if there can be occurrences of one entity that are not related to at least one occurrence of the other, then the relationship is said to be optional for that entity.

31. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Relationships (Cont.) There are three types of degree: 1.Many-to-many (m:n) Each occurrence of A is related to one or more occurrences of B, and each occurrence of B is related to one or more occurrences of A A B

32. CC20O7N - Software Engineering 1 Entity Relationship Modelling- Relationships (Cont.) 2. One - to - many (1:m) Each occurrence of A is related to one or more occurrences of B, but each occurrence of B is related to only one occurrence of A

33. CC20O7N - Software Engineering 1 Entity Relationship Modelling – Relationships (Cont.) 3. One-to-one (1:1) Each occurrence of A is related to only one occurrence of B, and each occurrence of B is related to only one occurrence of A A B

34. CC20O7N - Software Engineering 1 Entity Relationship Modelling –Relationships (Cont.) Optionality – if there can be occurrences of one entity that are not related to at least one occurrence of the other, then the relationship is said to be optional for that entity. Each A may be related to one B; Each B must be related to one A Dashed line denotes optional relationship

35. CC20O7N - Software Engineering 1 E-R Diagrams (Using SSADM Notation) Customer Customer/Account link Transaction Account

36. CC20O7N - Software Engineering 1 Entity Definitions/Descriptions In some organisations only brief descriptions/definitions will be required, while in others they may consist of several sections including details of attributes, relationships, volumes of data, user access, etc For CC2F07N brief descriptions/definitions will be used which list attributes and show primary keys. These descriptions can be included in Data Dictionary (together with definitions of data flows and data stores).

37. CC20O7N - Software Engineering 1 Examples of Simple Entity Definitions Customer = Cust No + Cust Name + Cust Addr +Cust Tel No…. Account = Account No. + Balance + Date Opened…. alternatively they can be specified as follows e.g: CUSTOMER Cust No Cust name Cust Addr Cust Tel No

38. CC20O7N - Software Engineering 1 Dynamic Sub-model Dynamic Model describes the components of the systems that have interesting behaviour. Modelling techniques for this sub-model include Entity Life Histories (ELHs), State Transition Diagrams (STDs) etc. in O.O. statechart diagrams, sequence diagrams, activity diagrams, etc.

39. CC20O7N - Software Engineering 1 Entity Life Histories (Using Jackson Notation Adopted in SSADM) Management Products Account Account life Account closed Account opened * DepositWithdraw oo Management Products Account Account life Account closed Account opened * DepositWithdraw oo

40. CC20O7N - Software Engineering 1 Relationships between Sub-models

41. CC20O7N - Software Engineering 1 How Is the SDLC Used In This Class? Clearly, the SDLC requires significant time, human resources and technical resources to perform well. For the class project, your team must implement the SDLC steps as follows: – Systems Planning (project requirements summary, project team description, preliminary work schedule, service area demographic analysis) – Systems Analysis (E-R diagram, Data Flow Diagrams, high-level functional description) – Systems Design (RDBM, Data Dictionary, identification/description of database objects, Web site map) – Systems Implementation (Access database, Web site content, elementary test plan) In addition, a White Paper will address practical systems implementation and operations/support issues.

42. CC20O7N - Software Engineering 1

43. Business Analysis with Data Flow Diagrams We initially claimed that entity-relationship diagrams could encode many business rules. But many elements of business processes cannot be represented by E-R diagrams: – Actors (individuals, organizations) which generate input data and/or receive output data; – Data transformations using specific business rules (which we said required application-level code); – Data storage or display that may or may not correspond to entities (e.g. views, reports, temporary tables, screens); – Data flows between actors, processes or data stores over time, and – Manual versus automated processing. Data Flow Diagrams (DFDs) are the link between initial business analysis, E-R diagrams and relational database models

44. CC20O7N - Software Engineering 1 Practical Significance of DFDs Many older information systems (legacy systems): – Are mainframe-based (inaccessible to most non-IT users); – Use non-relational (hierarchical) databases, and – Require second-generation programming languages (e.g. COBOL) to perform data input, queries, reporting. Thus, many IT professionals focus on data flows and physical implementation, not data relationships or RDBM design principles. Many business processes are so complex that E-R design alone will not give analysts insight into their businesses DFDs allow the analyst to determine: What does the organization do? How does the organization do it?

45. CC20O7N - Software Engineering 1 Creating DFDs Define Entities External entities represent persons, processes or machines which produce data to be used by the system or receive data that is output by the system Examples: Student, Customer, Client Define Processes Processes are discrete actions that transform input data to output data Examples: Create Student Record, Calculate Purchase Cost, Register Client Student 2.1 Create Student Record

46. CC20O7N - Software Engineering 1 Creating DFDs (cont’d) Define Data Stores Data stores are temporary or permanent repositories of information that are inputs to or outputs of processes Examples: Student Master, Client List Define Data Flows Data flows represent the transfer of data over time from one “place” (entity, process, data store) to another Examples: New Student Information (from Student, to Student Master) New Student Information (Templates are posted in l:\academic\90728\DFDSymbols.ppt ) Student Master D3

47. CC20O7N - Software Engineering 1 Creating DFDs (cont’d) Define the System A system is the collection of all business processes which perform tasks or produce outputs we care about. It is “what happens.” The system is a single process, connected to external entities Represented in a “Context Diagram” Define Subsystems A subsystem gives a more detailed view individual processes contained in the context diagram Includes data stores, more elementary processes (Figure 4.13, Shelly, Cashman and Rosenblatt)

48. CC20O7N - Software Engineering 1 DFDs Created by Top-Down Analysis Create a narrative: description of system Create a Context Diagram that contains a single process (“the system”) and all entities which share data with the system Explode the “parent” context diagram to produce a Diagram 0 (“child”) DFD Create Diagram 1, 2, …, n DFDs that represent “explosions” of Diagram 0, 1, …, n-1 DFDs until a diagram has only “primitive” processes Create process descriptions to be implemented by application programs: queries, macros, reports, programming languages Context Diagram Diagram 0 DFD Diagram 1 DFDs Diagram n DFDs Narrative E-R Diagram Process Descriptions

49. CC20O7N - Software Engineering 1 Where to Begin Creating DFDs Start with the data flow from an external entity and work forwards Start with the data flow to an external entity and work backwards Examine the data flows into or out of a data store Examine data flows, entity connections and data stores associated with a particular process Note fuzzy, ill-defined areas of the system for further clarification

50. CC20O7N - Software Engineering 1 What to Avoid in DFDs Making the data flow diagram too cluttered (e.g.  9 processes) 4 Perform Repair Processes with no outputs or no inputs 123 Many processes with a single input and output (linear flow) Processes whose inputs are obviously inadequate to yield outputs Having data flows terminate at data stores Connecting data stores directly to each other Courses Students Class List Connecting entities to anything other than processes Payroll Department Employees Process A Process B Process C

51. CC20O7N - Software Engineering 1 DFD Example: Bus Garage Repairs Buses come to a garage for repairs. A mechanic and helper perform the repair, record the reason for the repair and record the total cost of all parts used on a Shop Repair Order. Information on labor, parts and repair outcome is used for billing by the Accounting Department, parts monitoring by the inventory management computer system and a performance review by the supervisor. Key process (“the system”): performing repairs and storing information related to repairs External Entities: Bus, Mechanic, Helper, Supervisor, Inventory Management System, Accounting Department, etc. Processes: – Record Bus ID and reason for repair – Determine parts needed – Perform repair – Calculate parts extended and total cost – Record labor hours, cost

52. CC20O7N - Software Engineering 1 DFD Example: Bus Garage Repairs (cont’d) Data stores: – Personnel file – Repairs file – Bus master list – Parts list Data flows: – Repair order – Bus record – Parts record – Employee timecard – Invoices

53. CC20O7N - Software Engineering 1 Bus Mechanic Helper 0 Bus Repair Process SupervisorAccounting Bus Garage Context Diagram Mechanical problem to be repaired Labor Fixed mechanical problems Inventory Management System Repair summary List of parts used Labor, parts cost details

54. CC20O7N - Software Engineering 1 Practice Session of the modelling in the LAB of your own selected project One example will be discussed in the tutorial class Thank you