TMPA-2015: Software Engineering Education: The Messir Approach

TMPA-2015-Keynote - Part:
1 / 157
Prove it !
This is not an
Antonov !
Nicolas Guelﬁ- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU

2 / 157
My Name is
Guelﬁ !
Nicolas Guelﬁ
Software Engineering Education
The MessirApproach
TMPA-2015
(Invited Talk)

Presentation Parts
3 / 157
1: Warning ! (slide 4)
2: Software Engineering Education (slide 10)
3: An Experimental Remedy (slide 52)
4: Illustration: The iCrash Messep Variant (slide 64)
5: Conclusion (slide 139)

TMPA-2015-Keynote - Part: Warning !
Part I
Warning !
4 / 157

5 / 157
!! Warning !! on the Presentation’s Content
Pragmatism & Objectivism
• Useful, scalable but not universal
• Rigorous but mostly empirical
• Shared by some but not all
Based on Experience ...including:
• 25 years in education and knowledge
transfer (bachelor, master, doctorate,
post-doctorate)
• 8 years as Software Engineering expert
at Court of Justice for conformance
questions
• 400 trainees in the SE industry
managed at bachelor and master levels

5 / 157
• 25 years in theoretical and applied
research
◦ IEE
Efficient Verification of Occupants
Classification System

5 / 157
research
◦ Dassault Aviation - (Rafale)
Fault Tolerant Embedded System for
Outside Temperature Monitoring

5 / 157
research
◦ Theoretical Computer Science
Algebraic theories applied to the
mathematical modeling of concurrent
processes with advanced data structures

5 / 157
research
◦ Software Engineering & Dependable
Systems
European & National Research Projects,
Excellence networks
SERENE
(http://www.ercim.eu/activity/workgroup)

TMPA-2015-Keynote - Part: Software Engineering Education
Part II
6 / 157

Introductory Quotes
7 / 157
Software Engineering Deﬁnition
The application of a systematic, disciplined,
quantiﬁable approach to the development,
operation, and maintenance of software.
(IEEE in [IEEE(1990)])

Introductory Quotes
8 / 157
Software Engineering Deﬁnition
Software engineering is the part of computer
science which is too difﬁcult for the computer
scientist.
(Friedrich Bauer [Bauer(1971), 71])

Introductory Quotes
9 / 157
Today, the majority of Engineers understand very little of the “science of programming”. On
the other side, the scientists who study programming understand very little about what it
means to be an Engineer ...the two ﬁelds have much to learn from each other and that the
marriage of software and Engineering should be consummated.
(David Lorge Parnas in [Parnas(1997)])
Prove it !This is not an
Antonov !

Introductory Quotes
10 / 157
Is it possible to have software engineers in the numbers in
which we need them, without formal software engineering
education ?
(A.J. Perlis in [Naur and Randell(1969), 68])

Do We Need SE Education ?
11 / 157
Do We (Really) Need
Software Engineering
Education ?

12 / 157
“Computing” Jobs: Proportions and Distributions ?
(Science, Technology, Engineering and Mathematics)
(Science, Technology, Engineering and Mathematics)

13 / 157
“Computing” Jobs in 2022: Offers vs Grads ?

What About SE in Industry ?
14 / 157
What about
SE in Industry ?
(conjectures only !!)

15 / 157
Capability Maturity Model
CMM [Paulk(1993)] and CMMI-DEV [SEI(2010)]
• can be used as an observation tool
• provides a subjective and relative evaluation of the
Software Engineering practice in industry.

16 / 157
CCMI-DEV - Capability Maturity Model Integration for
Development
State of practice in industry [Bollinger and McGowan(2009)]
Level 1 - Initial
Level 2 - Repeatable
Level 3 - Deﬁned
Level 4 - Managed
Level 5 - Optimizing
0 10 20 30 40 50 60 70 80 90 100
Level 1
Level 2
Level 3
Level 4
Level 5
51.2
24.8
17.4
5.4
1.2
Percentage (%)

17 / 157
Agile Software Development - [Beck and al.(2001)]
Represents a “Software Engineering success story”
for the mass
• realistic w.r.t. SE maturity (theories, methods and tools)
• realistic w.r.t. ICT project’s budgets
Mainly focused on project management and
development life cycle
• iterative and incremental design and development
Promotes directly some SE areas
1. Software Construction
2. Software Testing
3. Software Engineering Management
4. Software Engineering Process
5. Software Quality
6. Software Engineering Professional Practice

18 / 157
Agile in Industry - [Stavru(2014)]
[Rodríguez and al.(2012)]
[VersionOne(2012)]
0 20 40 60 80 100
VersionOne
Rodriguez and al.
20
44.8
80
55.2
Rate of Agile in
Method Prone Projects (%)
No Agile
Agile

19 / 157
Agile Methodologies Used - [VersionOne(2015)]
0 20 40 60 80 100
Scrum
Scrum & XP hybrid
Custom Hybrid
Scrumban
Kanban
Iterative Dev.
Agile Modeling
Feature Driven Dev.
AgileUP
XP
56
10
8
6
6
4
1
1
0.5
0.5
Percentage (%)

20 / 157
Agile Project Management Tools Used
[VersionOne(2015)]

21 / 157
Model Driven Engineering Practice in industry
[Hutchinson et al.(2011)Hutchinson, Whittle, Rounceﬁeld, and Kristoffersen]
250 questionnaire answers from MDE practitioners
22 in-depth interviews of MDE professionals from 17
different companies
on-site observational studies with companies
practicing MDE

0 10 20 30 40 50 60 70 80 90 100
make use of UML
use a DSL of their own design
use a DSL provided by a tool
use BPMN
use SysML and MATLAB/Simulink
85
40
25
25
10
Percentage (%)
22 / 157

23 / 157
0 20 40 60 80 100
Class Diagram
Activity Diagram
Use Case Diagram
Sequence Diagram
State Machine Diagram
DSL Diagram
Component Diagram
Flow Diagram
Entity Relationship Diagram
Deployment Diagram
Object Diagram
Composite Structure Diagram
87
56
38
33
23
8
8
5
3
3
2
2
Percentage (%)
35 diagram types cited
inclusion min threshold of 2
diagrams below the threshold:
Abstract Syntax Graphs, Arrow
Diagrams, UsiXML Stylistics and
ICONIX Robustness Diagrams,...

0 20 40 60 80 100
Use of models for team communication
Use of models for understanding a problem at an abstract level
Code generation
Use of models to capture and document designs
Use of model-to-model transformations
Use of domain-speciﬁc languages (DSLs)
Model simulation - Executable models
Use of models in testing
Percentage (%)
Productivity Impact
Maintainability Impact
24 / 157

Status of SE Education ?
25 / 157
What is the status of
Education ?

Status of SE Education ?
26 / 157
Software Engineering Education Main Dates
1968 · · · · · ·• NATO conference [Naur and Randell(1969)]
1976 · · · · · ·• Workshop on Software Engineering Education
1978 · · · · · ·• Subcommittee on Model Curricula in SE (SMCSE)
1989 · · · · · ·• SEI Graduate Curriculum report
1990 · · · · · ·• N. Guelfi first SE lecture !
1993 · · · · · ·• IEEE CS/ACM Joint Steering Committee
1998 · · · · · ·• SE Coordinating Committee (SWECC)
1999 · · · · · ·• SE Code of Ethics & Professional Practice
2004 · · · · · ·• SE2004 Undergraduate Curriculum Report
2005 · · · · · ·• SWEBOK Certified [ISO/IEC(2005)]
2009 · · · · · ·• Graduate Software Engineering 2009 (GSwE2009 published)
2013 · · · · · ·• CS2013 Undergraduate Curriculum - submitted [Sahami and Roach(2014)]
2014 · · · · · ·• SE2014 Undergraduate Curriculum - submitted [ACM/IEEE(2015)]
2014 · · · · · ·• SWEBOK submitted for recognition [ISO/IEC(2014)]

SE Body of Knowledge ?
27 / 157
What is the
Body of Knowledge ?

28 / 157
SWEBOK IEEE/ISO Standard
[ISO/IEC(2005)],[ISO/IEC(2014)]
SE knowledge decomposed in:
• 15 Knowledge Areas
• 99 Topics
• 394 Sub-topics

29 / 157
Number Knowledge Area Names
1 Software Requirements
2 Software Design
3 Software Construction
4 Software Testing
5 Software Maintenance
6 Software Conﬁguration Management
7 Software Engineering Management
8 Software Engineering Process
9 Software Engineering Models and Methods
10 Software Quality
11 Software Engineering Professional Practice
12 Software Engineering Economics
13 Computing Foundations
14 Mathematical Foundations
15 Engineering Foundations
Figure: SWEBOK Knowledge Areas

30 / 157
Number Topic Names
1 Modeling
2 Types of Models
3 Analysis of Models
4 Software Engineering Methods
Figure: SWEBOK topics for (9) Software
Engineering Models and Methods
Number SubTopic Names
1 Modeling Principles
2 Properties and Expression of Models
3 Syntax, Semantics, and Pragmatics
4 Preconditions, Postconditions, and Invariants
Figure: SWEBOK topics for (9.1) Modeling
Number SubTopic Names
1 Heuristic Methods
2 Formal Methods
3 Prototyping Methods
4 Agile Methods
Figure: SWEBOK topics for (9.4) Software
Engineering Methods

SWEBOK Coverage ?
31 / 157
What is the SWEBOK
Intentional CoverageNG
Over the World ?

SWEBOK Coverage ?
32 / 157
Group Countries According to:
Culture
Economy
Location

SWEBOK Coverage ?
33 / 157
MessirEducation Regions
10 Regions - 48 Institutions
N° Region Name Qty
1 North America 7
2 Western Europe 11
3 Japan 3
4 Oceania and South Africa 4
5 Eastern Europe 4
6 Latin America 3
7 North Africa and the Middle East 5
8 Main Africa 2
9 South and Southeast Asia 7
10 Centrally Planned Asia 2
Figure: Messir Education Regions
3 samples
• Schangai Ranking - 48
• ABET/SE - 27
• Network - 14

SWEBOK Coverage ?
34 / 157
International Standard Classification
of Education [UNE(2012)]
Level
• 6: Bachelor
• 7: Master
• 8: Doctorate
Category
• 4: Academic
• 5: Professional
• 6: Orientation unspecified
SubCategory
• 5: First degree
• 6: Long first degree
• 7: Second or further degree
Exitfromeducationsystem/labourmarketentry
Tertiaryeducation
Post-
secondary
non-
tertiary
education
Secondary
education
Primary
education
Earlychildhood
education
First-timeschoolentry
01
02
1
2
3
4
8
667
766
767
5
666
665
768
Figure: International Standard Classification
of Education Pathways DiagramNicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU

SWEBOK Coverage ?
35 / 157
Global CoverageNG ALL Institutions
Global:
43,4%
KA Name Mean Min Max StdDev
1 Software Requirements 64 33 80 21
2 Software Design 46 17 66 21
3 Software Construction 51 36 67 16
4 Software Testing 28 5 42 16
5 Software Maintenance 11 0 28 14
6 Software Conﬁguration Management 6 0 17 8
7 Software Engineering Management 68 58 75 7
8 Software Engineering Process 35 33 40 3
9 Software Engineering Models and Methods 66 31 100 29
10 Software Quality 29 8 50 20
11 Software Engineering Professional Practice 71 58 84 13
12 Software Engineering Economics 24 8 60 25
13 Computing Foundations 58 11 79 32
14 Mathematical Foundations 56 19 75 26
15 Engineering Foundations 38 18 65 20
Figure: Global KA Coverage (%)

SWEBOK Coverage ?
36 / 157
Intentional CoverageNG by Institutions
Global:
55%
Michigan State University - United States (US)
Bachelor in Computer science
Number Knowledge Area Coverage (%)
9 Software Engineering Models and Methods 100
11 Software Engineering Professional Practice 79
13 Computing Foundations 79
7 Software Engineering Management 71
1 Software Requirements 70
14 Mathematical Foundations 69
3 Software Construction 67
15 Engineering Foundations 65
12 Software Engineering Economics 60
2 Software Design 54
4 Software Testing 42
10 Software Quality 42
8 Software Engineering Process 33
5 Software Maintenance 0
6 Software Conﬁguration Management 0
Figure: SWEBOK Coverage for Institution: 2 (55%)

SWEBOK Coverage ?
37 / 157
Intentional CoverageNG by Institutions
Global:
35%
Université Libre de Bruxelles - Belgium (BE)
Bachelor in Computer science
Figure: SWEBOK Coverage for Institution: 5 (35%)

Lessons Learned ?
38 / 157
What are the
Lessons Learned ?

Lessons Learned ?
39 / 157
Software Engineering - Lessons Learned
1 Extremism Syndrome
• Professional Oriented Curriculums (largely) exclude
science and theory
• Academic Oriented Curriculums (largely) exclude
technology and industry
Prove it !
This is not an
Antonov !
This is not an
Antonov !
Prove it !

Lessons Learned ?
40 / 157
2 Shared 68 Crisis Syndrome
• theories/methods/tools taught (mainly) inadequate
w.r.t. industry needs
• change rates too fast for SE education (& research)
• (very) poor availability/awareness/use of standards
in SE Education
◦ SWEBOK weakly covered
◦ GSwE2009/SE2014 weakly implemented
• SE Education Maturity Level 1 - Initial
◦ Process is ad hoc, even chaotic
◦ Success depends on individual effort and heroics

Lessons Learned ?
41 / 157
“Unfortunately, it’s just me.
It is my passion.”
(Dr. Kristen Walcott-Justice
University of Colorado)
3 Ugly Duckling Syndrome
• SE is explicitly taught mostly:
◦ as a block in “Software Engineering”
courses and rarely in a full curriculum
◦ by “Software Engineering Heroes”
◦ by “Nominated Volunteers”

Lessons Learned ?
42 / 157
4 Ivory Towers City Syndrome
• The majority of curriculums is made of
courses which:
◦ are disciplinary (verticality)
◦ focused on teacher(s) expertise topics
◦ poorly consistent with each others
◦ (very) poorly cooperating
• Cooperation with industry is (very) rare
• Cooperation with SE tools industry is
(very) poor

Lessons Learned ?
43 / 157
5 “HyperTheoryTrophy” Syndrome
• Most academic teachers have:
◦ a scientiﬁc education oriented towards
(fundamental) research
◦ (very) poor industrial experience as engineer
• Hyper presence of theoretical computer
science and formal methods
This is not an
Antonov !
Prove it !

Lessons Learned ?
44 / 157
6 Conservatism Syndrome
• courses contain “old fashioned” content even for
technology oriented courses

Lessons Learned ?
45 / 157
7 Forgotten Pragmatics Syndrome
• SE Problems encountered by the industry
• SE Problems addressed in education
• SE Problems addressed in research

Lessons Learned ?
46 / 157
8 Inﬁnity Fantasm Syndrom
• Viewpoints on the costs of the solutions:
◦ Industry
◦ Education
◦ Research
◦ Customer

So What ?
47 / 157
So ...
What Can We Do ?

TMPA-2015-Keynote - Part: An Experimental Remedy
Part III
An Experimental Remedy
48 / 157

Proposal Main Idea ?
49 / 157
A Product Line of Software Engineering Project Courses

50 / 157
Messep learning tool
Software Engineering Project Courses Product Line
Variation points include:
• SWEBOK
◦ Knowledge areas (KA)
◦ Topics (TP)
◦ Sub-topics (STP)
• Application Domains ([Heiman(2010)])
◦ Market (MK)
◦ Categories (CT)
◦ Sub-Categories (SCT)
• Technologies
not a one for all approach
Flexibility: an as complete as consistent as wished
approach for the targeted SE learning objectives

51 / 157
Messep : Domain Artefacts
SE Project Course Deﬁnition
• Commonalities
◦ none !
• Variabilities
◦ process, schedule
◦ activities, workload
◦ evaluation
SWEBOK
• Commonalities
◦ Messir(KA1-REQ, KA4-TEST,...)
◦ Excalibur (KA3.5-CONS.TOOLS)
• Variabilities
◦ KA1-REQ topics & subtopics
◦ KA9-MOD
◦ potentially all KAs
Application Domain
• Commonalities
◦ Applications
/Collaborative Applications
/Team Collaborative Applications
(iCrash Crisis Management Systems)
• Variabilities
◦ none yet !
Technologies
• Commonalities
◦ Eclipse , Java , SQL , JavaFx ,...
• Variabilities
◦ Eclipse plug-ins, Application Components
◦ HTML5, iOS, Android, ...

52 / 157
Messep : Derivation Processes
Forward
• Bind the variabilities
• Define Deltas
◦ add/modify variation point, variant,
constraint
• Derive SE Project Variant
◦ SE Project Definition documents
◦ Realization artefacts (i.e. models, code, SE
tools,...)
Back & Forth (if necessary)
• Select a SE Project Variant from the
Product Line
• Define Deltas (Optional)
◦ add/modify variation points, variants,
constraints
• Derive Refined SE Project Variant
(Optional)
◦ Realization artefacts
(i.e. models, code, SE tools,...)

TMPA-2015-Keynote - Part: Illustration: The iCrash MessepVariant
Part IV
Illustration: The
iCrash MessepVariant
53 / 157

iCrash SEP Variant - Process
54 / 157
iCrash 4ME Variant - Process
Back & Forth
• Select a SE Project Variant from the Product Line
◦ iCrash v1.0
• Deﬁne Deltas
◦ add/modify variation points, variants, constraints
• Derive Reﬁned SE Project Variant
◦ Realization artefacts (i.e. models, code, SE tools,...)

iCrash Variant Overview
55 / 157
Messep SE Project iCrash v1.0 Card
Features
Details
Project Name iCrash v 1.0
ICSED Level BA 655 (Bachelor/Professional/First degree)
Schedule 10 hours * 14 weeks * 2 periods
Group Size 4 [2-4]
Phases Per.1 [Pha.1/6w + Pha.2/8w]
Per.2 [Pha.1/8w + Pha.2/7w]
Main SWEBOK KAs KA1/REQ + KA9/MOD + KA3/CONS
Main Market Applications/Collaborative Applications/Team Collaborative Applications
Main Technologies
VirtualBox

56 / 157
iCrash v1.0 Domain Artefacts
Main Inputs Details
Requirements Messir Standardized Requirements Artefacts
• Excalibur Requirements Speciﬁcation Project
• Excalibur Requirements Documentation Project
• Excalibur Requirements Simulation Project
Construction iCrash v1.0 Code
• Functionalities - Java
• GUI - JavaFx
• Data persistency - MySQL
• Distributed processing - Java RMI
• Versioning - SubVersioN

57 / 157
Effective CoverageNG by Variant
36
%
Figure: SWEBOK Coverage iCrash v1.0 (36%)

iCrash SEP Commonalities - Requirement Analysis
58 / 157
What is the MessirInternal Standard ?

The MessirRequirements
Engineering process (MevoP )
is iterative and incremental.
59 / 157
Requirements Analyst
[Correct&Complete]
[Incorrect or Incomplete]
Use Cases
Concepts
Environment
Operations
Tests
Iteration
Closure

60 / 157
Deﬁnition Speciﬁcation Simulation
Use Case
Environment
Concept
Operation
Test
Figure: MevoP Process - Model focus by Analysis Level

61 / 157
Categories of Messirlanguages by Analysis levels.
Level msrd msr pl
Definition +++ + -
Specification ++ +++ -
Simulation + + +++
Agile ( msrd)
• Messirdocumentation language
• template based natural language
Rigorous ( msr)
• Messirspecification language
• structured object-oriented and constraint
oriented specification language
Scientific ( pl)
• Messirsimulation language
• Prologmsr programming language

iCrash - Stakeholders
The iCrash system is intended to support the ABC company for the
management of crisis situations.
the iCrash stakeholders are:
1. Communication Company
2. Humans
3. Coordinators
4. Administrator
5. Creator
6. Activator
62 / 157
iCrash v1.0 Stakeholders

iCrash - Use Case Model
63 / 157
iCrash
Use Case Diagram View
Illustration

64 / 157
iCrash
Use Case Specification
Illustration
1 use case system summary suDeployAndRun() {
2 actor actAdministrator[primary,active]
3 actor actMsrCreator[secondary,active]
4 actor actCoordinator[secondary,active,multiple]
5 actor actActivator[secondary,proactive]
6 actor actComCompany[secondary,active]
7
8 reuse oeCreateSystemAndEnvironment[1..1]
9 reuse ugAdministrateTheSystem[1..*]
10 reuse suGlobalCrisisHandling[1..*]
11 reuse oeSetClock[1..*]
12 reuse oeSollicitateCrisisHandling[0..*]
13 reuse oeAlert[1..*]
14
15 step a: actMsrCreator executes
oeCreateSystemAndEnvironment
16 step b: actAdministrator executes
ugAdministrateTheSystem
17 step c: actComCompany executes oeAlert
18 step d: actActivator executes oeSetClock
19 step ê: actActivator executes
oeSollicitateCrisisHandling
20 step f: actCoordinator executes
suGlobalCrisisHandling
21
22 ordering constraint
23 "step (a) must be always the first step."
25 "step (f) can be executed by different
actCoordinator actors."
27 "if (e) then previously (d)."Nicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU

65 / 157
iCrash
Use Case Documentation
Illustration
The goal is to install the iCrash system on its infrastructure and to exploit its capacities related to the secure
administration and efficient handling of car crash situations depending on alerts received.
Use-Case Description
Name suDeployAndRun
Scope system
Level summary
Primary Actor
1 actAdministrator[active]
Secondary actor(s)
1 actMsrCreator[active]
2 actCoordinator[active, multiple]
3 actActivator[proactive]
4 actComCompany[active]
Goal(s) description
The goal is to install the iCrash system on its infrastructure and to exploit its capacities related to the secure
administration and efficient handling of car crash situations depending on alerts received.
Reuse
1 oeCreateSystemAndEnvironment
2 ugAdministrateTheSystem [1..*]
3 suGlobalCrisisHandling [1..*]
4 oeSetClock [1..*]
5 oeSollicitateCrisisHandling [*]
6 oeAlert [1..*]
Protocol condition(s)
1 the iCrash system has never been deployed and used
Pre-condition(s)
1 none
Main post-condition(s)
1 the iCrash system has been created and has handled the crisis situations for which it received alerts
through the communication company.
Main Steps
a the actor actMsrCreator executes the oeCreateSystemAndEnvironment use case
b the actor actAdministrator executes the ugAdministrateTheSystem use case
c the actor actComCompany executes the oeAlert use case
d the actor actActivator executes the oeSetClock use case
e the actor actActivator executes the oeSollicitateCrisisHandling use case
f the actor actCoordinator executes the suGlobalCrisisHandling use case
Steps Ordering Constraints
1 step (a) must be always the first step.
2 step (f) can be executed by different actCoordinator actors.
3 if (e) than previously (d).

66 / 157
iCrash
Use Case Instance
Diagram View
Illustration

67 / 157

68 / 157
1 //----------------------------------------------------
2 steve
3 executed instanceof subfunction
4 oeLogin("steve","pwdMessirExcalibur2017"){
5 ieMessage('You are logged ! Welcome ...') returned to steve
6 }
7 //----------------------------------------------------
8 steve
10 oeGetCrisisSet("pending"){
11 ieSendACrisis("crisis with ID 1 details") returned to steve
12 }
13 //----------------------------------------------------
14 steve
16 oeSetCrisisHandler("1"){
17 ieSmsSend("+3524666445252","The handling of your alert by our services is in
progress !")
18 returned to tango
19 ieMessage("You are now considered as handling the crisis !")
20 returned to steve
21 }
22 //----------------------------------------------------

iCrash - Environment Model
69 / 157

iCrash - Environment Model
70 / 157
1 actor actCoordinator
2 role rnactCoordinator
3 cardinality [0..*]
4 extends actAuthenticated{
5
6 operation init():ptBoolean
7
8 output interface outactCoordinator{
9 operation oeInvalidateAlert(AdtAlertID:dtAlertID ):ptBoolean
10 operation oeCloseCrisis(AdtCrisisID:dtCrisisID ):ptBoolean
11 operation oeGetAlertsSet(AetAlertStatus:etAlertStatus ):ptBoolean
12 operation oeGetCrisisSet(AetCrisisStatus:etCrisisStatus ):ptBoolean
13 operation oeSetCrisisHandler(AdtCrisisID:dtCrisisID ):ptBoolean
...1 input interface inactCoordinator{
2 operation ieSendAnAlert(ActAlert:ctAlert ):ptBoolean
3 operation ieSendACrisis(ActCrisis:ctCrisis ):ptBoolean
4 }
5 }

iCrash - Concept Model
71 / 157
Concept Model - ctAlert

72 / 157
Class types and associations

73 / 157
Primary Types
/ Data Types

74 / 157
1 Concept Model {
2
3 Primary Types{
...1 class ctAlert role rnctAlert cardinality [0..*]{
2 attribute id:dtAlertID
3 attribute status: etAlertStatus
4 attribute location:dtGPSLocation
5 attribute instant:dtDateAndTime
6 attribute comment:dtComment
7
8 operation init( Aid:dtAlertID ,
9 Astatus:etAlertStatus ,
10 Alocation:dtGPSLocation ,
11 Ainstant:dtDateAndTime ,
12 Acomment:dtComment ):ptBoolean
13 operation isSentToCoordinator(AactCoordinator:actCoordinator ):ptBoolean
14
15 }

iCrash - Operation Model
MessirOperation Model
The objective is to provide the
properties that "characterize" all valid
"executions" for each system operation.
Categories of semantic properties
• Pre-protocol
• Pre-functional
• Post-functional
• Post-Protocol
75 / 157
System
Environment
?
output
event
input
event
global_statei
Output event
+
Input event 1
Input event 2
.....
env@pre
system@pre
env@post
system@post
global_statei+1

76 / 157
Operation Model at
Deﬁnition level (msrd ﬁle)
1 @@Operation
2 icrash.environment.actAdministrator.outactAdministrator.oeAddCoordinator
1 @description
2 "sent to add a new coordinator in the system's post state and environment
's post state."
3
4 //preProtocol descriptions
5 @preP
6 "the system is started"
7 @preP
8 "the actor logged previously and did not log out ! (i.e. the associated
ctAdministrator instance is considered logged)"
9 @endPreP
10
11 //preFunctional descriptions
1 @postF
2 "the system's state has a new instance of ctCoordinator initialized with
the given values."
3 @postF
4 "the new actor instance and ctCoordinator instance are related."

77 / 157
Operation Model at
Speciﬁcation level (mcl)
1 operation: icrash.environment.actAdministrator.outactAdministrator.
oeAddCoordinator(AdtCoordinatorID:dtCoordinatorID, AdtLogin:dtLogin,
AdtPassword:dtPassword):ptBoolean
1 postF:
2 let TheSystem: ctState in
3 self.rnActor.rnSystem = TheSystem
4 self.rnActor.rnSystem = TheSystem
5 and self.rnActor = TheActor
6 /* PostF01 */
7 TheactCoordinator.init()
8
9 /* PostF02 */
10 and ThectCoordinator.init(AdtCoordinatorID,AdtLogin,AdtPassword)
11
12 /* PostF03 */
13 and TheactCoordinator@post.rnctCoordinator = ThectCoordinator
14
15 /* PostF04 */
16 and ThectCoordinator@post.rnactAuthenticated = TheactCoordinator
17
18 /* PostF05 */
19 and TheActor.rnInterfaceIN^ieCoordinatorAdded()

78 / 157
Operation Model at Simulation level
(Prologmsr code)
1msrop(outactAdministrator,
2 oeAddCoordinator,
3 [preProtocol,Self,
4 AdtCoordinatorID,
5 AdtLogin,
6 AdtPassword
7 ],
8 []):-
...1/* PostF03 */
2 msrNav([TheactCoordinator],
3 [msmAtPost,rnctCoordinator],
4 [ThectCoordinator]),
5/* PostF05 */
6 msrNav([TheActor],
7 [rnInterfaceIN,
8 ieCoordinatorAdded,[]],
9 [[ptBoolean,true]]),

iCrash - Test Model
MessirTest Model
Defines test cases to:
1. verify or validate the specification by inspection or
simulation
2. verify or validate the delivered program
A test case is a sequence of test steps
• Test message - system operation triggered
• Constraints - domain for the parameter values
• Oracle - defines acceptance conditions
79 / 157
System
Environment
?
output
event
input
event
global_statei
Output event
+
Input event 1
Input event 2
.....
env@pre
system@pre
env@post
system@post
global_statei+1

iCrash - Test Model
80 / 157
1 test step ts12oeSetCrisisHandler order 12{
2 variables{
3 TheActor : actCoordinator
4 AdtCrisisID : dtCrisisID
5 }
6 constraints{
7 TheActor=TheSystem.rnactCoordinator
8 ->select(a | a.rnctCoordinator.login.
value.eq('steve'))
9 ->any2(true)
10 AdtCrisisID.value= '1'
11 }
12 test message{
13 out:TheActor sends to system
actCoordinator.outactCoordinator.
oeSetCrisisHandler(AdtCrisisID)
14 }
15 oracle{
16 variables{
17 AMessage:ptString
18 AdtPhoneNumber:dtPhoneNumber
19 AdtSMS:dtSMS
20 ActAlert:ctAlert
21
22 TheComCompany: actComCompany
23 TheCoordinator:actCoordinator
24 }
25 constraints{
26 AMessage = 'You are now considered as
handling the crisis !'
27 AdtSMS.value = 'The handling of your
alert by our services is in progress !'
28 TheComCompany.inactComCompany.ieSmsSend
(AdtPhoneNumber,AdtSMS)
29 TheCoordinator.inactCoordinator.
ieSendAnAlert(ActAlert)
30 TheActor.inactAuthenticated.ieMessage(
AMessage)
31 }

iCrash - Construction
81 / 157
What is the iCrash v1.0
Implementation Artefact ?

82 / 157
iCrash .FX v1.0 Program - GUI
Administrator
Coordinators
Panel

83 / 157
Administrator
Authentication
Panel

84 / 157
ComCompany
Alert
Panel

85 / 157
Coordinator
Alerts
Panel

86 / 157
Communication
Company
Crisis
Panel

87 / 157
Coordinator
Report
Panel

88 / 157
Coordinator
Status
Panel

89 / 157
Coordinator
Authentication
Panel

90 / 157
Activator
Clock
Panel

91 / 157
iCrash v1.0 Program - DB

92 / 157
iCrash v1.0 Program - DB

iCrash SEP Variant - Tools
93 / 157
What is the MessirSoftware Engineering Environment ?

94 / 157
Software Engineering Tools.
1 Requirements
2 Design
3 Construction
4 Management
5 Quality
6 Maintenance
Figure: Tools Focus
Type/Scope
• Tool: supports an individual Task
Unit belonging to the development
life cycle.
• Workbench: combines in an
integrated way two or more tools to
cover a sub-part of the software life
cycle.
• Environment: combines tools and
workbenches in order to target the
maximum coverage of the life
cycle.

Activities Tools/Technologies
Requirements
Excalibur Eclipse SE
workbench
95 / 157
MessirSoftware engineering Environment

Design
Eclipse UML Designer
96 / 157

Construction
Functionalities - Java
GUI - JavaFx
Data persistency - MySQL
Distributed processing -
Java RMI
... Tomcat
97 / 157

Management
Atlassian Conﬂuence knowledge base
collaboration tool.
SubVersioN versioning and revision
control tool.
Atlassian Bamboo and
Apache Maven continuous integration
server for project builds.
maven
VirtualBox
98 / 157

Quality
Test based Veriﬁcation &
Validation
• Messir Excalibur
simulator
• SWTbot testing tool for
graphical user interface.
• JUnit unit testing framework
• EclEmma Java code coverage.
Syntax validation tools
99 / 157

Maintenance
Atlassian JIRA issue tracking tool.
SubVersioN versioning and revision
control tool.
Atlassian Bamboo and
Apache Maven continuous integration
server for project builds.
maven
100 / 157

101 / 157

102 / 157

103 / 157

104 / 157

105 / 157

106 / 157

107 / 157

108 / 157

109 / 157
iCrash v1.0 Requirements Documentation
iCrash :
A Crisis Management Case Study
Å ×× ÖAnalysis Document
- v 1.4 -
(Report type: Simulation)
Laboratory for Advanced Software Systems
University of Luxembourg
Thursday 5th
November, 2015 - 08:12
iCrash :
Å ×× ÖAnalysis Document
- v 1.4 -
(Report type: Simulation)
Thursday 5th
November, 2015 - 08:12

110 / 157

111 / 157

iCrash SEP Variant - iCrash v1.ME
112 / 157
How to deﬁne my own
Project Variant ?

113 / 157
Messep - Variant Derivation Process
1 Define Deltas for iCrash 4ME
• Remove Unwanted features
◦ Requirements simulation level (Prolog)
• Add new features
◦ Activity/Requirements
(a) Define an access rights policy depending on coordinators domain of expertise.
(b) Update adequately the requirements artefacts (specification and report)
◦ Activity/Construction
(a) Update the iCrash v1.0 system to include your access rights policy
• Modify selected features
◦ Project schedule . ..

114 / 157
2 Deﬁne Deltas for iCrash v1. TCS
(a) Use Algebraic Petri Nets to model the
iCrash system
(b) Verify using model checking with the AlPiNA[a]
tools if an alert can stay unhandled inﬁnitely
◦ Project schedule .. .

114 / 157
sendcrisis
[$cd]
Recording Crisis Data
[]
[system($cd)]
System
sendcrisisfor
validation
[system(getcrisistype($vcs),
true)]
assigncrisis
isvalidcrisis($sy=true)&
invalidsobs($sob,
getcrisistype($sy)=true)
[$sy]
[assigncrisis($sob,$sy)]
Superobserver Ready
[$sob]
ExecutingCrisis
[$sy]
sendreport
blkrep($ec=true)
[$ec]
[]
ExecutedCrisisReport
[rp($ec)]
[sobs(YK,Fire)
sobs(NG,Blockage)]
[]
[system(getcrisistype($sy),
false)]
ValdidatingCrisis
validatecrisis
[$vcs]
[Fire, Fire,
Blockage,Blockage]
iCrash system
◦ Project schedule .. . [a] [Hostettler et al.(2011)Hostettler, Marechal, Linard, Risoldi, and Buchs]
[b] [Buchs and Guelﬁ(1991)]
[c] [Buchs and Guelﬁ(2000)]

115 / 157
1 Deﬁne Deltas for iCrash Eiffel [Meyer(2009)]
◦ iCrash Java Implementation
◦ Activity/Construction
(a) Write an Eiffel implementation that
conforms to the iCrash program.
◦ Activity/Code Generation
(b) Use the Xtend and Xtext MDE tools to
generate Eiffel implementation from
Messir speciﬁcation
◦ Project schedule ...

MessepWhat do I concretely get ?
116 / 157
What do I
Concretely Get ?

Actor Deliverables
Instructor
Main Work Products
• Project Course Syllabus (source,pdf)
• Project Course Evaluation forms (source, pdf,
xls)
Main Beneﬁts
• Efﬁciency - rapid engineering of SE project
course
• Quality - reuse of quality components
• Maintenability - standardized, generic,
modular & tool supported
• Stability in time in front of changing
instructors
• Flexibility - SE Coverage adapted to degree
or course objectives
117 / 157
Main Concrete Usable Messep Deliverables

Actor Deliverables
Students
Main Work Products
• Specialized Project Deﬁnition
• Reusable projects inputs (documentation,
models, source, executables, ...)
• Software Engineering Environment
Main Beneﬁts
• Learnability - teaching material
• Accessibility - tools
• Maturity - soundness of reused components
• Adequacy - work vs resource
• Motivation - more results / more experience
/ less failures / less deadlocks
118 / 157
Main Concrete Usable Messep Deliverables

MessepFlexibility
119 / 157
Messep Usage & Flexibility
Bachelor Level
• UML modeling with class diagrams, use case diagrams and
sequence diagrams
• Requirements engineering with use cases
• Practical development projects of with Java , JavaFx , MySQL .
• Introduction to software engineering concepts
• Introduction to development methods concepts
• Introduction to product quality
• Veriﬁcation and Validation
• ...

MessepFlexibility
120 / 157
Master Level
• Advanced Requirements Engineering
• Model Driven Engineering
• Domain Speciﬁc Languages: concepts and tools
• Software Engineering Environments: use and development
• Formal Methods
• Operational and Axiomatic Semantics
• Testing and Model checking
• Constraint logic programming
• ...

MessepFlexibility
121 / 157
Doctorate Level
• Theories, Methods and tools in the software engineering domain
• Domain Specific Languages
• Model Driven Engineering
• Specification based testing
• Dependability requirements
• Simulation and verification of modeling languages
• ...

TMPA-2015-Keynote - Part: Conclusion
Part V
Conclusion
122 / 157

MessirWho ?
123 / 157
There is a (HUGE) need to improve SE Education !
Messep SE Project Courses Product Line
• Allows for Rapid SE Course Deﬁnition & Evolution
• Reconciliates Science & Engineering
• Ensure Quality by Reuse
• Eases Educators Collaboration
• Improves SWEBOK Coverage

MessirWho ?
124 / 157
Messir& Excalibur Producers
• Nicolas Guelﬁ
• Alfredo Capozucca
• Benoit Ries

MessirWho ?
125 / 157
MessirProspective Network
Cat. Reg. RC CC Institution Contact(s)
edu 01 NA CA McGill University Joerg Kienzle
edu 01 NA US Carnegie Mellon University - Silicon Valley Cécile Péraire
edu 01 NA US Michigan State University Betty Cheng
edu 01 NA US University of Southern California George Edwards
Nenad Medvidovic
edu 02 WE CH University of Geneva Didier Buchs
edu 02 WE DE University of Hamburg Daniel Moldt
edu 02 WE IT University of Turin Susanna Donatelli
edu 02 WE IT University of Milan Lucia Pomello
edu 02 WE LU University of Luxembourg Nicolas Guelﬁ
edu 02 WE UK University of Newcastle Maciej Koutny
edu 05 EE RU Saint Petersburg State Technical University Vladimir Itsykson
Evgeny Pyshkin
ind 02 WE LU iTrust Consulting Carlo Harpes
Figure: Messir Prospective Network

MessirWho ?
126 / 157
Know a
Hero ?

MessirWho ?
126 / 157
Being him ...

MessirWho ?
126 / 157
Or him ...

MessirWho ?
126 / 157
Know a Victim ?

MessirWho ?
126 / 157
Tell him
to join our
daily scrum !

MessirWho ?
127 / 157
Contact us !
messir@uni.lu

Discussion
Questions, Ideas, Remarks
128 / 157

Discussion
References
[UNE(2012)] International Standard Classiﬁcation of Education (ISCED) 2011.
UNESCO Institute for Statistics, 2012.
doi: 10.15220/978-92-9189-123-8-en.
URL http://dx.doi.org/10.15220/978-92-9189-123-8-en.
[ACM/IEEE(2015)] ACM/IEEE.
Software engineering 2014 - curriculum guidelines for undergraduate degree programs in software engineering.
2015.
URL https://www.acm.org/education/SE2014-20150223_draft.pdf,https:
//www.acm.org/education/curricula-recommendations.
[Anderson et al.(2001)Anderson, Krathwohl, and Bloom] Lorin W Anderson, David R Krathwohl, and Benjamin Samuel Bloom.
A taxonomy for learning, teaching, and assessing: A revision of Bloom’s taxonomy of educational objectives.
Allyn & Bacon, 2001.
[Bauer(1971)] Friedrich L. Bauer.
Software engineering.
In 1. Foundations and systems., International Federation for Information Processing: IFIP congress series, pages 530–538, August 1971.
[Beck and al.(2001)] Kent Beck and al.
The agile manifesto, 2001.
[Bloom and Krathwohl(1956)] Benjamin Samuel Bloom and David R Krathwohl.
Taxonomy of educational objectives: The classiﬁcation of educational goals. handbook i: Cognitive domain.
1956.
[Bollinger and McGowan(2009)] Terry Bollinger and Clement McGowan.
A critical look at software capability evaluations: An update.
Software, IEEE, 26(5):80–83, 2009.
129 / 157

Discussion
Title
[Buchs and Guelfi(1991)] Didier Buchs and Nicolas Guelfi.
Co-opn: A concurrent object oriented petri net approach. in application and theory of petri nets.
In 12th International Conference, Gjern, Denmark, pages 432–454, 1991.
[Buchs and Guelfi(2000)] Didier Buchs and Nicolas Guelfi.
A formal specification framework for object-oriented distributed systems.
Software Engineering, IEEE Transactions on, 26(7):635–652, 2000.
[Heer(2012)] Rex Heer.
A model of learning objectives—based on a taxonomy for learning, teaching, and assessing: a revision of bloom’s taxonomy of educational
objectives.
Center for Excellence in Learning and Teaching, Iowa State University. http://www. celt. iastate. edu/teaching/RevisedBlooms1. html, 2012.
[Heiman(2010)] R Heiman.
Idc’s software taxonomy 2010.
International Data Corporation, Framingham, 2010.
[Hostettler et al.(2011)Hostettler, Marechal, Linard, Risoldi, and Buchs] Steve Hostettler, Alexis Marechal, Alban Linard, Matteo Risoldi, and Didier
Buchs.
High-level petri net model checking with alpina.
Fundamenta Informaticae, 113(3-4):229–264, August 2011.
ISSN 0169-2968.
[Hutchinson et al.(2011)Hutchinson, Whittle, Rouncefield, and Kristoffersen] John Hutchinson, Jon Whittle, Mark Rouncefield, and Steinar
Kristoffersen.
Empirical assessment of mde in industry.
In Proceedings of the 33rd International Conference on Software Engineering, pages 471–480. ACM, 2011.
130 / 157

Discussion
Title
[IEEE(1990)] IEEE.
Ieee standard glossary of software engineering terminology.
Technical report, 1990.
URL http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342.
[ISO/IEC(2005)] ISO/IEC.
Software Engineering – Guide to the Software Engineering Body of Knowledge (SWEBOK).
International Organization for Standardization, 2005.
ISO-IEC TR 19759-2005.
[ISO/IEC(2014)] ISO/IEC.
Software Engineering – Guide to the Software Engineering Body of Knowledge (SWEBOK).
International Organization for Standardization, 2014.
ISO-IEC TR 19759-2014.
[Meyer(2009)] Bertrand Meyer.
Touch of Class: Learning to Program Well with Objects and Contracts.
Springer Publishing Company, Incorporated, 1 edition, 2009.
ISBN 3540921443, 9783540921448.
[Naur and Randell(1969)] P. Naur and B. Randell.
Software engineering report of a conference sponsored by the nato science committee garmisch germany 7th-11th october 1968.
1969.
URL http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF.
131 / 157

Discussion
Title
[Parnas(1997)] David Lorge Parnas.
Software engineering: An unconsummated marriage (extended abstract).
In Mehdi Jazayeri and Helmut Schauer, editors, Software Engineering - ESEC/FSE ’97, 6th European Software Engineering Conference Held Jointly
with the 5th ACM SIGSOFT Symposium on Foundations of Software Engineering, Zurich, Switzerland, September 22-25, 1997, Proceedings, volume 1301
of Lecture Notes in Computer Science, pages 1–3. Springer, 1997.
ISBN 3-540-63531-9.
doi: 10.1145/267895.267897.
URL http://doi.acm.org/10.1145/267895.267897.
[Paulk(1993)] Mark Paulk.
Capability maturity model for software.
Wiley Online Library, 1993.
[Rodríguez and al.(2012)] Pilar Rodríguez and al.
Survey on agile and lean usage in ﬁnnish software industry.
In Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement, pages 139–148. ACM, 2012.
[Sahami and Roach(2014)] Mehran Sahami and Steve Roach.
Computer science curricula 2013 released.
Commun. ACM, 57(6):5–5, June 2014.
ISSN 0001-0782.
doi: 10.1145/2610445.
URL http://doi.acm.org.proxy.bnl.lu/10.1145/2610445.
[SEI(2010)] CMMI Product SEI.
Cmmi for development (cmmi-dev).
Technical report, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, 2010.
132 / 157

Discussion
Title
[Stavru(2014)] Stavros Stavru.
A critical examination of recent industrial surveys on agile method usage.
Journal of Systems and Software, 94:87–97, 2014.
[VersionOne(2012)] Inc VersionOne.
6th annual state of agile survey.
[VersionOne(2015)] Inc VersionOne.
9th annual state of agile survey.
133 / 157

Glossary
engineering the practical application of scientiﬁc ideas and principles.. 13
science a systematically organized body of knowledge on any subject.. 13
134 / 157

Appendix
135 / 157
Effective CoverageNG by Variant
36
%
Figure: SWEBOK Coverage iCrash v1.0 (36%)

Appendix
136 / 157
Problem: How to determine “more precisely” the
SWEBOK topic cognitive acquisition provided by a
lecture ?
Solution:
1. associate a Focus Level (1,2 or 3) representing the
importance of the subject w.r.t. to the lecture’s main
concern.
2. associate a Bloom Cognitive Level (1 to 6): representing
the output cognitive level supposed to be reached after
successful completion of the lecture
([Bloom and Krathwohl(1956)]).
3. compute an weighted average using quantiﬁed Bloom
Cognitive Level and focus level

Appendix
137 / 157
Bloom Education Levels
[Bloom and Krathwohl(1956)],
[Anderson et al.(2001)Anderson, Krathwohl, and Bloom],
(3D model from [Heer(2012)])

Appendix
1 Remembering
2 Understanding
3 Applying
4 Analyzing
5 Evaluating
6 Creating
Figure: Bloom 2001 Levels
138 / 157
Bloom 2001 Education Levels
[Anderson et al.(2001)Anderson, Krathwohl, and Bloom]

Appendix
Focus Levels
Bloom Levels 1 2 3
Creating 6 80 90 100
Evaluating 5 60 70 80
Analyzing 4 50 55 60
Applying 3 35 40 45
Understanding 2 20 25 30
Remembering 1 5 10 15
Table: Acquisition Levels Scale (%)
by Cognitive and Focus levels
139 / 157
MessirSWEBOK Acquisition Scale

Appendix
1 Remembering
1 Retrieving, recognizing, and recalling
relevant knowledge from long-term memory.
2 Understanding
1 Constructing meaning from oral, written,
and graphic messages through interpreting,
exemplifying, classifying, summarizing,
inferring, comparing, and explaining.
3 Applying
1 Carrying out or using a procedure through
executing, or implementing.
Figure: Bloom 2001 Levels 1,2,3
4 Analyzing
1 Breaking material into constituent parts,
determining how the parts relate to one
another and to an overall structure or
purpose through differentiating, organizing,
and attributing.
5 Evaluating
1 Making judgments based on criteria and
standards through checking and critiquing.
6 Creating
1 Putting elements together to form a coherent
or functional whole; reorganizing elements
into a new pattern or structure through
generating, planning, or producing.
Figure: Bloom 2001 Levels 4,5,6
140 / 157
Bloom Education Levels
[Anderson et al.(2001)Anderson, Krathwohl, and Bloom]

Appendix
141 / 157
Agile Techniques Used - [VersionOne(2015)]
0 20 40 60 80 100
Daily Standup
Prioritized backlogs
Short Iterations
Iteration Planning
Retrospectives
Release Planning
Unit Testing
Team-based estimation
Taskboard
Iteration reviews
80
79
79
71
69
65
65
56
53
53
Percentage (%)
0 20 40 60 80 100
Dedicated Product Owner
Single integrated team
Coding Standards
Open Work area
Refactoring
Test-driven development
Kanban
Story Mapping
Collective Code Ownership
Automated Acceptance Testing
Continuous Deployment
Pair Programming
Agile Games
Behaviour Driven Development
48
46
43
38
36
34
31
29
27
24
24
21
13
9
Percentage (%)

Appendix
142 / 157
Semiotics and the forgotten Pragmatics
semiotics
steve:Adminitrator
(pa,[1])
steve: Administrator
steve : Administrator
1
pa
syntactics semantics pragmatics

Appendix
143 / 157
MessirBook
Nicolas Guelfi
Å ×× ÖA Scientific Method for
the Software Engineering Master
- v 0.63 -
Thursday 14th
May, 2015 - 16:26
Contents
Part I - Specification, Simulation and Documentation 1
I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.3 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.2 Environment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.3 Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.3.1 Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.3.3.2 Datatype Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.3.3.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.3.3.4 Type Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.3.3.5 Textual Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.3.6 Graphical Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.3.7 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.4 Operation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.4.2 Constraints Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.3.4.3 Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.3.4.4 Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.3.5 Tests Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.5.2 Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.5.3 Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.6 Additional Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.6.1 Dependability Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.6.2 Performance Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.6.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.6.4 Other constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7.1 General Textual Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7.2 General Graphical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7.3 Environment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7.4 Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.3.7.5 Operation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
I.3.7.6 Test Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
I.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.2 Translating to Prolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.2.1 The Underlying Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.2.2 The Simulation Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.2.3 Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.4.3 Tests Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
I.4.4 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vNicolas Guelfi- Wednesday 11th November, 2015 (23:06) - University of Luxembourg, LU

Appendix
144 / 157
Excalibur Book
Alfredo Capozucca, Benoît Ries
Ü
Ð ÙÖ
Model-Driven Tools
for Domain-Speciﬁc
Languages and Methods
- v 0.47 -
Thursday 14th
May, 2015 - 16:21
Contents
Part I Prelude
I.1 Ü
Ð ÙÖ Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part II Ü
Ð ÙÖ User Guide (70-100 pages)
II.1 Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.2 Introduction (10 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.3 Analysis Models (15 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.4 Views (15 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.5 Documentation (15 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.6 Simulation (15 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II.7 F.A.Q. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part III Model-Driven Engineering of a DSL Environment (200-220 pages)
III.1 Software Engineering Environments (30 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.2 Specifying textually (50 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.3 Representing graphically (50 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.4 Documenting (50 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.5 Formally simulating (20 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.6 Limitations (5 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.7 Development roadmap (5 pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix
145 / 157
Messir
Tutorial Slides
- Part:
1 / 252
Who are
you ?
My Name is
Guelfi !
Nicolas Guelfi
A Scientific Method for
the Software Engineering Master
-
Tutorial
Nicolas Guelfi - February 5, 2015 (17:03) - University of Luxembourg
- Part: Operation Model - Theory
Operation Specification in Process
Categories of semantic properties
Pre-functional properties
I Conditions under which the system
operation is considered defined .
I Expressed using:
• the system’s state @pre
• the environment state @pre
• the operation parameters
11 / 252
System
Environment
?
output
event
input
event
global_statei
Output event
+
Input event 1
Input event 2
.....
env@pre
system@pre
env@post
system@post
unde f ined de f ined
global_statei+1
Nicolas Guelfi - February 5, 2015 (17:03) - University of Luxembourg
- Part: Process - Illustration
Phase: Iteration 1 - Requirements Definition
Step 3 - Refine Use Case Model - Application
PROCESS STEP
Phase: Requirement Elicitation - Iteration: 1 - Step: 3
Name: Refine Use Case Model
Goal
to reach a fixed point for the first version of the use case model
Process
1. refine existing use cases - select all use cases that contain steps that would
need to be decomposed differently:
1.1 Refine using use case levels adequately (subfunction<usergoal<summary)
1.2 Refine actor definition by using inheritance for interface sharing and by modifying the
interfaces to be consistent with the update version of the use cases.
2. refine use cases instances - for each use case instance impacted by the use
case refinement, redefine the use cases instances including consistent
refinement of information exchange descriptions.
3. enrich use case instances - provide additional use case instances to improve
the coverage of interactions scenarios between system and environment.
- Part: Process - Illustration
Phase: Iteration 1 - Requirements Definition
Step 3 - Refine Use Case Model - Application
1 Use Case Model {
2
3 use case system usergoal
4 ugAdministrateTheSystem() {
5 primary actor actAdministrator[active]
6
7 reuse ugSecurelyUseSystem[1..*]
8 reuse oeAddCoordinator[1..*]
9 reuse oeDeleteCoordinator[1..*]
10
11 step a: actAdministrator
12 executes ugSecurelyUseSystem
13 step b: actAdministrator
14 executes oeAddCoordinator
15 step c: actAdministrator
16 executes oeDeleteCoordinator
17 }
18 }
19}

Appendix
146 / 157

Appendix
147 / 157

Appendix
148 / 157

Appendix
149 / 157

Appendix
150 / 157

Appendix
151 / 157

Appendix
152 / 157

Appendix
153 / 157

Appendix
154 / 157

Appendix
155 / 157

Appendix
156 / 157
6, rue R. Coudenhove-Kalergi, Luxembourg
iCrash :
Analysis Document
- v 1.3 -
Monday 15th June, 2015 - 18:17
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Purpose and recipients of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Application Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Deﬁnitions, acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Domain Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Communication Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Humans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Coordinators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4 Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.5 Creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.6 Activator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 System’s Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Use Cases Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Use Case Instance(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Environment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Local view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Local view 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Local view 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Local view 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Local view 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Global view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Actors and Interfaces Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.1 actActivator Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.2 actAdministrator Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.3 actAuthenticated Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.4 actComCompany Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.5 actCoordinator Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.6 actMsrCreator Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 PrimaryTypes-Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1 Local view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.2 Local view 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.3 Local view 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.4 Local view 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.5 Global view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 PrimaryTypes-Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Global view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 SecondaryTypes-Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Local view 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2

Appendix
157 / 157
38 4 Concept Model
Fig. 4.5 Concept Model - PrimaryTypes-Classes global view 01. Primary types class types global view - cm-pt-ct-gv-01 .
4.3 SecondaryTypes-Datatypes
4.3.1 Local view 01
Figure 4.7 shows the local view of the secondary types datatype types.
4.4 Concept Model Types Descriptions
This section provides the textual descriptions of all the types defined in the concept model and that can be part
of the graphical views provided.
4.4.1 Primary types - Class types descriptions
The table below is providing comments on the graphical views given for the class types of the primary types.
Type logical operations are precisely specified in the operation model.
Classes
ctAdministrator
used to caracterize internally the entity that is responsible of administrating the iCrash system.
extends icrash.concepts.primarytypes.classes.ctAuthenticated
operation init: used to initialize the current object as a new instance of the ctAdministrator type.
ctAlert
Used to model crisis alerts sent by any human having communication capability using communication companies
belonging to the system’s environment
4.4 Concept Model Types Descriptions 39
. . . Classes table continuation
attribute id: dtAlertID: the alert unique identification information.
attribute status: etAlertStatus: the alert validation status
attribute location: dtGPSLocation: the position of the alert provided by the space-based satellite
navigation system used by the human using the communication company to inform the
iCrash system of a crisis.
attribute instant: dtDateAndTime: the date and time at which the alert notification has been sent.
attribute comment: dtComment: a textual description providing unstructured information on the
alert.
operation init: used to initialize the current object as a new instance of the ctAlert type.
operation isSentToCoordinator: used to provide a given coordinator with current alert information.
ctAuthenticated
used to model system’s representation about actors that need to authenticate to access some specific
functionalities.
attribute login: dtLogin: an identifier for authentication.
attribute pwd: dtPassword: a key for authentication.
attribute vpIsLogged: ptBoolean: used to determine the access status.
operation init: used to initialize the current object as a new instance of the ctAuthenticated type.
ctCoordinator
used to model system’s representation about the actors that have the responsibility to handle alerts and crisis.
extends icrash.concepts.primarytypes.classes.ctAuthenticated
attribute id: dtCoordinatorID: a unique identification information.
operation init: used to initialize the current object as a new instance of the ctCoordinator type.
ctCrisis
Used to model crisis that are infered from the reception of at least one alert message. Crisis aer entities that
are handled by the iCrash system.
attribute id: dtCrisisID: the crisis unique identification information.
attribute type: etCrisisType: an indication of the gravity of the crisis.
attribute status: etCrisisStatus: the crisis handling status.
attribute location: dtGPSLocation: the position of the crisis equal by the one of the first alert
received and associated to the crisis.
attribute instant: dtDateAndTime: the date and time at which the first related alert notification
has been sent.
attribute comment: dtComment: a textual description providing unstructured information on the
crisis handling.
operation init: used to initialize the current object as a new instance of the ctAlert type.
operation handlingDelayPassed: used to determine if the crisis stood too longly in a pending status
since last reminder.
operation maxHandlingDelayPassed: used to determine if the crisis stood too longly in a pending
status since its creation.
operation isSentToCoordinator: used to provide a given coordinator with current crisis information.
operation isAllocatedIfPossible: used to allocate a crisis to a coordinator if any or to alert the
administrator of crisis waiting to be handled.
ctHuman
used to model system’s representation about the indirect actors that has alerted of potential crisis.
attribute id: dtPhoneNumber: the number of the communication device used to send an alert to
iCrash system.
attribute kind: etHumanKind: role with respect to the alert notified.
operation init: used to initialize the current object as a new instance of the ctHuman type.
ctState
used to model the system. Each system specified using must include a ctState class for which there
is only one instance at any state of the abstract machine after creation.
attribute nextValueForAlertID: dtInteger: used to associate each alert declared with a unique
idenitification value.
continues in next page . . .

TMPA-2015: Software Engineering Education: The Messir Approach

More Related Content

What's hot

Viewers also liked

Similar to TMPA-2015: Software Engineering Education: The Messir Approach

More from Iosif Itkin

Recently uploaded

TMPA-2015: Software Engineering Education: The Messir Approach