Models are simplified representations of reality (abstractions).
p. 152: sample of models often used in system design.
p. 148: "The process of creating a model helps an analysis clarify and refine the design."
Models allow (internal) clarity; essentials only.
Models allow decomposition of complex data and behavior in simpler parts.
Models imply that irrelevant data clutter is ignored; essentials only.
Formalization using models enables integrity checking (consistency, completeness, uniqueness; e.g., relational normal form).
p. 149: "Models also assist in communication with the system users and foster understanding."
Be very, very careful!! What is the danger here?
Please ignore the typology of models on pages 150-151.
Scenarios have a low level of abstraction --> high level of (nonessential) detail.
Software has higher level of abstraction --> additional modeling required.
Events or Occurrences:
Time (absolute and relative).
Place (absolute and relative).
Actors/agents: persons, organizations (e.g., groups, depts, etc.), or even a machine or program.
Events trigger behavior which may include other events.
External vs. internal events:
External events: Coming from outside the system:
User clicks a menu option or button.
Email is delivered.
HTTP request received.
Etc.
Internal events: generated from within the system:
Customer's credit balance is updated based on received payment.
Shipping order is sent to shipping Dept.
Daily sales reports are automatically generated and emailed.
Hourly error-checking fails test and alarms are sent out.
Scheduled (p. 156: temporal) vs. trigger-based (p.157: state) events:
Problem: do you see a relationship between scheduled/triggered and external/internal?
Originated in real-time (engineering) systems:
Building/environmental monitoring (e.g., update system when new data point received (http://blt.colorado.edu).
Industrial process control (e.g., shut off valve when pressure reaches x Pa (1 Newton per meter squared)).
Household goods/electronics:
Breaker, fuse or GFCI: interrupt current when amperage reaches X.
Switch on furnace when temperature drops below Y.
Pressure release valve on high pressure cooker.
Etc.
All events have consequences (an event without a consequence is irrelevant for the system; should be abstracted out or removed from the model as nonessential).
Sequences of conditions, events and consequences determine the behavior of the system.
Nowadays, most user interfaces follow the event model: if this happens, do that.
Things:
Things discretize the world; fits the binary/logical universe of software engineering.
Things have attributes.
Things have relationships.
Relational integrity constraints.
Hierarchy (ako).
Things have behavior (state transitions).
Things can communicate.
Object-oriented Programming (OOP): Programs that consist of things as objects which are grouped in classes that have attributes and behavior; i.e., the objects undergo state transitions and communicate with each other.
