Three Case Studies in (Semi-Formal) System Modeling: Luca Viganò

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
1 / 57
Table of contents
Example 1: Class Administration Program Example 2: Simulations Program Example 3: Elevator Control Analysis model validation Conclusions
Case Studies
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!
Analysis model
Case Studies
5 / 57
Example 1: Class Administration Program
Outline
Case Studies
6 / 57

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, ...
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.
Case Studies
8 / 57
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.
Case Studies
9 / 57
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.
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.

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.
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
Case Studies
13 / 57
Example 2: Simulations Program
Outline
Case Studies
14 / 57
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.
Case Studies
15 / 57
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.
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.
Case Studies
17 / 57
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.
Case Studies
18 / 57
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.

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. . . .
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.
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.
Case Studies
22 / 57
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: ...
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
Case Studies
24 / 57
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.
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
Case Studies
26 / 57
Example 3: Elevator Control
Outline
Case Studies
27 / 57
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.
Case Studies
28 / 57
Use Case: fetch elevator
Case Studies
29 / 57
Use Case: ride elevator
Case Studies
30 / 57
Initial analysis object model
Case Studies
31 / 57
Sequence diagram: fetch and ride elevator
Case Studies
32 / 57
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.
Case Studies
33 / 57
Use Case: request elevator
Case Studies
34 / 57
Use Case: reach oor
Case Studies
35 / 57
Sequence diagram: request elevator
Case Studies
36 / 57
Sequence diagram: reach oor
Case Studies
37 / 57
State diagram: controller
Case Studies
38 / 57
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.
Case Studies
39 / 57
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
Use Case: request elevator
Case Studies
41 / 57
Use Case: reach oor
Case Studies
42 / 57
Sequence diagram: request elevator
Case Studies
43 / 57
Sequence diagram: reach oor
Case Studies
44 / 57
Class diagram
Case Studies
45 / 57
State diagram: controller
Case Studies
46 / 57
Analysis model validation
Outline
Case Studies
47 / 57
Validation and verication of models
Case Studies
48 / 57
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.
Case Studies
49 / 57
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.
Case Studies
50 / 57
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.
Case Studies
51 / 57
Analysis activities summary
Case Studies
52 / 57
Conclusions
Outline
Case Studies
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.
Case Studies
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.
Conclusions
Example solution of the last homework (cont.)
Case Studies
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.
Case Studies
57 / 57

Three Case Studies in (Semi-Formal) System Modeling: Luca Viganò

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Three Case Studies in (Semi-Formal) System Modeling: Luca Viganò

Caricato da

Copyright:

Formati disponibili

Three Case Studies in (Semi-Formal) System Modeling

Ingegneria del SW, 13.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Objectives of system modeling

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 1: Class Administration Program

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 1: Class Administration Program

Example 1: Class Administration Program

Example 1: Class Administration Program

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

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 1: Class Administration Program

Desired: an improvement of the status quo!

Lets consider part of the requirements:

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 1: Class Administration Program

A possible Use Case model

CS3 Course Organizer

CS4 Course Organizer

Produce Course Handbook

Register for modules

CS4 Director of Studies

Example 1: Class Administration Program

Brainstorming with CRC Cards

Basis for class diagram and scenario simulation.

Example 1: Class Administration Program

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

Example 1: Class Administration Program

Update module entry

Print handbook lecturer UTO

Generate HTML version

CS4 course organiser

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 2: Simulations Program

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 2: Simulations Program

Example 2: Simulations Program

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 2: Simulations Program

A detailed description (potential classes in red)

Example 2: Simulations Program

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 2: Simulations Program

Luca Vigan (Universit di Verona)

Ingegneria del SW, 13.04.11

Example 2: Simulations Program

Use Cases model

Example 2: Simulations Program

Use Cases model (cont.)

Example 2: Simulations Program

Class diagram: Version I (rough)