Three Case Studies in (Semi-Formal) System Modeling

Luca Vigan
Dipartimento di Informatica Universit di Verona

Ingegneria del SW, 13.04.11

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

1 / 57

Table of contents

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

2 / 57

The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

Goal: Specify the requirements as far as possible, but as abstractly as possible. Modeling languages and methods are used here!
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 3 / 57

Objectives of system modeling

To explain why the context of a system should be modeled as part of the requirements engineering process. To describe behavioral modeling, data modeling, and object modeling. To introduce some of the notations used in the Unied Modeling Language (UML). Today we will study three examples of using UML diagrams to model systems:
Class Administration Program. Simulations Program. Elevator Control.

Shows integration of diagrams in the modeling process. Disclaimer: 30-minute case studies are (over)simplications!
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 4 / 57

Analysis model

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

5 / 57

Example 1: Class Administration Program

Outline

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

6 / 57

Example 1: Class Administration Program

Example 1: Class Administration Program

Project: system to administer 4th year of a computer science degree. The status quo is as follows: In summer, a committee decides which course modules are offered in the next year (CS4). The dean makes the teaching assignments to the lecturers. Each lecturer creates a course description and sends it to the CS4 coordinator. Someone in the Undergraduate Teaching Ofce (UTO) produces a version of the course handbook. The CS4 coordinator produces a HTML version. The CS3-coordinator sends a student list to the CS4 coordinator and UTO. Each student has a supervisor that functions as Director of Studies (DoS). This assignment is made in the rst year. Students register for modules, the UTO checks validity, and the DoS is consulted in borderline cases. The UTO produces a lecture-participation list for each lecturer. Changes, administration of grades, ...
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 7 / 57

Example 1: Class Administration Program

Problem 1 (cont.)

These requirements are imprecise. Further analysis is needed to understand them.

Are students only CS-students? What must additionally be updated? (Webpages, ...) What is a course handbook? How many of them are there? What constitutes a valid module combination? In some universities, one must take advanced honors courses, etc.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

8 / 57

Example 1: Class Administration Program

Problem 1 (cont.)

Desired: an improvement of the status quo!

Less work for everyone, including the coordinator. On-line registration for teaching modules. On-line information. Support or automation of the production of teaching material (course handbooks) and lists.

Lets consider part of the requirements:

(We leave queries out standard support from database system.) Use Cases are:
Production of course handbooks. Administration from CS4 lists. Registration for modules.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

9 / 57

Example 1: Class Administration Program

A possible Use Case model

Create CS4 list

CS3 Course Organizer

CS4 Course Organizer

Produce Course Handbook

UTO

CS4 Lecturer

Register for modules

CS4 Student

CS4 Director of Studies

Produce Course Handbook: this Use Case takes place after the syllabus committee has determined the set of available modules and the department head has allocated duties to lecturers. The CS4 course organizer updates the core (module-independent) sections of each course handbook by getting the current text from the system, modifying it, and returning the modied version to the system. The lecturer of each module, similarly, updates the module descriptions by getting the text from the system, updating it, and returning it. The updates can happen in any order. When the updates are complete, the system sends a complete text of the handbook by email to the UTO, who prints it and updates the web pages.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 10 / 57

Example 1: Class Administration Program

Brainstorming with CRC Cards

Example: CRC cards for Produce Course Handbook:
HONORS COURSE Responsibilities Collaborators Keep collection MODULE of modules Generate course handbook text MODULE Responsibilities Keep collection of course Keep Lecturer of course

Collaborators

DIRECTOR OF STUDIES Responsibilities Collaborators Provide human DoSs interface to the system

Basis for class diagram and scenario simulation.

Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 11 / 57

Example 1: Class Administration Program

Class Diagram
Here is a rst version, which should be rened later.
Lecturer teaches 1 0..* Director of Studies directs 1 0..* Student takes 6 6..*

Module

1..*

1..* Non Graduating Student Graduating Student 0..* is on Honors Course

Questions: Which of the following statements are consistent with this model?
Not all lecturers teach some CS4 module. Not every DoS is a CS4 lecturer. All students must take an honors course.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 12 / 57

Example 1: Class Administration Program

Dynamic modeling
State-charts: no classes with interesting state transitions. Data modeling plays the largest role in design. Behavior is relatively simple. Activity diagram to model work-ow (e.g. task synchronization and dependencies):
Update core sections Determine modules

Allocate duties

Update module entry

syllabus committee

head of department

Print handbook lecturer UTO

Generate HTML version

CS4 course organiser

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

13 / 57

Example 2: Simulations Program

Outline

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

14 / 57

Example 2: Simulations Program

Example 2: Simulations Program

Project: Develop an integrated modeling environment to support discrete event simulation. Support the development of simulation models (e.g. a specialized CASE-tool) and their simulation. Based on a process-oriented view of simulation. Simulation should both report on events (system traces) and provide statistical summary information.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

15 / 57

Example 2: Simulations Program

A detailed description (potential classes in red)

System users are developers who build simulation models and check that they run without error, and experimenters who run them and collect statistics about what happens. Entities modeled are active entities and passive entities. Active entities represent things that carry out activities, like workers in a factory. When a real-life worker does something that affects other real-life things, the active entity modeling that worker causes a simulated event which affects those entities that model those things. Passive entities are resources, semaphores, and buffers. Although inactive, they affect the behavior of active entities, e.g. a process with insufcient resources blocks. Passive entities also report information on their state over time.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 16 / 57

Example 2: Simulations Program

Description (cont.)

The behavior of an active entity is determined by a sequence of events to be simulated. At any point in the simulation, an active entity is in one of three states.
1

2 3

Active, where it responds to an event. Only one active entity can be in this state at a time and its event time denes the current simulated time. Blocked, waiting for a request to be satised by a passive entity. Waiting for simulated time to reach this objects next event time.

Simulated events arise as messages either from a scheduler or from a passive entity whose state has changed. Simulated events should send messages to a trace le so that an experimenter can follow the internal behavior of the model.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

17 / 57

Example 2: Simulations Program

Description (cont.)

Statistics are collected by updating information about passive entities and other values for which information is needed. Examples of values being monitored and their derived statistics are counts of how many times something occurs and the average value over time of something like a queues length. The conditions under which a model executes are varied to observe how the system would respond. The values varied are read from an external data set, which is set up before the model is run.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

18 / 57

Example 2: Simulations Program

Use Cases model

Developer

create model

<<include>>

run a model

<<include>>
observe behavior

Experimenter

<<extends>>

collect statistics

create model: Developer creates an initial model by interacting with editing functions of the tool. He then creates a dataset and checks the model by following the behavior dened in the run a model Use Case. If there are errors, he modies the model and runs it again. observe behavior: Experimenter selects a model, created earlier (see create model). He selects or creates a dataset which determines conditions such as resources and durations of variable delays. He then follows the behavior in the run a model Use Case and, when the model has run, reads the trace generated.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 19 / 57

Example 2: Simulations Program

create model

Use Cases model (cont.)

Developer

<<include>>

run a model

<<include>>
observe behavior

Experimenter

collect statistics: Before using the run a model Use Case, the Experimenter sets a ag indicating that statistics should be collected and reported by writing them to a le at the end of the run.
collect statistics

<<extends>>

run a model: This Use Case assumes a model/dataset has been selected. The actor starts the model, which consists of instances of objects used to model and observe the system. Each active entity sets itself to an initial simulated event time and to an initial next simulated event, which it reads from the dataset. Each passive entity reads its initial settings from the same dataset. The entities act out behavior specied by the description of each active entitys life cycle, under the control of the scheduler, which ensures that events occur in the order of their simulated time. Passive entities ensure that constraints are respected. . . .
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 20 / 57

Example 2: Simulations Program

Class diagram: Version I (rough)

Scheduler 1 1 1 invokes asks time from 1 1..* Report 1 asks summary from 1..* Statistic {abstract} 1..* ActiveEntity {abstract} 1..* driven by 1 ExternalDataset 1..* 1 set by 0..* PassiveEntity 1 updates makes requests to 1 Count Average 1

schedules

Resource

Buffer

N.B.: ActiveEntity is abstract since the developer provides a concrete realization (through subclassing). Statistic also abstract, although two instances are provided.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 21 / 57

Example 2: Simulations Program

Abstract classes

An abstract class is a class that cannot be directly instantiated. Instead, one instantiates an instance of a subclass. One can identify an abstract class by writing its name in italics or by using the label {abstract}. Typically, an abstract class has one or more operations that are abstract. An abstract operation has no implementation; it is pure declaration so that clients can bind to the abstract class.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

22 / 57

Example 2: Simulations Program

Class Diagram (cont.)

Version I can be rened to come closer to an implementation. We specify associations, attributes, methods. E.g.:
Scheduler invokes Report. Direction: One way, from Scheduler to Report. Meaning: The Scheduler has the possibility of receiving statistics from Report-Objects, at the end of a simulation. Implementation: The Collection Attribute reports in the Scheduler, and the operation report() in Report. Scheduler schedules ActiveEntity. Direction: Two way: each Scheduler must be able to activate and ActiveEntity, and each ActiveEntity requires the Scheduler, in order to be entered in the event list. Meaning: The Scheduler controls the sequence in which ActiveEntities are executed, guaranteeing that execution occurs in the correct order. Implementation: ...
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 23 / 57

Example 2: Simulations Program

Rened class diagram

Scheduler - reports: Collection - evList: TimeOrderedList + now() : Real + wait(a : ActiveEntity) + run(runTime:Real) 1 schedules 1..* ActiveEntity {abstract} # evTime : Real # nextEvent : Integer # s : Scheduler # input : ExternalDataset +trace(m : Text) + reschedule() + act() + getTime() : Real 1..* driven by 1 ExternalDataset + giveValue() : Real Resource - avail : Boolean + acquire(a:ActiveEntity) + release() Buffer 1 updates makes requests to 1 1 1..* 0..* set by Count - total : Integer + update(r:Real) + report() + reset() Average - sum : Real + update(r:Real) + report() + reset() 1 1 1 invokes asks time from 0..* 1..* Report - stats: Collection + report() 1 1..* asks for summary from Statistic {abstract} # observations : Integer # clock : Scheduler # startTime : Real + reset() + update(r:Real) + report()

PassiveEntity # blocked : FIFOList # myStat : Statistic # input : ExternalDataset

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

24 / 57

Example 2: Simulations Program

One class in detail: ActiveEntity

Abstract class: no operation for act(). Can only be used after generalization. Attributes are protected. Can be used in subclasses. State/behavior:
act() in event list do / activeDetail [not nextEvent=Finished]s.wait(self) [nextEvent=Finished] active

One begins in the state in event list, i.e. one waits in evList of the Schedulers. A transition occurs when the object receives an act()-message. Upon leaving the state active, the object either terminates or sends itself to the Scheduler in the form of a wait-message. ActiveEntity has a nested state machine named activeDetail, which species specialized details from active. In each specialization of ActiveEntity, the Developer must later dene activeDetail.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 25 / 57

Example 2: Simulations Program

Another class: Average

Specializes the abstract class Statistic. 3 Methods. Meaning can be xed with a state-chart.
report() / printSummary() / sum := 0 /observations := 0

entry / startTime := now() update(val : Real) / sum := sum + val/observations++

reset() / sum := 0 / observations := 0

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

26 / 57

Example 3: Elevator Control

Outline

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

27 / 57

Example 3: Elevator Control

Example 3: Elevator Control: problem statement

The elevator has one button for each oor:

Illuminate when pressed. Cause the elevator to visit the corresponding oor. Illumination is canceled when the elevator visits the corresponding oor.

Each oor, except the rst oor and top oor, has two buttons to request the elevator to go up or down, respectively:
Illuminate when pressed. Cause the elevator to visit the corresponding oor. Illumination is canceled when the elevator visits the oor and then moves in the desired direction.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

28 / 57

Example 3: Elevator Control

Use Case: fetch elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

29 / 57

Example 3: Elevator Control

Use Case: ride elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

30 / 57

Example 3: Elevator Control

Initial analysis object model

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

31 / 57

Example 3: Elevator Control

Sequence diagram: fetch and ride elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

32 / 57

Example 3: Elevator Control

Iteration: Missed Requirements

The project manager decides that the analysis results should also be discussed with the hardware engineer. Engine cannot be told to move to a given oor. Messages understood by the engine:
Start moving in a given direction. Stop moving.

Sensors are used to determine position of elevator:

Sensors send signal when oor is reached.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

33 / 57

Example 3: Elevator Control

Use Case: request elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

34 / 57

Example 3: Elevator Control

Use Case: reach oor

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

35 / 57

Example 3: Elevator Control

Sequence diagram: request elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

36 / 57

Example 3: Elevator Control

Sequence diagram: reach oor

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

37 / 57

Example 3: Elevator Control

State diagram: controller

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

38 / 57

Example 3: Elevator Control

A more realistic elevator

Additional business requirements. Requests shall be accepted at any time:

Also when elevator is moving.

System keeps track of all pending requests:

Processing order not specied.

Elevator serves requests on its way immediately:

Detailed by scenario.

We ignore illumination of buttons and operation of doors in the following.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

39 / 57

Example 3: Elevator Control

Scenario: processing requests on the way

1 2 3

Alice enters elevator on rst oor and pushes button for fth oor. System initiates elevator to move to fth. When elevator is on second oor, Bob pushes hall button on third oor. System stops elevator on third oor. Bob enters elevator and pushes button for sixth oor. System initiates elevator to move to fth oor. System stops elevator on fth oor. Alice gets off. System initiates elevator to move to sixth oor. System stops elevator on sixth oor. Bob gets off.
Case Studies Ingegneria del SW, 13.04.11 40 / 57

4 5 6 7 8 9 10 11

Luca Vigan (Universit di Verona)

Example 3: Elevator Control

Use Case: request elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

41 / 57

Example 3: Elevator Control

Use Case: reach oor

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

42 / 57

Example 3: Elevator Control

Sequence diagram: request elevator

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

43 / 57

Example 3: Elevator Control

Sequence diagram: reach oor

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

44 / 57

Example 3: Elevator Control

Class diagram

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

45 / 57

Example 3: Elevator Control

State diagram: controller

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

46 / 57

Analysis model validation

Outline

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

47 / 57

Analysis model validation

Validation and verication of models

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

48 / 57

Analysis model validation

Validation and verication of models (cont.)

Verication is a comparison of two models.

Determining that a model accurately represents another model. One can prove a renement relation (rarely done in practice, unfortunately).

Validation is a comparison of a model to reality.

Reality can be an articial system, (e.g. legacy system). Validation is a critical step in the development process.

Requirements should be validated with the client and the user.

Technique: Formal and informal requirements reviews.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

49 / 57

Analysis model validation

Checklist for requirements review

Is the model correct?

Everything in the model represents an aspect of reality.

Is the model complete?

Every scenario, including exceptions, is described.

Is the model consistent?

The model does not have components that contradict themselves (for example, deliver contradicting results).

Is the model unambiguous?

The model describes one system (one reality), not many.

Is the model realistic?

The model can be implemented without problems.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

50 / 57

Analysis model validation

Checklist for requirements review (cont.)

One problem with modeling: we describe a system model with many different views:
Use Cases, class, sequence, and state diagrams.

We need to check the equivalence of these views. Syntactical check of the models.
Consistent naming of classes, attributes, methods. No dangling associations (pointing to nowhere). No double-dened classes. No missing classes (mentioned but not dened). No classes with the same name but different meanings.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

51 / 57

Analysis model validation

Analysis activities summary

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

52 / 57

Conclusions

Outline

Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

53 / 57

Conclusions

Summary

Models yield different views of a system at different levels of abstraction. Models compliment textual documentation. Useful for planning, development, etc. ... Iterating brain-storming/diagrams/discussions is helpful in building models and improving general problem understanding. Building models is a skill that must be acquired through practice! We have not shown any false starts here.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

54 / 57

Conclusions

Example solution of the last homework

The following coarse statecharts diagram reects the fact that according to the product sketch of the CSS-system, we need three data-bases (rooms, event-offers, class-schedules), which must be edited by the scheduling manager. This results in a separation of the central CSS-state in three viewing modes (plus a forth initial one containing general information on CSS), which are represented as sub-states offering editing functionality on these data-bases. Global state-transitions are init (implicit), EXIT, LOAD_EVENT_OFFERS and LOAD_ROOMS. Additionally, there is a transition on the event CREATE_SCHEDULES triggered by the scheduling manager. All these events may occur in an arbitrary sub-state of CSS; this fact is concisely represented in the statecharts diagram. The diagram also introduces intermediate states LOAD_EVENT_OFFERS, CREATE_SCHEDULES and LOAD_ROOMS, which are not strictly necessary but will allow easier renements of the dialogues connected with these states with respect to possible failure (cannot nd le, present a choose-box with possible le names, etc.). The overall diagram assumes a global variable INIT, which protocols if the operation CREATE_SCHEDULES has successfully taken place. In this case, the (guarded) event CS_TAB may take place, and thereby enable the view of the produced class-schedule variants. INIT is set by the action SCHEDULES_INIT and reset by the action SCHEDULES_NOT_INIT.
Luca Vigan (Universit di Verona) Case Studies Ingegneria del SW, 13.04.11 55 / 57

Conclusions

Example solution of the last homework (cont.)

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

56 / 57

Conclusions

Homework
We continue with the semi-formal analysis of the requirements of our Class Scheduling System software-project and begin the design phase.
1

Rene the coarse state-charts event-model. The new model should in particular contain more rened versions of ROOM _VIEW and CLASS _SCHEDULE _VIEW , and it should yield a coarse model of the GUI (the graphical user-interface). Give a (brief) evaluation of the different semi-formal analysis techniques that we have seen and employed in the previous exercises. Provide, to this end, a suitable classication of the techniques.

Luca Vigan (Universit di Verona)

Case Studies

Ingegneria del SW, 13.04.11

57 / 57