1. CS 310 Ch8: System models Abstract descriptions of systems being analyzed to help the analyst understand the system functionality communicate with customers Models present the system from different perspectives external perspective for the system’s context or environment behavioural perspective showing the behaviour of the system structural perspective showing the system or data architecture

2. Models 8.1 Context Models (illustrate the system boundaries) Architectural models show a system and its relationship with other systems Process models show the processes that the system supports. Used to describe a system’s overall behaviour. 8.2 Behavioural models (how a system behaves) Data flow models (DFD)* show how data moves through the system State machine models show the systems response to events 8.3 Data Models (ER diagrams and data dictionaries) 8.4 Object Models (like C++ classes) 8.5 Structured methods * Very little difference between DFD and process models

3. Context model: an ATM system This is architectural, it says nothing about how systems interact the system

4. Equipment procurement process Process models needed to describe activities

5. 8.2.1 Data-flow models Data flow diagrams (DFDs) show the processing steps as data flows through a system from a functional perspective simple and intuitive notation that customers can understand Similar to process diagrams, with the focus on data flows tracking and documenting the data associated with a process helps to develop an overall understanding of the system Data flow diagrams may also show what data is exchanged with other systems in the environment

6. Order processing DFD How does this differ from an architectural process model? In the way it is arrived at: one is derived from what information passes through the system, the other from what is happening May be a small piece of one of the bubbles in the process model

7. 8.2.2 State machine models Model the system response to external and internal events Often used for modelling real-time systems Conventions: system states are nodes events are arcs between these nodes when an event occurs, the system moves from one state to another

8. State machine: microwave oven state name what it does state transitions

9. Microwave oven expansion of the Operation state *

10. Context (8.1) versus Behavioral Models (8.2) Context: defines system boundaries high level: fig 8.1 shows simple boundaries lower level process diagrams (e.g. fig 8.2) show activities, distinguishing between internal and external activities Behavioral: how it behaves data flow (like process, but emphasis is on data) »sometimes an elaboration of an activity in a process model state machine

11. Sign On Select Option Send Message Process Diagram for IM Operation... Select SN Validate SN/PWD SN/pwd invalid sign on Present Options SN send/SN Send Message DFD for IM Sign On

12. 8.3 (Semantic) data models Describe the logical structure of data processed by the system using ER model How does this differ from CS 325 notation?

13. 8.4 Object models Describe the system in terms of object classes: a set of objects with common attributes and the services (operations) Natural way to reflect the real-world entities Abstract entities are more difficult to model this way Types inheritance models aggregation models interaction models What do you know about object models?

14. Library class hierarchy 8.4.1 Inheritance models

15. Multiple inheritance Object classes can inherit from several super-classes Can lead to semantic conflicts when attributes/services with the same name in different super-classes have different semantics Makes class hierarchy reorganization more complex

16. Object aggregation

17. 8.4.3 Object behaviour modelling using a UML sequence diagram

18. 8.5 Structured Methods Often a company will have a well-defined modeling process Structured methods define a set of models a process for deriving these models rules and guidelines that should apply to the models Normally with specific CASE tool support This can be too restrictive More commmon practice: use a variety of models to elicit requirements