CS /31 Illinois Institute of Technology CS487 Software Engineering Analysis Modeling Instructor David Lash

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

CS /31 Modeling

CS /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.

CS /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.

CS /31 System Context Diagram

CS /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.

CS /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)

CS /31 Initial System Context Diagram

CS /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.

CS /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.

CS /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

CS /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

CS /31 Partitioning - Example

CS /31 Partitioning - continue example

CS /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.

CS /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

CS /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

CS /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

CS /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

CS /31 Data Modeling - Relationships Example

CS /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

CS /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

CS /31 ERD u Cornerstone of the Data Model u Diagram the DO, Relationships and attributes

CS /31 Example of Modality and Carnality

CS /31 Example of ERD

CS /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

CS /31 ERD II example - Homesafe (Basic Relations)

CS /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

CS /31 ERD II example - Homesafe

CS /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.