Teaching modeling of reactive systems Øystein Haugen INF 2120

advertisement
INF 2120
Teaching modeling of reactive systems
Øystein Haugen
oysteinh@ifi.uio.no
12-Oct-06
INF2120 Prosjekt i modellering
1
Purpose of INF2120 – Project in Modeling
ƒ
The students should learn how to apply what they should
have learned already.
– as opposed to learning a lot of new stuff
ƒ
INF 2120
The task of the course should be so big that it would be
impossible to perform it alone.
– but the difference in capacity in our field is so very big ....
ƒ
The students shall experience project work.
– but this is not the only course with project work
12-Oct-06
INF2120 Prosjekt i modellering
2
Learning objectives
ƒ
to learn how concurrent, reactive systems are built,
– and this is the undergraduate course to learn it!
ƒ
to learn how to combine technical, reactive systems with
administrative database systems,
ƒ
INF 2120
– since such hybrid systems are becoming commonplace
to connect to (semi-)professional software that provides
very cool and useful functionality,
– we seldom start from scratch, but rather use building blocks
ƒ
to experience a variety of interconnected tools.
– to be able to handle a diversity of tools will be important
12-Oct-06
INF2120 Prosjekt i modellering
3
The format of the course
ƒ
ƒ
ƒ
ƒ
ƒ
10 credits (out of a normal of 30 a semester, 60 a year)
Early January to early June
~40 students (but noone has been rejected due to space)
Lectures: 2 hours/week
Teaching Groups (with assistant teacher):
INF 2120
– 2 hours/week in room with blackboard, but no computers
– 2 hours/week (half semester) in lab-room with computers
ƒ Project Groups
– 4-6 persons within one teaching group
ƒ Resources during the course
– All the lectures and supplementary material are available on the web
– we build up a FAQ for difficulties experienced throughout the course.
– The students are encouraged to cooperate not only within the group, but
also between the groups.
– we welcome solutions that the students can find by using the Internet.
12-Oct-06
INF2120 Prosjekt i modellering
4
The project
ƒ 3 Drops (specification, design, execute/test)
– specification: sequence diagrams
– design: state machines
– execute / test: java / UML testing profile
INF 2120
ƒ Peer reviews on each drop
– as well as grading by the teachers
ƒ New project topic every year
– which prevents cheating
ƒ 2005: to find nearest bus stop to the user based on
positioning mobile, find first bus for a given destination
ƒ 2006: private surveillance system ”ICU” where positioning
is used to place your buddies on a GoogleEarth map
12-Oct-06
INF2120 Prosjekt i modellering
5
Engineering Method
ƒ Recommended literature
– Skagestein: System development (in Norwegian)
– Haugen, Møller-Pedersen, Weigert: two chapters on design for
reactive systems in
INF 2120
ƒ UML for Real (Lavogno, Martin, Selic eds.)
ƒ Embedded Systems Handbook (Zurawski ed.)
ƒ Small demo system
– GooglePos: having a very basic service – but executable
– Small database application: showing database interface
ƒ Apply project organization already learned
– there is a question whether they have really learned this!
12-Oct-06
INF2120 Prosjekt i modellering
6
Tools
third party sw:
simple interfaces
PATS
hybrid
systems
Oracle
UML2
SeDi
plugin
executable
modeling
UML 2 runtime
system
open source –
our own
UML compiler
3.0
JavaFrame
Windows+
Linux
12-Oct-06
INF2120 Prosjekt i modellering
7
INF 2120
Commercial
big, imperfect
The Model – what are we making?
sm ATM
Idle
User
/authN=0
*
*
ATM
1
*
ATM
Bank
CardId(cid)
CashRepository
/authN=0
:EnterPIN
:Service
1
ok
status
Withdrawal
nok
1
[authN<3]/
authN++;
send(msg(”Try again”))
«include»
Withdrawal
*
:Withdrawal
*
ok
[authN==3]/
authN=0
send(msg(
”illegal entry”));
User
«include»
:Status
1
Card
Authentication
Bank
1
cancelled
Account
Currency
myAccounts
CardOut
cardTaken
A Use Case Model
A Class Model
A State Machine Model
INF 2120
entry: send(card)
s d A u th e n tica te
:U ser
:A T M
BankContext
:B ank
Id le
C ardid(cid)
re f
:User
[1..10.000]
:ATM[1..100]
:Bank
E nte rP IN
lo o p (0 ,2 )
P IN N O K
m sg("T ry again!")
re f
A Composite Structure Model
12-Oct-06
E n te rP IN
An Interaction Model
INF2120 Prosjekt i modellering
8
Consistency
sm ATM
Idle
User
/authN=0
*
*
ATM
1
*
ATM
Bank
CardId(cid)
CashRepository
/authN=0
:EnterPIN
:Service
1
ok
status
Withdrawal
nok
1
[authN<3]/
authN++;
send(msg(”Try again”))
Withdrawal
*
:Withdrawal
*
ok
[authN==3]/
authN=0
send(msg(
”illegal entry”));
User
1
Authentication
«include»
:Status
Card
«include»
Bank
1
cancelled
Account
Currency
myAccounts
CardOut
INF 2120
entry: send(card)
cardTaken
s d A u th e n tica te
:U ser
:A T M
BankContext
:B ank
Id le
C ardid(cid)
re f
:User
[1..10.000]
:ATM[1..100]
:Bank
E nte rP IN
lo o p (0 ,2 )
P IN N O K
m sg("T ry again!")
re f
12-Oct-06
INF2120 Prosjekt i modellering
E n te rP IN
9
Statements from the students
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
12-Oct-06
INF2120 Prosjekt i modellering
10
INF 2120
ƒ
State machines were just ingenious! Great for overview and
amazingly simple.
Nice to work with (semi-) real technology such as the PATS
laboratory interface.
Eclipse is great. Nice to work on a cross-system platform.
Sequence diagrams were difficult at first, but after a while they felt
natural and we understood how to use them and benefit from them.
The use of an Oracle database had little significance. The database
was very simple and could as well have been replaced by a simple
file.
Most students were reasonably positive towards Rational Software
Modeler (RSM), but almost everyone had some negative
experiences to balance the positive remarks.
SeDi – the sequence diagram editor plugin – was considered all
right, but almost all of the students thought that better integration
with RSM (and the UML2 repository) would be very desirable.
More statements from students
ƒ
ƒ
The UML to JavaFrame transformer was considered “surprisingly
good”. Code generation became a favorite for many students,
The project work caused the most traumas.
–
–
ƒ
ƒ
The students were reasonably satisfied with randomly composed
groups. They had no desire for stratification of the students prior to
group formation.
The students would have liked more hands-on lab time with
supervision and less blackboard-oriented group teaching.
12-Oct-06
INF2120 Prosjekt i modellering
11
INF 2120
–
Many students experienced that the groups were unevenly composed,
which in fact was intentional.
This caused conflicts and uneven distribution of the workload. Especially
the hardworking students found this frustrating.
Some students also reported problems of the project due to difficulties
with configuration management.
... and even more statements
ƒ
ƒ
Everybody liked hard deadlines.
Most students had benefit from peer-criticism, both being
criticized and doing critics.
– The evaluations from lecturer and group teachers were also
considered very valuable.
Most students also accepted the informal A-F grading on
drops.
– A few students found the grading definitely positive, while one
person was clearly against such informal grading.
ƒ
In the final evaluation, the students thought that the
course had been a good one. 68% said that the course
should receive a B and 14% an A.
– They were more satisfied with the teachers and less satisfied
with the tools.
12-Oct-06
INF2120 Prosjekt i modellering
12
INF 2120
ƒ
Experiences (as seen from the teachers)
ƒ
ƒ
ƒ
ƒ
ƒ
12-Oct-06
INF2120 Prosjekt i modellering
13
INF 2120
ƒ
Going from informal UML to executable UML is non-trivial
Decomposition of lifelines in sequence diagrams can be learned and
brought to productive use.
Manually ensuring consistency between sequence diagrams and
composite structures is difficult. Tool support is much wanted.
To model with state machines and asynchronous signaling requires
some maturing, but once grasped, most students become very
enthusiastic.
In the end the students see the essence of consistency between the
sequence diagrams and the set of state machines (as well as the
intermediate composites).
That the system in the end actually runs with “cool” things like
mobile phones is an appreciated added value.
Download