Modeling and abstraction, software development process [Software Modeling] [Computer Science] [Vrije...

Software and Services research group (S2)

Department of Computer Science, Faculty of SciencesVrije Universiteit Amsterdam

VRIJEUNIVERSITEITAMSTERDAM

Introduction to the course

Software modeling (401016) – 2016/2017

Ivano [email protected]


Hello

2

Software Architecture & Model-Driven Engineering

applied to

Autonomous dronesMobile applicationsWeb technologies

If you think good architecture is expensive, try bad architecture.

... Brian Foote and Joseph Yoder


Who is who

• Ivano Malavolta• [email protected]• Room T4.38 – Sciences building

• Lars Cordewener• [email protected]

• George Karlos• [email protected]

3

teaching assistants

coordinator & lecturer


Roadmap

• Introduction to the course• Software abstraction and modeling• Software development process

4


Introduction to the course

5


Quick test J

6


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


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


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


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


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


Textbook

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

12


Additional books

• [Optional] Russ Miles, Kim Hamilton, “Learning UML 2.0”,O’Reilly, 2006.

• [Mandatory, only selected chapters] Craig Larman, “ApplyingUML and Patterns: An Introduction to Object-OrientedAnalysis and Design and Iterative Development”, 3rd edition,Prentice Hall PTR, 2005.

13


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


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


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


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 examProject deliverable 3

30 Mar


Philosophical moment

18


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


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!


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


Project - modeling part (tools)

Eclipse Papyrus https://eclipse.org/papyrus

22


Project - modeling part (tools)

Yakindu Statechartshttps://www.itemis.com/en/yakindu/statechart-tools

23


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


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


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


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


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


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


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• [email protected]

• Meet and talk to us during the breaks J

30


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


Software abstraction and modeling

32


Where is software today?

33


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?


Abstraction

Engineers abstract away from a number of details that can

be ignored SAFELY

3560k lines of text

60k lines of code

Slide inspired by Mircea Lungu


A metaphor: building construction is model-driven

36


Let’s build some models of the house

37


Example for software: mobile app navigation

38


Models and abstraction

The human mind continuously re-works reality by applying cognitive processes

Modela simplified or partial representation of reality, defined in order to accomplish a task or to reach an agreement

Abstractionthe activity of finding the commonality in many different observations

Modelingthe 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.)


ModelsWhat 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 propertiesPragmatic Feature A model needs to be usable in place of an

original with respect to some purpose

ModelrepresentsSystem



MotivationWhat is Model Engineering?

Model as the central artifact of software development

ModelRapid prototyping

Static analysis

Code generation

Automated testing

Refactoring/Transformation

Documentation



§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


Uses of models


Modeling purposes

Descriptive models(example: astronomy)

VS Prescriptive models(example: electrical engineering)

43


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


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



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 arecode generators

• Prescriptive models are often used for development à their importance might decade when the system is implemented

46



Software development process

47


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?


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


Software development

Chaotic and inefficient Orderly, predictable and repeatable

. . . . . .

Slide by Cesar Augusto Nogueira, IBM

Without process Following a defined process


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


The goals of a development process(B. Boehm 1988)

“… to determine the order of stages involved in softwaredevelopment and evolution, and to establish the transitioncriteria for progressing from one stage to the next.Thus a process model addresses the following softwareproject questions:

What shall we do next?How long shall we continue to do it?”


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


Requirements engineering

Involves § eliciting§ understanding§ analyzing§ specifying

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Focus on– what functionalities are needed– NOT on how to realize them


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


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

Interfacedesign

Componentdesign

Systemarchitecture

Databasespecification

Interfacespecification

Requirementsspecification

Architecturaldesign

Componentspecification

Platforminformation

Datadescription

Design inputs

Design activities

Design outputs

Database design


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


Evolution

Software is inherently flexible and can change

Fewer and fewer systems are completely new à continuous evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems


What you need to remember

Requirements engineering create the software specification (what needs to be realized)

Designrequirements à detailed design of the system (descriptive and/or prescriptive)

Implementation and testingdesign à executable software

Software evolution new requirements à the software must evolve to remain useful


The waterfall development process

• Exist in many variants• all sharing sequential flow style

• It is document-driven

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


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!)


Issues of the waterfall model

Poor agility



Poor quality



High risk


Waterfall à agile


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


Agile in practice

You make a list You start executing

You estimate You update the plan “@run-time”

You set priorities


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


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


Readings

• UML@Classroom: An Introduction to Object-Oriented Modeling” – chapter 1

70


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

Modeling and abstraction, software development process [Software Modeling] [Computer Science] [Vrije...

Technology

Transcript of Modeling and abstraction, software development process [Software Modeling] [Computer Science] [Vrije...