modeling and abstraction, software development process [software modeling] [computer science] [vrije...
Post on 13-Apr-2017
895 Views
Preview:
TRANSCRIPT
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 Malavoltai.malavolta@vu.nl
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Roadmap
• Introduction to the course• Software abstraction and modeling• Software development process
4
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Textbook
• [Mandatory] Martina Seidl, Marion Scholz, Christian Huemer, Gerti Kappel, "UML@Classroom: An Introduction to Object-Oriented Modeling", 2015.
12
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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!
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Project - modeling part (tools)
Eclipse Papyrus https://eclipse.org/papyrus
22
VRIJEUNIVERSITEITAMSTERDAM
Project - modeling part (tools)
Yakindu Statechartshttps://www.itemis.com/en/yakindu/statechart-tools
23
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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?
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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.)
VRIJEUNIVERSITEITAMSTERDAM
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
Marco Brambilla, Jordi Cabot, and Manuel Wimmer. 2012.Model-Driven Software Engineering in Practice (1st ed.)
VRIJEUNIVERSITEITAMSTERDAM
MotivationWhat is Model Engineering?
Model as the central artifact of software development
ModelRapid 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.)
VRIJEUNIVERSITEITAMSTERDAM
§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
VRIJEUNIVERSITEITAMSTERDAM
Modeling purposes
Descriptive models(example: astronomy)
VS Prescriptive models(example: electrical engineering)
43
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
Slide inspired by Patrizio Pelliccione’s lecture at GSSI
VRIJEUNIVERSITEITAMSTERDAM
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?
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Software development
Chaotic and inefficient Orderly, predictable and repeatable
. . . . . .
Slide by Cesar Augusto Nogueira, IBM
Without process Following a defined process
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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?”
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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!)
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Agile in practice
You make a list You start executing
You estimate You update the plan “@run-time”
You set priorities
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
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
VRIJEUNIVERSITEITAMSTERDAM
Readings
• UML@Classroom: An Introduction to Object-Oriented Modeling” – chapter 1
70
VRIJEUNIVERSITEITAMSTERDAM
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
top related