Modeling and abstraction, software development process [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
3 likes870 views
The document outlines the Software Design course at Vrije Universiteit Amsterdam, focusing on software abstraction, modeling, and development processes. It covers course structure, grading assessment, project deliverables, and the significance of UML modeling techniques. Additionally, it highlights the importance of teamwork, lab sessions, and attendance, along with providing resources for students to succeed.
![VRIJE
UNIVERSITEIT
AMSTERDAM
Textbook
• [Mandatory] Martina Seidl, Marion Scholz, Christian Huemer,
Gerti Kappel, "UML@Classroom: An Introduction to Object-
Oriented Modeling", 2015.
12](https://image.slidesharecdn.com/01intro-180206151252/85/Modeling-and-abstraction-software-development-process-Software-Design-Computer-Science-Vrije-Universiteit-Amsterdam-2017-2018-12-320.jpg)
![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](https://image.slidesharecdn.com/01intro-180206151252/85/Modeling-and-abstraction-software-development-process-Software-Design-Computer-Science-Vrije-Universiteit-Amsterdam-2017-2018-13-320.jpg)
Modeling and abstraction, software development process [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
- 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 [email protected]
- 2. VRIJE UNIVERSITEIT AMSTERDAM Who is who • Ivano Malavolta • [email protected] • Room T4.38 – Sciences building • Lars Cordewener • [email protected] • George Karlos • [email protected] • Louise Ivan • [email protected] • Gøran Hovde Strønstad • [email protected] 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
- 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
- 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 • [email protected] • 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
- 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
- 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