Modeling

Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4th edition, Prentice Hall, 2009.

Hans Van Vliet, Software Engineering: Principles and Practice, third edition, John Wiley & Sons, 2008.

What Is a Model?

• Pairs (2 minutes)

2

Models

• ‘Complete’ meaning no additional information is needed to understand the system from that perspective

• abstraction of some entity – understand before build – omits nonessential details

• examples: – architectural models to show customers – airplane scale models – storyboards of advertisements – outlines of books

3

Why Build a Model?

• Purposes of a model– Testing a real entity before building it – Communication with customers – Visualization – Reduction of complexity

4

What Types and How Many?

• No consensus but multiple models of different types, e.g., 4+1 view model of S/W architecture1

5

Logical view Development view

Physical viewProcess view

Scenarios

1 P. Kruchten. The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November 1995.

4+1 View Model

• Use case view– functionality of system from outside perspective, e.g., in UML use

case diagram• Logical view

– description of system's parts, e.g., in UML class, object, state machine, and interaction diagrams

• Process view– description of process within system, e.g., in UML activity diagram

• Development view– organization of system's part into modules and components, e.g.,

in UML package and component diagrams• Physical view

– system's parts into real-world entities, e.g., in UML deployment diagram

6

Different Models

Several models will be considered in developing our system

• Use case model: describes requirements from the user perspective

• Design model: describes classes and objects

• Implementation model: source code

• Test model: test cases and test procedures

7

Investigate:

• People and machines playing some role (actors)

• Items produced, consumed, or modified

• Functions performed

• Modes of operation that determine when functions are performed

8

Analysis

• All aspects of the problem domain need to be investigated.

• Decompose the problem into smaller problems until the entire problem is fully understood.

• The models that depict information, function, and behavior must be constructed in a manner that uncovers detail.

9

Note:

• "Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.";

• "Essentially, all models are wrong, but some are useful."

– George E.P. Box & Norman R. Draper, Empirical Model-Building and Response Surfaces (Wiley 1987) pp. 74 and 424. (Professor of statistics, U of Wisconsin)

10

Operational Principles: Analysis Methods

• The information domain of a problem must be represented and understood.

• The functions that the software is to perform must be defined.

• The behavior of the software (as a consequence of external events) must be represented.

11

Modeling Views

It all comes down to these:• Objects: data• Functions: transformations of data• States: transitions controlling transformations

Functional

Data

Behavior STD ScenariosEvents

DFDFunctional decomposition

ERD

12

Data (Static) Models

• Used to understand the data and actors in a system

• Abstraction of the information needed and generated by the system

• Describes the problem domain

• Helps identify, classify, and abstract the problem

13

Function (Transformational) Models

• Used to understand the transformations that take place in the system

• Used to understand the inputs and outputs for computations

14

State (Dynamic) Models

• Used to understand states and modes of the system

• Used to specify the flow of control through the system and system components

15

Modeling

DataDictionary

Object Model - static, structural, data aspects of system

Dynamic Model - temporal, behavioral, “control” aspects of system

Functional Model – transformational, “function” aspects of system

E-RDiagram

Class Diagram

State-Transition DiagramDecision TablesCollaboration Diagram

Data-flowDiagram

16

Static Models

• Entity Relationship Models

• Class Models

17

Dynamic Models

• Event trace– Show a sequence of events and

associated responses

• Message sequence chart– Enhanced event trace notation– Vertical lines are entity time lines (time

flows from top to bottom)– Horizontal lines are messages or events

18

Dynamic Models (Cont.)

• State Machines– Should remind you of FSMs from theory. – Nodes are states– Arcs are transitions

• Event (condition)/action• Instantaneous

• Statecharts: UML state machine notation

19

Functional Models

• Data Flow Diagrams – Processes– Data– Data store

• Use Cases

20

Static Models

• Pairs (10 minutes)– Read about ER diagrams PP 263-265

• What are the nodes (node types)?

• What are the edges?

21

In Class: Diagram the Following

• A library has books and journals, and each can be checked out.

• A patron has a name, a UTEP ID number, an address.

• A patron can check out any number of books or journals.

• When a book or journal is checked out, it must be returned in 5 days (so we must keep track of the checkout date)

22

In Class: Static Models

• Show how you can use an ER diagram to represent – Association– Aggregation– Generalization– Composition– role names– multiplicities

23