This presentation is about a lecture I gave within the "Software Modeling" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam. http://www.ivanomalavolta.com

1. Software and Services research group (S2)
Department of Computer Science, Faculty of Sciences
Vrije Universiteit Amsterdam
VRIJE
UNIVERSITEIT
AMSTERDAM
Introduction to the course
Software modeling (401016) – 2016/2017
Ivano Malavolta
i.malavolta@vu.nl

2. VRIJE
UNIVERSITEIT
AMSTERDAM
Hello
2
Software Architecture & Model-Driven Engineering
applied to
Autonomous drones
Mobile applications
Web technologies
If you think good architecture is expensive,
try bad architecture.
... Brian Foote and Joseph Yoder

3. VRIJE
UNIVERSITEIT
AMSTERDAM
Who is who
• Ivano Malavolta
• i.malavolta@.vu.nl
• Room T4.38 – Sciences building
• Lars Cordewener
• l.e.j.cordewener@student.vu.nl
• George Karlos
• g.karlos@student.vu.nl
3
teaching assistants
coordinator & lecturer

4. VRIJE
UNIVERSITEIT
AMSTERDAM
Roadmap
• Introduction to the course
• Software abstraction and modeling
• Software development process
4

5. VRIJE
UNIVERSITEIT
AMSTERDAM
Introduction to the course
5

6. VRIJE
UNIVERSITEIT
AMSTERDAM
Quick test J
6

7. VRIJE
UNIVERSITEIT
AMSTERDAM
Recommended background knowledge
The course does not impose any specific prerequisites
The only requirement is a basic knowledge of Java
• to check whether you know Java, follow this tutorial (until the
Java – Packages section):
• https://www.tutorialspoint.com/java
7

8. VRIJE
UNIVERSITEIT
AMSTERDAM
What this course is about
• MAIN GOAL – to have insights and knowledge about:
• recurrent software design problems
• methodologies and techniques for solving those problems
• object-oriented
• model-driven
• Understanding different types of software life cycle
• How to identify software requirements with models
• How to transform requirement models into design models
• How to let design models drive the whole development life
cycle
• source code generation
• models execution
8

9. VRIJE
UNIVERSITEIT
AMSTERDAM
What this course is NOT about
• How to write documentation
• How to draw nice pictures
• First I model, than I implement
• Good modeling à saving of time (and $$$)
9

10. VRIJE
UNIVERSITEIT
AMSTERDAM
Schedule of the course
10
Theory Lab sessions
WK 1 Abstraction + software life cycle
WK 2 Requirements engineering with UML
WK 3 Detailed structural models in UML + code generation
WK 4 Object-oriented design patterns in ML
WK 5 Behavioral models in UML + models execution
WK 6 Modeling communication patterns in UML
WK 7 Insights on advanced techniques + Q&A
WK 8 Exam and team project final boost
You will be evaluated on this part only

11. VRIJE
UNIVERSITEIT
AMSTERDAM
A typical lecture
• ~5 minutes
• discussion about the previous lab session
• questions about how it went, feeling about the tools, problems,
ideas, etc.
• ~5 minutes
• recap of the previous lecture and setting the stage for the
topics discussed in this lecture in a light way
• ~1 hour
• lecturing, giving and explaining examples, moderation of
possible discussions
• ~5 minutes
• wrap up, discussion of reading material, look forward to the
next phases of the course
11
Each lecture will be your
compass, not your book

12. VRIJE
UNIVERSITEIT
AMSTERDAM
Textbook
• [Mandatory] Martina Seidl, Marion Scholz, Christian Huemer,
Gerti Kappel, "UML@Classroom: An Introduction to Object-
Oriented Modeling", 2015.
12

13. VRIJE
UNIVERSITEIT
AMSTERDAM
Additional books
• [Optional] Russ Miles, Kim Hamilton, “Learning UML 2.0”,
O’Reilly, 2006.
• [Mandatory, only selected chapters] Craig Larman, “Applying
UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development”, 3rd edition,
Prentice Hall PTR, 2005.
13

14. VRIJE
UNIVERSITEIT
AMSTERDAM
A typical lab session
• ~5 minutes
• discussion about the previous lecture and lab
• ~15 minutes
• explanation of an exercise and its execution in an interactive
manner
• the source code of the exercise will be available on BB
• ~60 minutes
• you can work on your own team project by following the
same steps performed by the TA
• you can ask questions at any time to the TA, thus solving
your problems “on-demand”
• bring your own laptops
14
if you attend, you
already learnt J

15. VRIJE
UNIVERSITEIT
AMSTERDAM
Grading
• Team project (70% of the final grade)
• teams of 3 students
• each part of project will be started during the lab sessions
and finished as homework
• Written exam (30% of the final grade)
• 20 multiple-choice questions
• based on the books listed in the Readings section of the
student guide
More details on BlackBoard
15

16. VRIJE
UNIVERSITEIT
AMSTERDAM
Grading (continued)
To pass the course the following conditions must be met:
• The score of the team project must be 6.0 or higher
• The score of the written exam must be 6.0 or higher
• The final weighted grade must be 6.0 or higher
Deadlines and slip days:
• Deadlines are firm
• Violating deadlines means losing slip days
• You have 3 slip days per team
• You decide how to spend them
• Your assignment will be marked fail after you exhaust your
slip days
16

17. VRIJE
UNIVERSITEIT
AMSTERDAM
Course overall timeline
7 Feb
31 Mar
Modeling and software life cycle
Modeling requirements
Structural modeling
Behavioural modeling
Advanced concepts
• Teams formed
• Tool installed
Project deliverable 1
Project deliverable 2
Written exam
Project deliverable 3
30 Mar

18. VRIJE
UNIVERSITEIT
AMSTERDAM
Philosophical moment
18

19. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - the ROVU system
• Goal
• to develop a robotic system with various UML-based
techniques
• implement a simple demonstrator via a robotic 3D simulator
19

20. VRIJE
UNIVERSITEIT
AMSTERDAM
Project
• Teams of 3 students
• Aims:
• to put in practice what you will learn
• to develop your technical skills
• Two conceptual parts:
• Modeling
• Implementation (in Java)
• Each deliverable has two parts:
• Written report
• Eclipse project with source code and UML models
20
Start forming teams NOW!

21. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - modeling part
You will provide:
• a set of UML models of the ROVU system
• a detailed description of
• your design decisions
• how you evaluated alternatives
• how you shaped the problem and its solution
• etc.
The tools allow you to automatically generate Java source code
• you will use that Java code as basis for the implementation
part of the project
21

22. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - modeling part (tools)
Eclipse Papyrus
https://eclipse.org/papyrus
22

23. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - modeling part (tools)
Yakindu Statecharts
https://www.itemis.com/en/yakindu/statechart-tools
23

24. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - implementation part
• You will implement a running system from the created
models
• The resulting system must be functional with respect to a
basic usage of the modeled system
• In order to prove that your system works, you have to
• integrate it with the Simbad robotic simulator
• provide a demo video in which you show the simulation
24

25. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - implementation part (tool)
Reference material about the Simbad robot simulator can be
found here:
• http://simbad.sourceforge.net/index.php
• http://simbad.sourceforge.net/guide.php
• http://simbad.sourceforge.net/doc/
• https://github.com/jimmikaelkael/simbad/tree/master/src
• https://www.ibm.com/developerworks/library/j-robots/
25

26. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - schedule and deliverables
• Deliverable 1 (25% of the final grade)
• System informal description and system requirements
• Only modeling and textual descriptions
• Deadline: 24 February: 23:59
• Deliverable 2 (25% of the final grade)
• Detailed design model
• Modeling and code generation
• Deadline: 13 March: 23:59
• Deliverable 3 (50% of the final grade)
• Final project submission
• Modeling and implementation
• Deadline: 31 March: 23:59
26

27. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - the requirement change ⚡
• After the deadline for deliverable 2 I will declare a
requirement change of your system spec
• there are 3 types of changes
• your team will be randomly assigned to one of them
• You will adapt your project to the new requirement
• The change will not be disruptive if you correctly modelled
the system
27

28. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - relationship with lab sessions
Attendance to lab sessions is VERY advised (aka mandatory)
Each lab session will correspond to a specific part of your
project
à you can look at how each part is done by a TA
à you can ask questions to the TA interactively
à you can start working on your project right away
Misinterpreting or not applying what TAs teach in lab sessions
will result in failing the course
28

29. VRIJE
UNIVERSITEIT
AMSTERDAM
What we expect from you
This is a 6 credits course
à we ask you to invest approximately 150 hours for passing the
exam
Your estimated average time per week is as follows:
• Attending lectures and lab sessions: 4 hours
• Studying literature and lecture material: 8 hours
• Working on your team project: 6 hours
• TOTAL: 18 hours
• Total study time: 18 hours x 7 weeks = 126 hours
• Preparing for the final project: 150 – 126 = 24 hours
29

30. VRIJE
UNIVERSITEIT
AMSTERDAM
Communication
• All course material is provided on BlackBoard
• Dedicated forum on BlackBoard as well
• you will easily find potential solutions to your problems
already in there
• For questions concerning specific cases about the course
• i.malavolta@vu.nl
• Meet and talk to us during the breaks J
30

31. VRIJE
UNIVERSITEIT
AMSTERDAM
First action!
• Form your team and enroll on Blackboard (today)
• Tomorrow we will finalize the teams
• Setup the project tools
• Before next lab session
• Installation guides on BlackBoard for:
• Apple Mac
• Linux
• Microsoft Windows
31

32. VRIJE
UNIVERSITEIT
AMSTERDAM
Software abstraction and modeling
32

33. VRIJE
UNIVERSITEIT
AMSTERDAM
Where is software today?
33

34. VRIJE
UNIVERSITEIT
AMSTERDAM
How big is software today?
34
http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
http://hbr.org/2010/06/why-dinosaurs-will-keep-ruling-the-auto-industry/ar/1
Can you name some problems emerging
from software complexity and large size?

35. VRIJE
UNIVERSITEIT
AMSTERDAM
Abstraction
Engineers abstract away from a number of details that can
be ignored SAFELY
35
60k lines of text
60k lines of code
Slide inspired by Mircea Lungu

36. VRIJE
UNIVERSITEIT
AMSTERDAM
A metaphor: building construction is model-driven
36

37. VRIJE
UNIVERSITEIT
AMSTERDAM
Let’s build some models of the house
37

38. VRIJE
UNIVERSITEIT
AMSTERDAM
Example for software: mobile app navigation
38

39. VRIJE
UNIVERSITEIT
AMSTERDAM
Models and abstraction
The human mind continuously re-works reality by applying
cognitive processes
Model
a simplified or partial representation of reality, defined in order
to accomplish a task or to reach an agreement
Abstraction
the activity of finding the commonality in many different
observations
Modeling
the activity of creating models representing an abstract view of
the system
Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2012.
Model-Driven Software Engineering in Practice (1st ed.)

40. VRIJE
UNIVERSITEIT
AMSTERDAM
Models
What is a model?
Mapping Feature A model is based on an original (=system)
Reduction Feature A model only reflects a (relevant) selection
of the original‘s properties
Pragmatic Feature A model needs to be usable in place of an
original with respect to some purpose
ModelrepresentsSystem
Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2012.
Model-Driven Software Engineering in Practice (1st ed.)

41. VRIJE
UNIVERSITEIT
AMSTERDAM
Motivation
What is Model Engineering?
Model as the central artifact of software development
Model
Rapid prototyping
Static analysis
Code generation
Automated testing
Refactoring/
Transformation
Documentation
Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2012.
Model-Driven Software Engineering in Practice (1st ed.)

42. VRIJE
UNIVERSITEIT
AMSTERDAM
§Models as drafts
§ Communication of ideas and alternatives
§ Objective: modeling per se
§Models as guidelines
§ Design decisions are documented
§ Objective: instructions for implementation
§Models as programs
§ Applications are generated automatically
§ Objective: models are source code and vice versa
t
Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2012.
Model-Driven Software Engineering in Practice (1st ed.)
Uses of models

43. VRIJE
UNIVERSITEIT
AMSTERDAM
Modeling purposes
Descriptive models
(example: astronomy)
VS
Prescriptive models
(example: electrical engineering)
43

44. VRIJE
UNIVERSITEIT
AMSTERDAM
Descriptive VS prescriptive models
• A consumer may be a human, but also a software
• Consumer and intent influence the abstraction level of a
model
• The importance of a model may vary during its lifetime
44
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

45. VRIJE
UNIVERSITEIT
AMSTERDAM
Descriptive models
• Sketches and throw-away models
• to better understand the reality and to explore possible
solutions
• short life time
• Models of ideas and vision about the system to be developed
• to exploit the model for having feedback before
implementing the system
• Models extracted from a running system or source code
• for example, to visualize all the calls between a set of Java
classes
45
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

46. VRIJE
UNIVERSITEIT
AMSTERDAM
Prescriptive models
• The subject does not yet exist
• for example, models are used to generate the subject
• They guide the development of the system
• tipically more detailed than descriptive models
• put constraints on the system
• The most common consumers of prescriptive models are
code generators
• Prescriptive models are often used for development à their
importance might decade when the system is implemented
46
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

47. VRIJE
UNIVERSITEIT
AMSTERDAM
Software development process
47

48. VRIJE
UNIVERSITEIT
AMSTERDAM
Problem
If you need to develop a system with 10M LOCs…
• How many people do you need?
• How much time?
• How do they synchronize?
• How do you know that you are performing well?

49. VRIJE
UNIVERSITEIT
AMSTERDAM
Code & Fix: the naïve process model
• Write code
• Fix it to
• eliminate any errors that have been detected
• enhance existing functionality
• add new features
Source of difficulties and deficiencies
• impossible to predict
• impossible to manage

50. VRIJE
UNIVERSITEIT
AMSTERDAM
Software development
Chaotic and inefficient Orderly, predictable and
repeatable
. . . . . .
Slide by Cesar Augusto Nogueira, IBM
Without process Following a defined process

51. VRIJE
UNIVERSITEIT
AMSTERDAM
Software process
Attempt to organize the software life cycle by defining:
§ activities involved in software production
§ order of activities and their relationships
Goals of a software process
§ standardization
§ predictability
§ productivity
§ high product quality
§ ability to plan time and budget requirements

52. VRIJE
UNIVERSITEIT
AMSTERDAM
The goals of a development process
(B. Boehm 1988)
“… to determine the order of stages involved in software
development and evolution, and to establish the transition
criteria for progressing from one stage to the next.
Thus a process model addresses the following software
project questions:
What shall we do next?
How long shall we continue to do it?”

53. VRIJE
UNIVERSITEIT
AMSTERDAM
Main development activities
They must be performed independently of the used process
The process simply affects the flow among activities
Requirements engineering
Design
Implementation and testing
Evolution
You will cover these
activities in your project

54. VRIJE
UNIVERSITEIT
AMSTERDAM
Requirements engineering
Involves
§ eliciting
§ understanding
§ analyzing
§ specifying
Feasibility
study
Requirements
elicitation and
analysis
Requirements
specification
Requirements
validation
Feasibility
report
System
models
User and system
requirements
Requirements
document
Focus on
– what functionalities are needed
– NOT on how to realize them

55. VRIJE
UNIVERSITEIT
AMSTERDAM
The requirements specification document
• Specifies what are the main functionalities of the system
• For example:
• R1: the rovers shall never collide with each other
• R2: the rovers shall avoid obstacles autonomously
• Defines the qualities to be met
• For example:
• R3: each rover shall react to the presence of an obstacle within 10
milliseconds
• R4: the central station shall be secure with respect to malicious
attacks

56. VRIJE
UNIVERSITEIT
AMSTERDAM
Design
• The art of giving shape to a system via models
• drives the implementation
• helps in understanding the system
• Not a clear-cut, sequential process
• you get ideas, propose solutions
• you backtrack and retry when problems arise
Interface
design
Component
design
System
architecture
Database
specification
Interface
specification
Requirements
specification
Architectural
design
Component
specification
Platform
information
Data
description
Design inputs
Design activities
Design outputs
Database design

57. VRIJE
UNIVERSITEIT
AMSTERDAM
Implementation and testing
Involves the actual implementation of the system
Component testing
§ Individual components are tested independently
§ Components may be Java classes, methods or objects
System testing
§ Testing of the system as a whole
§ Testing of emergent properties is particularly important
• ex. overall performance of the system
Acceptance testing
§ Testing with customer data to check that the system
meets the customer’s needs

58. VRIJE
UNIVERSITEIT
AMSTERDAM
Evolution
Software is inherently flexible and can change
Fewer and fewer systems are completely new
à continuous evolution
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems

59. VRIJE
UNIVERSITEIT
AMSTERDAM
What you need to remember
Requirements engineering
create the software specification (what needs to be realized)
Design
requirements à detailed design of the system (descriptive
and/or prescriptive)
Implementation and testing
design à executable software
Software evolution
new requirements à the software must evolve to remain useful

60. VRIJE
UNIVERSITEIT
AMSTERDAM
The waterfall development process
• Exist in many variants
• all sharing sequential flow style
• It is document-driven
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

61. VRIJE
UNIVERSITEIT
AMSTERDAM
Critical evaluation of the waterfall model
+ sw process subject to discipline, planning, and management
à standard-oriented
+ postpone implementation to after understanding objectives
+ good documentation
– difficult to gather all requirements once and for all
– users may not know what they want
– rigid
– no feedback from the customer
– no parallelism, all phases are blocking
– a single delivery date (at the end!)

62. VRIJE
UNIVERSITEIT
AMSTERDAM
Issues of the waterfall model
Poor agility

63. VRIJE
UNIVERSITEIT
AMSTERDAM
Issues of the waterfall model
Poor quality

64. VRIJE
UNIVERSITEIT
AMSTERDAM
Issues of the waterfall model
High risk

65. VRIJE
UNIVERSITEIT
AMSTERDAM
Waterfall à agile

66. VRIJE
UNIVERSITEIT
AMSTERDAM
Agile principles
Agile methods are iterative development processes with:
frequent releases of the product
continuous interaction between dev. team and customer
reduce product documentation
continuous and systematic assessment of produced value and
risks

67. VRIJE
UNIVERSITEIT
AMSTERDAM
Agile in practice
You make a list You start executing
You estimate You update the plan
“@run-time”
You set priorities

68. VRIJE
UNIVERSITEIT
AMSTERDAM
Critical evaluation of the agile method
+ Acceptance of change à less risky
+ Frequent and short iterations
+ Emphasis on working code
+ Associating a test with every piece of functionality
+ tests are a key resource within the project
+ Continuous integration (and delivery)
+ Planned
– Tests as a replacement for specifications
– Feature-based development & ignorance of dependencies
– No quality plan
– Dismissal of a priori architecture work
– actually, dismissal of everything which is non-shippable

69. VRIJE
UNIVERSITEIT
AMSTERDAM
What this lecture means to you?
• Today software is complex and large
• Abstraction is key for complex systems
• Models are abstract representations of a system
• low-level details are safely ignored
• models can be used for many purposes
• documentation is the less interesting one
• descriptive VS prescriptive models
• No silver bullet for software development process
• waterfall VS agile
• models drive the development across the whole process
69

70. VRIJE
UNIVERSITEIT
AMSTERDAM
Readings
• UML@Classroom: An Introduction to Object-Oriented
Modeling” – chapter 1
70

71. VRIJE
UNIVERSITEIT
AMSTERDAM
Acknowledgement
Images for the house metaphor
• http://files1.caprionline.it/article/2710_Curzio_Malaparte/image/2_g.20091209221925.jpg
• http://www.caprilocationservice.com/includes/timthumb.php?src=http://www.caprilocationservice.
com/uploads/home/1514757ff0900e.jpg&w=750&h=450
• http://3.bp.blogspot.com/-
zuagz0DJOio/UMTbt5XihHI/AAAAAAAAAEI/6hQUB9d3IbI/s1600/Comparing+Elevations.png
• https://upload.wikimedia.org/wikipedia/commons/8/81/Consumer_Mains_Wiring.jpg
• http://1.bp.blogspot.com/_AQ4X1mJWGDE/TPXoyp52TdI/AAAAAAAAAAk/tm5_v27L3Tk/s1600/ca
saM+detail.jpg
• https://upload.wikimedia.org/wikipedia/commons/thumb/9/98/PSM_V33_D306_Plumbing_arrang
ement_in_a_19th_century_new_york_house.jpg/629px-
PSM_V33_D306_Plumbing_arrangement_in_a_19th_century_new_york_house.jpg
71