This presentation is about a lecture I gave within the "Software Design" 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 design (400170) – 2017/2018
Ivano Malavolta
i.malavolta@vu.nl

2. 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
• Louise Ivan
• livpayawal@gmail.com
• Gøran Hovde Strønstad
• goran.hovde@gmail.com
2
LAB teaching assistants
coordinator & lecturer
TOOL teaching assistants

3. VRIJE
UNIVERSITEIT
AMSTERDAM
Roles within the team
• Lecturer
• Prepare and give all lectures
• Keep the organization of the whole course
• Answer to questions related to lectures and project on Canvas
• Grading of ~5 teams
• LAB TAs
• Prepare and give labs (2 classrooms in parallel)
• Grading of ~5 teams each
• TOOL TAs
• 1-1 on-demand meetings with teams
• Answer to tool-related questions in Canvas
• Grading of ~15 teams
3

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
Recommended background knowledge
The course does not impose any specific prerequisites
The only requirement is a basic knowledge of Java
• to refresh your Java knowledge, follow this tutorial (until the
Java – Packages section):
• https://www.tutorialspoint.com/java
6

7. VRIJE
UNIVERSITEIT
AMSTERDAM
Quick test J
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
• e.g., source code generation
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
Lectures Labs
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 UML
WK 5 Behavioral models in UML
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
• ~60 minutes
• Demo performed “live”
• the source code of the demo will be available on Canvas
• ~15 minutes
• you can try out the demo 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 4-5 students
• each part of project can be started during the lab sessions
and finished at home
• 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 Canvas
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 if you will use more than
3 slip days
16

17. VRIJE
UNIVERSITEIT
AMSTERDAM
Course overall timeline
6 Feb
30 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
26 Mar
23 Feb
9 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 4-5 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 always 2 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 tool allows 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 (tool)
Eclipse Papyrus
https://eclipse.org/papyrus
22

23. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - implementation part
• You will implement a running system from the UML 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
23

24. 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/
24

25. VRIJE
UNIVERSITEIT
AMSTERDAM
Project - schedule and deliverables
• Deliverable 1 (25% of the final grade)
• MODELING: System informal description and system
requirements
• IMPLEMENTATION: Base version of the robotic system
working in the Simbad simulator
• Deadline: 23 February: 23:59
• Deliverable 2 (25% of the final grade)
• MODELING: Detailed design model
• IMPLEMENTATION: Base + usage of generated Java classes
• Deadline: 9 March: 23:59
• Deliverable 3 (50% of the final grade)
• MODELING: full design of the system
• IMPLEMENTATION: fully-working implementation
• Deadline: 30 March: 23:59
25

26. 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
26

27. 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
27

28. 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
28

29. VRIJE
UNIVERSITEIT
AMSTERDAM
Communication
• All course material is provided on Canvas
• Dedicated Q&A section on Canvas
• 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
29

30. VRIJE
UNIVERSITEIT
AMSTERDAM
What to do in case of issues/questions?
30
Ask on Canvas
1-1 on-demand
meeting with
TOOL TAs
Tool issue or
about
project?
Question
about
lecture
contents?
YES
NO
YES
(wide question
or case difficult
to replicate)
YES
(specific
question)
Prepare
replication
project
Start
NO
Come and talk to us
(break or end of
lecture/lab)
if everything
else fails...

31. VRIJE
UNIVERSITEIT
AMSTERDAM
First action!
• Form your team and enroll on Canvas (today)
• Tomorrow we will finalize the teams
• Setup the project tools
• Before next lab session
• Installation guides on Canvas 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: buildings 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 – abstraction - design
Model
a simplified or partial representation of reality, defined in order
to accomplish a task or to reach an agreement
Abstraction
the activity of generalizing — setting aside specific and
individual features
Software design
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
Modeling purposes
Descriptive models
(example: astronomy)
VS
Prescriptive models
(example: electrical engineering)
42

43. 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
43
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

44. 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
44
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

45. 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
45
Slide inspired by Patrizio Pelliccione’s lecture at GSSI

46. VRIJE
UNIVERSITEIT
AMSTERDAM
Software development process
46

47. 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?

48. VRIJE
UNIVERSITEIT
AMSTERDAM
Software development
Gather
Requirements
Design
System
Test
Unit
TestIm
plem
ent
Rework Correct
Mistakes
Review
CreatePrototype
ManageRisks
Integrate
Chaotic and inefficient Orderly, predictable and
repeatable
. . . . . .
Slide by Cesar Augusto Nogueira, IBM
Without process Following a defined process

49. 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?”

50. 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

51. 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

52. 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

53. 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

54. 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

55. 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

56. 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

57. 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

58. VRIJE
UNIVERSITEIT
AMSTERDAM
Critical evaluation of the waterfall model
+ precise 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!)

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

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

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

62. VRIJE
UNIVERSITEIT
AMSTERDAM
Waterfall à agile

63. 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

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

65. 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
+ Continuous integration (and delivery)
– 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

66. 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
66

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

68. 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
68