1. CS48704-1/31 Illinois Institute of Technology CS487 Software Engineering Analysis Modeling Instructor David Lash

2. CS48704-2/31 Illinois Institute of Technology This level of modeling is the very highest level. The basic input-processing-output template.

3. CS48704-3/31 Modeling

4. CS48704-4/31 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.

5. CS48704-5/31 System Context Diagrams u Basic Version Of Diagram would be u Input -> Processing -> Output u Extend to include u User Interface, Input, System Functions and control, output and maintenance u Format for creating hierarchy of detail u Enable to define boundaries between the “software” and the operating (external) environment.

6. CS48704-6/31 System Context Diagram

7. CS48704-7/31 System Context Diagrams u Consider Conveyor Line Sorting System – CLSS developed such that boxes moving along a conveyor belt will be Identified and sorting into 1 of 6 bins at the end of the line. – Boxes pass a sorting stations where they are identifies – Based on ID number of the side, the boxes are shunted into the correct bin – Boxes pass in random order and evenly spaced. The line moves slowly.

8. CS48704-8/31 System Context Diagrams - CLSS u Consider Conveyor Line Sorting System - II – Has a PC sorting stn site. Boxes moving along conveyor belt identified and stored into 1 of 6 boxes at end of line. Boxes have bar code on side. – PC execs software, interacts with bar code rdr and conveyor line monitoring equipment (to get speed of line) – stores parts numbers sorted and interacts with operator – sends signals to shunting hardware – sends out reports and communicates with server in factory floor. (pg 265)

9. CS48704-9/31 Initial System Context Diagram

10. CS48704-10/31 Refine Into a System Flow Diagram u Page 265 shows refined diagram – Look at important lines of data and control flow. – Might be the top level of a series of SFDs that are later developed (See page 266.

11. CS48704-11/31 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.

12. CS48704-12/31 Partitioning u A straightforward way to break-down a complex system (divide and conquer) – decompose system into parts u create a hierarchical representation of function/information by – More detail by moving vertically – functional decomposition horizontally

13. CS48704-13/31 Partitioning - Home Safe u Specification From Requirements gathering (interview) – HS monitors sensors, interacts with owner via keypad (via control pad) – Control pad can be program and config system – Master passwd is programmed for arming and alarming system. Phone numbers are input for dialing out for help. – When sensor event, alarm then after T time, dial phone number and downloads event info (sensor, time, type of event). Repeat every 20 seconds

14. CS48704-14/31 Partitioning - Example

15. CS48704-15/31 Partitioning - continue example

16. CS48704-16/31 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling - (See page 301 diag) – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.

17. CS48704-17/31 Data Modeling u DM answers questions like: – What are data objects in the system – What are the Data Objects made of – How are they related u One common method is the ERD - Has the following pieces: – Data Object: representation of something with attributes E.g., Width (1 property) VS dimension (HGt, width) – Relationship: The nature of the connection between data Objects.. – Attributes: properties that describe the object

18. CS48704-18/31 Data Modeling - Data Objects u Data Object - representation of object with multiple properties that software deals with: – width VS Dimension – car (color, engine, body style) – Dashboard u DO can be – something producing information (e.g., report) – occurrence - phone call, event – role - salesperson, manager, engineer – place - warehouse, house, Chicago, – physical thing - car, saw, airplane, – structure - directory, file, u DO in system have some relationship – CAR has an ENGINE

19. CS48704-19/31 Data Modeling - Attributes u Attributes - define the properties of the DO They can: – name an instance of the DO – describe the instance – point to another table – 1 or more attributes become the key or identifier. – Attributes that are used depend on the problem. Make MODEL ID# BodyTYPE COLOR OWNER Lexus LS400 AB123 Sedan Blue DAL Chevy Vette XYZ1 Sports RED ABC - ID# is a key or identifier - OWNER is points or refers to another DO - others are naming and descriptive attributes - An instance is 1 row e.g., lexus - DO is CARS

20. CS48704-20/31 Data Modeling - Relationships u Relationships - define how DO are connected: – DO1 - books DO2 - bookstore – Within the software u bookstore orders books u bookstore displays books u book stores stocks books u bookstore sells books u bookstore returns books

21. CS48704-21/31 Data Modeling - Relationships Example

22. CS48704-22/31 Data Modeling - Relationships (Cardinatlity) u Just saying DO1 related to DO2 need more info – How many DO1 are related to DO2? u Relationships have characteristics: – Cardinality – The number of occurrences that that 1 DO can be related to another: - one-to-one (e.g., husband only 1 wife) - one-to-many. (e.g., mother many Children) –Child to have 1 mother - many-to-many (e.g., uncle many nephews, Nephew many uncles) - Defines the maximum number of DO in a relationship. - Does not indicate if a particular instance must participate

23. CS48704-23/31 Data Modeling - Relationships - Modality u Modality – How required is the relation. – 0 – when no explicit need for relationship to occur – 1 – when an occurrence is mandatory

24. CS48704-24/31 ERD u Cornerstone of the Data Model u Diagram the DO, Relationships and attributes

25. CS48704-25/31 Example of Modality and Carnality

26. CS48704-26/31 Example of ERD

27. CS48704-27/31 ERD II example - Homesafe u Enables homeowner (HW) to config security system (SS), during install u HS monitors all sensors connected to SS u HS interacts with HW via Keypad on cntl panel (CP) u CP is used to program system u Each sensor (SEN) is assigned a # and type u A master passwd is programmed, Tel number are input for dialing on Sensor event (SEN) u on SEN event, alarm invoked & SS dials phone number, and gives info to (MS) monitoring Service u CP has keyboard input stuff

28. CS48704-28/31 ERD II example - Homesafe (Basic Relations)

29. CS48704-29/31 ERD II example - Derived Relationships u SS monitors sensor u SS enables/disables sensor u SS tests sensor u SS program sensor u Attributes of Sensor has type, internal id, zone location, alarm level

30. CS48704-30/31 ERD II example - Homesafe

31. CS48704-31/31 High-Level Modeling Tools u System Modeling – System Context Diagram – Partitioning u Data Modeling – Entity-Relation - Data objects and their relationships u Information flow diagrams – Data flow diagrams - how data transforms in system- how functions transform data u Control Specifications – State diagrams - how system behaves as result of external events.