diff --git a/README.md b/README.md index 92027b4..b43c4a9 100644 --- a/README.md +++ b/README.md @@ -84,12 +84,12 @@ Mitschriften und selbst angefertigte Unterlagen und Hilfen zu Informatik Vorlesu - [Schaltsysteme](Schaltsysteme.md) - Quellen/frei nach: [Dr.-Ing. Prof. h. c. Karsten Henke](https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-technische-informatik-und-ingenieurinformatik/fachgebiet-integrierte-kommunikationssysteme/team/karsten-henke) - [Softwareprojekt 2021](Softwareprojekt%202021.md) -- [Softwaretechnik](Softwaretechnik.md) +- Softwaretechnik 1 (Mitschrift temporär nicht verfügbar) - [Zusammenfassung](Softwaretechnik%20-%20Cheatsheet.pdf) - [Seminar](Softwaretechnik%20-%20Seminar.pdf) - [Beispiel Flowchart](Softwaretechnik%20Flowchart.tex) - Quellen/frei nach: [Prof. Dr.-Ing. habil. Armin Zimmermann](https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-technische-informatik-und-ingenieurinformatik/sse/team/prof-armin-zimmermann), [Dr.-Ing. Ralph Maschotta](https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-technische-informatik-und-ingenieurinformatik/sse/team/dr-ralph-maschotta) -- [Softwaretechnik 2](Softwaretechnik%202.md) +- Softwaretechnik 2 (Mitschrift temporär nicht verfügbar) - [Softwaretechnik 2 Cheatsheet](Softwaretechnik%202%20-%20Cheatsheet.pdf) - Quellen/frei nach: [Prof. Dr.-Ing. habil. Armin Zimmermann](https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-technische-informatik-und-ingenieurinformatik/sse/team/prof-armin-zimmermann), [Dr.-Ing. Ralph Maschotta](https://www.tu-ilmenau.de/universitaet/fakultaeten/fakultaet-informatik-und-automatisierung/profil/institute-und-fachgebiete/institut-fuer-technische-informatik-und-ingenieurinformatik/sse/team/dr-ralph-maschotta) - [Stochastik](Stochastik.md) diff --git a/Softwaretechnik 2.md b/Softwaretechnik 2.md deleted file mode 100644 index ab1a878..0000000 --- a/Softwaretechnik 2.md +++ /dev/null @@ -1,2561 +0,0 @@ -- Fachkompetenz: Die Studierenden verfügen über anwendungs-orientiertes Wissen zu Werkzeugen der Anforderungserhebung und -modellierung, der Prozessmodellierung und -anpassung, der Aufwandsschätzung, des Softwaretests, der Produktlinien-entwicklung und der Wartung von Software. -- Methodenkompetenz: Die Studierenden kennen den methodischen Hintergrund zu den vorgestellten Werkzeugen / Verfahren und sind daher in der Lage auch neue Problemstellungen zu lösen. Sie können aus den vorgestellten Methoden jeweils die passenden auswählen. -- Systemkompetenz: Die Studierenden können die vorgestellten Methoden und Werkzeuge in Projekten unterschiedlicher Domänen an-wenden. -- Sozialkompetenz: Die Studierenden kennen die Bedeutung und den Einfluss der erlernten Methoden und Werkzeuge innerhalb einen Firma. Sie können daher Ihr jeweiliges Vorgehen und dieErgebnisse auf die Erfordernisse eines Projektes in einer Organisation abstimmen. - -- [Motivation](#motivation) - - [Software Development Challenges](#software-development-challenges) -- [Software Development Processes](#software-development-processes) - - [Motivation](#motivation-1) - - [Software Processes](#software-processes) - - [Arten von Entwicklungsprozessen](#arten-von-entwicklungsprozessen) - - [Certification of Project Managers](#certification-of-project-managers) - - [PMP Example Question 1 (taken from the PMP website)](#pmp-example-question-1-taken-from-the-pmp-website) - - [PMP Example Question 2 (taken from the PMP website)](#pmp-example-question-2-taken-from-the-pmp-website) - - [PMP Example Questions 3 (taken from the PMP website)](#pmp-example-questions-3-taken-from-the-pmp-website) - - [OpenUP](#openup) - - [Core Principles](#core-principles) - - [Collaboration: Some key practices](#collaboration-some-key-practices) - - [Evolve: Some key practices](#evolve-some-key-practices) - - [Balance: Some key practices](#balance-some-key-practices) - - [Focus: Some key practices](#focus-some-key-practices) - - [OpenUP is Agile and Unified](#openup-is-agile-and-unified) - - [OpenUP Project Lifecycle](#openup-project-lifecycle) - - [OpenUP Iteration Lifecycle](#openup-iteration-lifecycle) - - [OpenUP Lifecycle - Inception Phase](#openup-lifecycle---inception-phase) - - [OpenUP Lifecycle - Elaboration Phase](#openup-lifecycle---elaboration-phase) - - [OpenUP Lifecycle - Construction Phase](#openup-lifecycle---construction-phase) - - [OpenUP Lifecycle - Transition Phase](#openup-lifecycle---transition-phase) - - [OpenUP Disciplines](#openup-disciplines) - - [Example: OpenUp](#example-openup) - - [The four Phases of OpenUP](#the-four-phases-of-openup) - - [SCRUM](#scrum) - - [Product Backlog](#product-backlog) - - [Sprint Backlog](#sprint-backlog) - - [Daily Scrum](#daily-scrum) - - [Where do changes come from?](#where-do-changes-come-from) - - [Example: Change Control Process](#example-change-control-process) - - [Impact Analysis Questionaire](#impact-analysis-questionaire) - - [Metamodelle](#metamodelle) - - [What is Model Driven Development?](#what-is-model-driven-development) - - [Meta-meta model ...](#meta-meta-model-) -- [Requirements Engineering](#requirements-engineering) - - [Definition: Requirements Engineering](#definition-requirements-engineering) - - [Definition: Requirement](#definition-requirement) - - [Requirement Types](#requirement-types) - - [Different Requirement Types](#different-requirement-types) - - [Struktur einer Anforderung](#struktur-einer-anforderung) - - [Anforderungsschablonen](#anforderungsschablonen) - - [Anforderungserhebung / Elicitation Techniques](#anforderungserhebung--elicitation-techniques) - - [Stakeholder Model](#stakeholder-model) - - [Elicitation Techniques](#elicitation-techniques) - - [Web-Search](#web-search) - - [Patentrecherche](#patentrecherche) - - [Interviews](#interviews) - - [MindMaps](#mindmaps) - - [Questionaire: ... ilities](#questionaire--ilities) - - [SEI Risk Taxonomy](#sei-risk-taxonomy) - - [Repertory Grid](#repertory-grid) - - [Repertory Grid: How to](#repertory-grid-how-to) - - [Repertory Grid: Analysis](#repertory-grid-analysis) - - [Goal Question Metric](#goal-question-metric) - - [Requirements Document Structure](#requirements-document-structure) -- [Software Estimation](#software-estimation) - - [A Little Estimation Game [McCo 2006]](#a-little-estimation-game-mcco-2006) - - [Ten Key Characteristics of Software Executives](#ten-key-characteristics-of-software-executives) - - [Estimation Improvement with the Capability Maturity Model](#estimation-improvement-with-the-capability-maturity-model) - - [Accuracy and Precision](#accuracy-and-precision) - - [Productivity Rates](#productivity-rates) - - [Randbedingungen, Fallstricke](#randbedingungen-fallstricke) - - [Over- / Underestimation](#over---underestimation) - - [Project Outcomes by Project Size](#project-outcomes-by-project-size) - - [Communication Paths](#communication-paths) - - [Communication Paths cont.](#communication-paths-cont) - - [The Cone of Uncertainty](#the-cone-of-uncertainty) - - [Accuracy vs. Project Length](#accuracy-vs-project-length) - - [Commonly Missing Activities](#commonly-missing-activities) - - [Einflussgröße: Personal](#einflussgröße-personal) - - [Einflussgröße: Programmiersprache](#einflussgröße-programmiersprache) - - [Estimation Techniques](#estimation-techniques) - - [Zählen](#zählen) - - [Historische Daten](#historische-daten) - - [Expert Judgement](#expert-judgement) - - [Proxy-Based Estimates](#proxy-based-estimates) - - [Function Points](#function-points) - - [Conversion of FP to LOC](#conversion-of-fp-to-loc) - - [Examples of Productivity](#examples-of-productivity) - - [Checklist for individual estimates](#checklist-for-individual-estimates) -- [Testen](#testen) - - [Motivation](#motivation-2) - - [Definition: Error](#definition-error) - - [Testprozess](#testprozess) - - [W-Model](#w-model) - - [Develop Requirements Test Cases](#develop-requirements-test-cases) - - [Plan System Test](#plan-system-test) - - [Plan Integration Test](#plan-integration-test) - - [Plan Unit Test](#plan-unit-test) - - [Test Implementation](#test-implementation) - - [MISRA](#misra) - - [Unit Testing](#unit-testing) - - [Check for Memory Leaks](#check-for-memory-leaks) - - [Invalid Pointers](#invalid-pointers) - - [Use Of Uninitialized Variables](#use-of-uninitialized-variables) - - [Unit Testing](#unit-testing-1) - - [Integration Testing](#integration-testing) - - [Time Measurement](#time-measurement) - - [System Testing](#system-testing) - - [System Testing](#system-testing-1) - - [Statistical Testing](#statistical-testing) - - [Acceptance Testing](#acceptance-testing) - - [Beispiel: Testen eines Softstarters](#beispiel-testen-eines-softstarters) - - [Development of Embedded Systems](#development-of-embedded-systems) - - [Conclusion](#conclusion) -- [Software Product Lines](#software-product-lines) - - [Beispiel: Cycling Computers ...](#beispiel-cycling-computers-) - - [History of Terms](#history-of-terms) - - [Currently available Software Product Lines](#currently-available-software-product-lines) - - [Product Line Development Cycle](#product-line-development-cycle) - - [The Concept of Variability](#the-concept-of-variability) - - [Modeling of Product Lines using Features](#modeling-of-product-lines-using-features) - - [Features](#features) - - [Feature Modeling: Example](#feature-modeling-example) - - [Example Tool: PureVariants](#example-tool-purevariants) - - [Example online-tool:](#example-online-tool) - - [Handling Variability](#handling-variability) - - [Design Time](#design-time) - - [Factory Pattern](#factory-pattern) - - [Factory Method](#factory-method) - - [Abstract Factory Pattern](#abstract-factory-pattern) - - [Decorator](#decorator) - - [Compile Time](#compile-time) - - [Variabiliy at Compile Time](#variabiliy-at-compile-time) - - [Startup Time](#startup-time) - - [Runtime](#runtime) - - [Aspect-Oriented Programming](#aspect-oriented-programming) - - [AOP / AspectJ](#aop--aspectj) - - [Example: _Authentication_](#example-authentication) - - [Domain Specific Languages](#domain-specific-languages) - - [Types of DSLs](#types-of-dsls) - - [Example: Test Case Generation](#example-test-case-generation) - - [Scanner](#scanner) -- [Software Maintenance](#software-maintenance) - - [Motivation](#motivation-3) - - [Reengineering](#reengineering) - - [Code Smells](#code-smells) - - [Code - Hard to read](#code---hard-to-read) - - [Metrics](#metrics) - - [The Law of Demeter](#the-law-of-demeter) - - [What is the simplest design?](#what-is-the-simplest-design) - - [Refactoring](#refactoring) - - [Refactoring Overview](#refactoring-overview) - - [Refactoring Howto](#refactoring-howto) - - [Composing Methods](#composing-methods) - - [Extract Method](#extract-method) - - [Inline Method](#inline-method) - - [Remove Assignments to Parameters](#remove-assignments-to-parameters) - - [Moving Features between Objects](#moving-features-between-objects) - - [Extract Class](#extract-class) - - [Organizing Data](#organizing-data) - - [Simplifying Conditional Expressions](#simplifying-conditional-expressions) - - [Making Method Calls Simpler](#making-method-calls-simpler) - - [Dealing with Generalization](#dealing-with-generalization) - - [Other Refactorings](#other-refactorings) - - [Long Living Software](#long-living-software) - - [Compiler Compiler](#compiler-compiler) - - [Long Living Systems](#long-living-systems) - -# Motivation -## Software Development Challenges -- Introduction of New Technologies -- Tool Chain -- Multi Domain Knowledge -- Certification -- Corporate Culture - -Automatisierung -- basiert auf Logik -- Deterministisch - -# Software Development Processes -## Motivation -- Warum sind Entwicklungsprozesse sinnvoll? -- Softwareentwicklungsrozesse erzeugen folgende Artefakte - - Dokumente, die jeweils einer bestimmten Struktur entsprechen! - - Requirements Dokument - - Architekturdokument (Bauplan) - - Projektplan - - Risiken - - Quellcode, der der Architektur entsprechen muss - - ... der das System implementiert - - ... der Testfälle - - ... des Installationsprogramms - - ... der Wartungssoftware (-> Extra Entwicklungsprojekt) - - Testfälle - -Why development processes? -- Development Processes are needed to know - - How do we develop systems? - - When to do what in a development team? -- Development Processes need to be _implemented_ per company and/or project - - Tailor the process! - - Establish the knowledge of the process in the development team - - Development Processes are a key competence for Project Managers - -## Software Processes -1. Background -2. OpenUP -3. SCRUM -4. Metamodels - - -### Arten von Entwicklungsprozessen -Phase-, Waterfall-, Loop-Models -![Buns2002](Assets/Softwaretechnik2-phasenmodell.png) - -Prototype-Models -![](Assets/Softwaretechnik2-prototypmodell.png) - -Incremental-, Evolutionary, Recursive-, Iterative-Models -![](Assets/Softwaretechnik2-evolutionsmodell.png) - -Spiral-Model -![Boeh 1988](Assets/Softwaretechnik2-Spiralmodell.png) - -### Certification of Project Managers -- Project Management Professional (PMP)® -- Industry-recognized certification [http://www.pmi.org](http://www.pmi.org) -- PMP Requirements - - "... three years of project management experience, with 4500 hours leading and directing projects and 35 hours of project management education." (Erfolgreich und/oder bezahlt?) - -PMP background -- Examination for Project Managers - - 200 multiple-choice questions in 4hrs -> 1min 12sec per question - - 2-3 weeks of preparation -- Paid renewal every three years - -#### PMP Example Question 1 (taken from the PMP website) -An accepted deadline for a project approaches. However, the project manager realizes only 75% percent of the work has been completed. The project manager then issues a change request. What should the change request authorize? -1. Additional resources using the contingency fund -2. Escalation approval to use contingency funding -3. Team overtime to meet schedule -4. Corrective action based on causes - -#### PMP Example Question 2 (taken from the PMP website) -The project manager develops a process improvement plan to encourage continuous process improvement during the life of the project. Which of the following is a valid tool or technique to assist the project manager to assure the success of the process improvement plan? -1. Change control system -2. Process analysis -3. Benchmarking -4. Configuration management system - -#### PMP Example Questions 3 (taken from the PMP website) -The project manager meets with the project team to review lessons learned from previous projects. In what activity is the team involved? -1. Performance management -2. Scope identification -3. Risk identification -4. Project team status meeting - - -## OpenUP -### Core Principles -(Made available under EPL v1.0) -OpenUP is based on a set of mutually supporting core principles: -- Collaborate to align interests and share understanding -- Evolve to continuously obtain feedback and improve -- Balance competing priorities to maximize stakeholder value -- Focus on articulating the architecture - -### Collaboration: Some key practices -- Maintain a common understanding - - Key artifacts: Vision, requirements, architecture notebook, iteration plan -- Foster a high-trust environment - - Manage by intent, tear down walls, understand the perspectives of others -- Share responsibility - - Everybody owns the product, help each other -- Learn continuously - - Develop technical and interpersonal skills, be a student and a teacher -- Organize around the architecture - - The architecture provides a shared understanding of the solution and forms the - basis for partitioning work. - -### Evolve: Some key practices -- Develop your project in iterations - - Use time-boxed iterations that deliver incremental value and provide frequent feedback. -- Focus iterations on meeting the next management milestone - - Divide the project into phases with clear goals and focus iterations on meeting those goals. - - Manage risks - - Identify and eliminate risk early. -- Embrace and manage change - - Adapt to changes. -- Measure progress objectively - - Deliver working software, get daily status, and use metrics. -- Continuously re-evaluate what you do - - Assess each iteration and perform process retrospectives. - -### Balance: Some key practices -- Know your audience & create a shared understanding of the domain. - - Identify stakeholders early and establish a common language -- Separate the problem from the solution - - Understand the problem before rushing into a solution. -- Use scenarios and use cases to capture requirements - - Capture requirements in a form that stakeholders understand -- Establish and maintain agreement on priorities - - Prioritize work to maximize value and minimize risk early -- Make trade-offs to maximize value - - Investigate alternative designs and re-factor to maximize value -- Manage scope - - Assess the impact of changes and set expectations accordingly. - -### Focus: Some key practices -- Create the architecture for what you know today - - Keep it as simple as possible and anticipate change -- Leverage the architecture as a collaborative tool - - A good architecture facilitates collaboration by communicating the "big-picture" and enabling parallelism in development. -- Cope with complexity by raising the level of abstraction - - Use models to raise the level of abstraction to focus on important high-level decisions. -- Organize the architecture into loosely coupled, highly cohesive components - - Design the system to maximize cohesion and minimize coupling to improve comprehension and increase flexibility. -- Reuse existing assets - - Don’t re-invent the wheel. Made available under EPL v1.0 - -### OpenUP is Agile and Unified -- OpenUP incorporates a number of agile practices... - - Test-First Design - - Continuous Integration - - Agile Estimation - - Daily Standup, Iteration Assessment, Iteration Retrospective - - Self-organizing teams -- ...within the context of an iterative, incremental lifecycle (UP). - -Core principles mapping to Agile manifesto - -| OpenUP/Basic Key principles | Agile manifesto | -| ---------------------------------------------------------- | --------------------------------------------------- | -| Collaborate to align interests and share understanding | Individuals and interactions over process and tools | -| Evolve to continuously obtain feedback and improve | Responding to change over following a plan | -| Balance competing priorities to maximize stakeholder value | Customer collaboration over contract negotiation | -| Focus on articulating the architecture | Working software over comprehensive documentation | - -Governance Model - Balancing Agility and Discipline -- OpenUP incorporates a three-tiered governance model to plan, execute, and monitor progress. -- These tiers correspond to personal, team and stakeholder concerns and each operates at a different time scale and level of detail. - -### OpenUP Project Lifecycle -- OpenUP uses an iterative, incremental lifecycle. -- Proper application of this lifecycle directly addresses the first core principle (Evolve). -- The lifecycle is divided into 4 phases, each with a particular purpose and milestone criteria to exit the phase: - - Inception: To understand the problem. - - Elaboration: To validate the solution architecture. - - Construction: To build and verify the solution in increments. - - Transition: To transition the solution to the operational environment and validate the solution. - -### OpenUP Iteration Lifecycle -- Phases are further decomposed into a number of iterations. -- At the end of each iteration a verified build of the system increment is available. -- Each iteration has its own lifecycle, beginning with planning and ending in a stable system increment, Iteration Review (did we achieve the iteration objectives) and a Retrospective (is there a better process). -- Progress on completion of micro-increments is monitored daily via "Scrums" and the iteration burndown chart to provide timely feedback. -![](Assets/Softwaretechnik2-openUp-lifecycle.png) - -Micro-Increments -- Micro-increments are small steps towards the goals of the iteration. -- Should be small enough to be completed in a day or two - - Identify Stakeholders is a micro-increment (one step of a task). - - Determine Technical Approach for Persistency is a micro-increment (a task with a specific - focus) - - Develop Solution Increment for UC 1 Main Flow is a micro-increment (a task with a - specific focus) -- Micro-increments are defined and tracked via the work items list. -- Work items reference requirements and process tasks as needed to provide - required inputs to complete the micro-increment. - -### OpenUP Lifecycle - Inception Phase -- The primary purpose of the Inception Phase is to understand the scope of the problem and feasibility of a solution. -- At the Lifecycle Objectives Milestone, progress towards meeting these objectives are assessed and a decision to proceed with the same scope, change the scope, or terminate the project is made. -- More specifically, the objectives and associated process activities are: - -| Phase objectives | Activities that address objectives | -| -------------------------------------------------------------------- | ------------------------------------------- | -| Define a Vision | Initiate Project | -| Identify key system functionality | Identify and Refine Requirements | -| Determine at least one possible solution | Agree on Technical Approach | -| Understand the cost, schedule, and risks associated with the project | Initiate Project, Plan and Manage Iteration | - -### OpenUP Lifecycle - Elaboration Phase -- The primary purpose of the Elaboration Phase is to validate the solution architecture (feasibility and trade-offs). -- At the Lifecycle Architecture Milestone, progress towards meeting these objectives are assessed and a decision to proceed with the same scope, change the scope, or terminate the project is made. -- More specifically, the objectives and associated process activities are: - -| Phase objectives | Activities that address objectives | -| -------------------------------------------------------------------------- | ------------------------------------------------------------------- | -| Get a more detailed understanding of the requirements | Identify and Refine Requirements | -| Design, implement, validate, and baseline an architecture | Develop the Architecture, Develop Solution Increment, Test Solution | -| Mitigate essential risks, and produce accurate schedule and cost estimates | Plan and Manage Iteration, Ongoing Tasks | - -### OpenUP Lifecycle - Construction Phase -- The primary purpose of the Construction Phase is to develop and verify the solution incrementally. -- At the Initial Operational Capability Milestone, progress towards meeting these objectives is assessed and a decision to deploy the solution to the operation environment is made. -- More specifically, the objectives and associated process activities are: - -| Phase objectives | Activities that address objectives | -| ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | -| Iteratively develop a complete product that is ready to transition to the user community | Identify and Refine Requirements; Develop Solution Increment; Test Solution | -| Minimize development costs and achieve some degree of parallelism | Plan and Manage Iteration Ongoing Tasks | - -### OpenUP Lifecycle - Transition Phase -- The primary purpose of the Transition Phase is to deploy the solution to the operational environment and validate it. -- At the Product Release Milestone, progress towards meeting these objectives are assessed and a decision to make the product generally available is made. -- More specifically, the objectives and associated process activities are: - -| Phase objectives | Activities that address objectives | -| ----------------------------------------------------------- | -------------------------------------------------------- | -| Beta test to validate that user expectations are met | Ongoing Tasks; Develop Solution Increment; Test Solution | -| Achieve stakeholder concurrence that deployment is complete | Plan and Manage Iteration; Test Solution | -| Improve future project performance through lessons learned | Plan and Manage Iteration | - -### OpenUP Disciplines -- A discipline is a collection of tasks that are related to a major "area of concern" within the overall project. -- Within the lifecycle, tasks are performed concurrently across several disciplines. -- Separating tasks into distinct disciplines is simply an effective way to organize content that makes comprehension easier. -- OpenUP defines the following Disciplines: - -### Example: OpenUp -![OpenUp Beispiel](Assets/Softwaretechnik2-openUp-beispiel.png) - -[http://www.eclipse.org/epf/general/An_Introduction_to_EPF.zip](http://www.eclipse.org/epf/general/An_Introduction_to_EPF.zip) - -### The four Phases of OpenUP -![Phasen](Assets/Softwaretechnik2-openUp-phasen.png) - -Decomposition of a Phase -![](Assets/Softwaretechnik2-openUp-lifecycle.png) - -1. Inception - - Glossary - - Vision - - Work Items List - - Project Plan - - Risk List - - Supporting Requirements Spec - - Use Case, Use Case Model - - Architecture Notebook - - Iteration Plan -2. Elaboration - - Architecture - - Design - - Developer Tests - - Build - - Implementation - - Test Log - - Test Scripts -3. Construction -4. Transition - - -Inhalte - -## SCRUM -Example: SCRUM -![](Assets/Softwaretechnik2-scrum.png) - -### Product Backlog -- Requirements -- Each item will be refined by the -> Sprint Backlog - -### Sprint Backlog -- Prioritized workitems -- 2-4 weeks -- Daily tracking of the progress (remaining work in days or h) - -Sprint Burndown Chart -![](Assets/Softwaretechnik2-Sprint%20Burndown%20Chart.png) - -### Daily Scrum -Short daily meeting -1. What did you do yesterday? -2. What will you do today? -3. Are there any impediments in your way? - -### Where do changes come from? -![Wieg 1999, p344](Assets/Softwaretechnik2-Veränderungen.png) - -## Example: Change Control Process -![](Assets/Softwaretechnik2-change-control-process.png) -Everyone needs to know about -- The owner of each document -- The access rights to each document -- The change procedure - -### Impact Analysis Questionaire -[Wieg 1999, p346] -- Do any existing requirements in the baseline conflict with the proposed change? -- Do any other pending requirements changes conflict with the proposed change? -- What are the business or technical consequences of not making the change? -- What are possible adverse side effects or other risks of making the proposed change? -- Will the proposed change adversely affect performance requirements or other quality attributes? -- Is the proposed change feasible within known technical constraints and current staff skills? -- Will the proposed change place unacceptable demand on any computer resources required for the development, test, or operating environments? -- Must any tools be acquired to implement and test the change? -- How will the proposed change affect the sequence, dependencies, effort, or duration of any tasks currently in the project plan? -- Will prototyping or other user input be required to verify the proposed change? -- How much effort that has already been invested in the project will be lost it this change is accepted? -- Will the proposed change cause an increase in product unit cost, such as by increasingg third-party product licensing fees? -- Will the change affect any marketing, manufacturing, training, or customer support plans? -- Identify any user interface changes, additions, or deletions required. -- Identify any changes, additions, or deletions required in reports, databases, or files. -- Identify the design components that must be created, modified, or deleted. -- Identify the source code files that must be created, modified, or deleted. -- Identify any changes required in build files or procedures. -- Identify existing unit, integration, system, and acceptance test cases that must be modified or deleted. -- Estimate the number of new unit, integration, system, and acceptance test cases that will be required. -- Identify any help screens, training materials, or other user documentation that must be created or modified. -- Identify any other applications, libraries, or hardware components affected by the change. -- Identify any third-party software that must be purchased or licensed. -- Identify any impact the proposed change will have on the project‘s software project management plan, quality assurance plan, configuration management plan, or other plans. [Wieg 1999], p346 - - -## Metamodelle -### What is Model Driven Development? -MDD proposes the usage of "models at different levels of abstraction and performs -transformations between them in order to derive a concrete application implementation " [1] - -Model -- Everything can be a representation of a model - - Source Code - - Word, Excel - - ... -- Conforms to a meta-model -- -> Manage complexity with a higher/smarter abstraction - -### Meta-meta model ... -- Object Management Group (OMG) -- Meta Object Facility (MOF) -- Commonly used 4 layer abstraction -- MDD tools are based on this structure! - -Meta Levels -- M3: z.B. MOF -- M2: z.B. UML Meta Model -- M1: z.B. UML Model -- M0: z.B. Source Code - - -# Requirements Engineering -## Definition: Requirements Engineering -![](Assets/Softwaretechnik2-Requirements%20Engineering.png) - -Definition ([Bere 2009] → [DoD 1991]): "Requirements engineering involves all lifecycle activities devoted to (1) identification of user requirements, (2) analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and (3) validation of the documented requirements against user needs, as well as (4) processes that support these activities." - -- Professionelles Requirements Engineering - - (1) Erheben Um was geht es? - - (2) Modellieren Analyse / Verfeinerung ... - - (3) Validieren Prüfen - - (4) Verwalten Nutzung / Wiederverwendung - -![](Assets/Softwaretechnik2-Requriements-Engineering-2.png) - -## Definition: Requirement -What is a requirement? "requirement", IEEE 610.12 - 1990, p62 -1. A condition or capability needed by a user to solve a problem or achieve an objective. -2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. -3. A documented representation of a condition or capability as in (1) or (2). - -See also: design requirement; functional requirement; implementation requirement; interface requirement; performance requirement; physical requirement. - -Requirement vs. Goal ( "a hot topic in the community"): -A goal is an objective the system under consideration should achieve. (intended properties of the system) [Lams 2001]. - -## Requirement Types -### Different Requirement Types -Requirements -- Functional - - Data - - Processes / Functions - - Behaviour -- Non-functional - - Process - - Shipment - - Implementation - - Standards - - Organisation - - Product - - Reliability - - Usability - - Efficiency - - Maintainability - - Protability - - Safety - - Performance - - Ergonomy - - External - - Law - - Economy - - Interoperability - - Cultural - - Physics - - IT Technology - - -## Struktur einer Anforderung -Strukturelemente - - Id - - Description - - Rationale - - Satisfaction - - Origin - - References - - Validation - -What a Requirement Looks Like -- Unique Requirements ID - - Mostly numbers or alphanumeric combinations are being used. - - Prevent redundancies -> automatic generation of this ID - - System-wide identification of a requirement / workitem -- Document Structure (-> Specification Document, -> Requirement Types) - - We need to know how to sort the requirements. Where to sort in a new requirement? Where to find requirements to a given topic? - - "Checklist" missing requirements / redundancies - - Wide / complete scope of the requirements document -- Relations - - ... to one/more use-case(s) - - ... to other requirements - - Use Interaction (one requirement refers to the implemented functionality of another requirement, e.g. Scrolling through a list of videos might make use of the immediate play-video functionality) - - Share Interaction (two requirements share the same resource, e.g. memory) - - ... to a component (off-the-shelf) of the system. (This is a relation to the system design) - - ... to a specific system variant (of a system family). - - Conflicts between requirements (should be resolved before the design phase) - - Conflicting requirements, side effects - - Analysis of the requirements, coverage metrics, automated traceability matrices -- Description - - A single sentence describing the requirement - - Textual frames / boiler plates [Rupp 2002], p229... - - UML (Activity, Sequence, Use-Cases, Statecharts), _legacy model types ??_ - - Without a description we don‘t understand a requirement - - Developers are forced to think about the requirement -- Rationale - - Why is this requirement important? - - Unneeded / unnecessary requirements have no rationale - - Reduction of the requirements specification to the essentially needed requirements -- Origin - - Who came up with this requirement? Where does it come from? - - Without a source there is no "personal" reason to have a requirement - - The origin is always the source for more information about the requirement -- Validation / Test-Case - - How could we quantify this requirement to test/validate it? - - Un-testable requirements have no means to be approved by the customer - - Project management (planning, scope, partitioning) is possible -- Customer Satisfaction - - What is the level of customer-interest in this requirement? How important is this requirement to the customer? - - What if this requirment won‘t be realized ...? - - Could also be seen as priority of this requirement (see Kano Model) - - I like it that way - - It must be that way - - I am neutral - - I can live with it that way - - I dislike it that whay - - Without the analysis of the customer satisfaction, the acceptance of the final result is unknown. - - Customer Satisfaction -- References - - To Domain-Knowledge or other information important to understand the requirement - - The learning curve for new employees or new stakeholders will be prolonged. - - Understanding of the system is sped up. - -### Anforderungsschablonen -für die Beschreibung von Anforderungen [Rupp 2002] -![](Assets/Softwaretechnik2-anforderungsschablone1.png) -![](Assets/Softwaretechnik2-anforderungsschablone2.png) -![](Assets/Softwaretechnik2-anforderungsschablone3.png) - -Kano Model -![](Assets/Softwaretechnik2-Kano-1.png) -![](Assets/Softwaretechnik2-Kano-2.png) - -## Anforderungserhebung / Elicitation Techniques -### Stakeholder Model -- Sponsor - - Customer - - Marketing - - Productdesign -- User - - Enduser - - Maintenance -- Contractor (Someone delivering something) -- Projectmanager -- Softwareengineer -- Qualityengineer -- Technical Writer - -### Elicitation Techniques -![](Assets/Softwaretechnik2-Elicitation%20Techniques.png) - -- Own Participation ... - - Internship - - Job-Rotation - - "Hospitanz" -- Ethnographic Observation - - Other cultures ... -- Introspection - - Explicitly try to think as a different individual (e. g. customers) - - ... change your ViewPoint [Rupp 2002], p111 -- Document Analysis - - Market Studies, Books, Papers - - Standards - - System Documentation, User Manuals (of competitors) - - Web-Search ... - - Patent Search -- Interviews (with/for statistical analysis) - - In person, Telco - - (Web-based) questionaire (e.g. Sharepoint) - - Structured / not structured - - Feedback round, [Rupp 2002], p120 - - Brainstorming - - MindMaps - - With domain experts, developers, ... -- Protocol Analysis - - Learn about business processes - - Input / Output of process steps (Observation) - - Apprenticing, Job-Rotation / "Hospitanz -- Knowledge Engineering ... - - Repertory Grid - - Goal Question Metric - -### Web-Search -Example: Literature Search - -| Name | Weblink | -| ----------------- | ------------------------------------------- | -| Web of Knowledge | http://www.webofknowledge.com/ | -| IEEE explore | http://ieeexplore.ieee.org | -| ACM | http://dl.acm.org/ | -| Scirus | http://www.scirus.com | -| DBLP | http://www.informatik.uni-trier.de/~ley/db/ | -| Citeseer(X) | http://citeseerx.ist.psu.edu | -| Google Scholar | http://scholar.google.de/ | -| Patentdatenbanken | http://worldwide.espacenet.com/ | - -### Patentrecherche -- Viele Informationen sind nur in Patenten verfügbar -- An anderer Stelle veröffentlicht <-> In Patenten veröffentlicht -- 80% finden sich nur in Patenten! -- Wo veröffentlichen um Geheimhaltung bemühte Wettbewerber ihre Forschungs- und Entwicklungsergebnisse? - -Lösungen aus Patentdokumenten... doch es bedarf gewisser Grundkenntnisse! -- Hüten Sie sich vor "naiven" Schlagwortsuchen wie ... "Feder" -> "Energiespeichermittel" -- Manchmal will der Anmelder einfach vermeiden, dass sein Patent gefunden wird ... - - "Spielzeugball" -> "Kugelförmiges Objekt mit biegsamen Fäden" - - "Kugellager" -> "Vielzahl von Kugeln" - -Lernen Sie, wie man nach Patenten sucht! -- http://www.epo.org/wbt/pi-tour -- http://www.epo.org/patents/learning/e-learning.html - - - -### Interviews -[Pohl 2008] -- Vorbereitung - - Ziel definieren/kommunizieren, Teilnehmer auswählen/einladen/kennenlernen, Ort wählen, Fragen vorbereiten, Domänensprache erlernen -- Durchführung - - Einleitung: Ziele und erwartete Ergebnisse, Einstiegsfrage - - Zusammenfassungen, Pausen, Protokoll -- Nachbereitung - - Protokoll, Anforderungen, To-Do-Liste - - ->Prüfung / Review - -#### MindMaps -- freemind.sourceforge.net -- MindManager (http://www.mindjet.com) -![](Assets/Softwaretechnik2-mindmap.png) - -#### Questionaire: ... ilities -- ISO 9126 -- ISO 25010 -- ISO 25051 -- ... - -#### SEI Risk Taxonomy - -### Repertory Grid -- Based on the _Personal Construct Theory_ by George Kelly, 1955 -- Repertory Grid - Auswahltabelle - - lat. Repertorium Bibliographie eines Fachbereiches, - - reperire = "wiederfinden" - - franz. Repertoire = Verzeichnis -- Interview technique: -> The interviewee creates his own interview! -- Goal: Understand someones ideas by similarities -- Elements: ... the items for the reasoning process -- Construct - - Single dimension of meaning for a person to identify two pheonomena as similar - - Two poles represent the extreme viewpoints (with a typical scale of 1 ... 5) - -#### Repertory Grid: How to -+ What is the question to be answered? -+ Elicit the elements -+ Elaborate the constructs - - By comparing triads -> How are two of these similar and the third one different? -+ Organize the elements and constructs in a table (-> grid) and rate (1...5) each element according to the constructs - -Example: "What is the best car brand for me?" -![](Assets/Softwaretechnik2-repertory-grid.png) - -#### Repertory Grid: Analysis -1. Best fit ... -2. What is closest to the optimum? -3. Clustering to refine the constructs - - -### Goal Question Metric -1. Robert E. Park, Wolfhart B Goethert, William A. Florac,"Goal-Driven Software Measurement - A Guidebook", SEI Bericht, CMZ/SEI-96-HB-002, 1996. -2. Danilo Assmann, Ralf Kalmar, Dr Teade Punter, "Handbuch, Messen und Bewerten von WebApplikationen mit der Goal/Question/Metric Methode", IESE-Report Nr. 087.02/D ver. 1.2, 2002 - -Motivation -- Messen und Bewerten von - - Softwareentwicklungsprozessen - - Produkten / Artefakten / Komponenten -- Ziel: Quantitative Aussagen - - In einem Projektkontext - - Für die beteiligten Personen - -GQM -- Zielorientiertes Messen - - Ziele sind organisations- / projektspezifisch - 1. Planung der Messung - 2. Instrumentierung - 3. Datenerfassung - 4. Datenanalyse mit Ergebnisbericht - -GQM Abstraction Sheet -![](Assets/Softwaretechnik2-GQM-abstraction-sheet1.png) -![](Assets/Softwaretechnik2-GQM-abstraction-sheet2.png) - -Elicitation Techniques -- Team Building - - Kick-Off - - Workshops - - Business Event Workshop (-> people/employees describe their work) - - Future Workshop - - Identify and group problems. Work in smaller teams on the groups. - - Find and describe visionary solutions to problems. Think without constraints. - - Estimate the needed resources and the feasibility for/of the proposed solutions. -- Focus Groups - - Sub-Teams for specific issues / topics - - - -### Requirements Document Structure -Document Structure -- Volere Schema -- Sections, Sub-Sections, ... -- Examples ... -- Requirements -- Design -- Use-Cases -- Relation of documents amongst each other? -- ... - -(Project) Document Setup -- Lastenheft -- Pflichtenheft -- System Tests -- Testresults -- Standards -![](Assets/Softwaretechnik2-project-document-setup.png) - -# Software Estimation -## A Little Estimation Game [McCo 2006] -Please read and observe the following directions carefully: -"For each question, fill in the upper and lower bounds that, in your opinion, give you a 90% chance of including the correct value. Be careful not to make your ranges either too wide or too narrow. Make them wide enough so that, in your best judgment, the ranges give you a 90% chance of including the correct answer. Please do not research any of the answers-this quiz is intended to assess your estimation skills, not your research skills. You must fill in an answer [or each item; an omitted item will be scored as an incorrect item. Please limit your time on this exercise to 10 minutes." - -| Low Estimate | Question | -| ------------ | ------------------------------------------------------ | -| | Surface temperature of the sun | -| | Latitude of Shanghai | -| | Area of the Asian continent | -| | The year of Alexander the Great‘s birth | -| | Total value of U.S. currency in circulation in 2004 | -| | Total volume of the Great Lakes | -| | Worldwide box office receipts for the movie _Titanic_ | -| | Total length of the coastline of the Pacific Ocean | -| | Number of book titles published in the U.S. since 1976 | -| | Heaviest blue whale ever recorded | - -Results: A Little Estimation Game -| Low Estimate | Question | -| --------------- | ------------------------------------------------------ | -| 6000 ºC | Surface temperature of the sun | -| 31º | North Latitude of Shanghai | -| 44.390.000 km^2 | Area of the Asian continent | -| 356 BC | The year of Alexander the Great‘s birth | -| $719.9 billion | Total value of U.S. currency in circulation in 2004 | -| 23000 km^3 | Total volume of the Great Lakes | -| 1,834 x 10^9 $ | Worldwide box office receipts for the movie Titanic | -| 135663 km | Total length of the coastline of the Pacific Ocean | -| 22 million | Number of book titles published in the U.S. since 1976 | -| 170 metric tons | Heaviest blue whale ever recorded | - --> Most people reach a 30% confidence level if they believe it is a 90% confidence level! - -#### Ten Key Characteristics of Software Executives -1. Executives will always ask for what they want. -2. Executives will always probe to get what they want if they don't get it initially. -3. Executives will tend to probe until they discover your point of discomfort. -4. Executives won't always know what's possible, but they will know what would be good for the business if it were possible. -5. Executives will be assertive. That's how they got to be executives in the first place. -6. Executives will respect you when you are being assertive. In fact, they assume you will be assertive if you need to be. -7. Executives want you to operate with the organization's best interests at heart. -8. Executives will want to explore lots of variations to maximize business _value._ -9. Executives know things about the business, the market, and the company that you don't know , and they may prioritize your project's goals differently than you would. -10. Executives will always want visibility and commitment early (which would indeed _have_ great business _value,_ if it were possible). [McCo 2006], p260 - -### Estimation Improvement with the Capability Maturity Model -![](Assets/Softwaretechnik2-CapabilityMaturityModel.png) - -Improvement in estimation at the Boeing Company. As with the U.S. Air Force projects, the predictability of the projects improved dramatically at higher CMM levels. [McCo 2006, p10] - - -## Accuracy and Precision -![](Assets/Softwaretechnik2-Accuracy-and-Precision.png) - -## Productivity Rates -![McCo 2006, 62](Assets/Softwaretechnik2-Productivity-Rates.png) - -## Randbedingungen, Fallstricke -##### Over- / Underestimation -- Cyril Northcote Parkinson, 1955 in _The Economist_ - - "Work expands so as to fill the time available for its completion. " -- -> Parkinson's Law -- Developers have a tendency to: Best Case Estimates - -##### Project Outcomes by Project Size -| Size in Function Points (and Approximate Lines of Code) | Early | On Time | Late | Failed (Canceled) | -| ------------------------------------------------------- | ----- | ------- | ---- | ----------------- | -| 10 FP (1,000 LOC) | 11% | 81% | 6% | 2% | -| 100 FP (10,000 LOC) | 6% | 75% | 12% | 7% | -| 1,000 FP (100,000 LOC) | 1% | 61% | 18% | 20% | -| 10,000 FP (1,000,000 LOC) | <1% | 28% | 24% | 48% | -| 100,000 FP (10,000,000 LOC) | 0% | 14% | 21% | 65% | - -[McCo 2006], p25, Source: Estimating Software Costs (Jones 1998). - - -##### Communication Paths -| Paths (P) | 0 | 1 | 3 | 6 | ... | 15 | -| --------- | --- | --- | --- | --- | --- | --- | -| Nodes (n) | 1 | 2 | 3 | 4 | ... | 6 | - -$$P=\sum_{i=1}^{n-1} i=\frac{(n-1)*((n-1)+1)}{2}=\frac{2*(n-1)}{2}$$ -Gaußsche Summenformel: $\sum_{i=1}^n = 1+2+3+...+n=\frac{n(n+1)}{2}$ - -##### Communication Paths cont. -![](Assets/Softwaretechnik2-Communicationpath-1.png) -![](Assets/Softwaretechnik2-Communicationpath-2.png) - - -### The Cone of Uncertainty -![McCo 2006, p36](Assets/Softwaretechnik2-Cone-of-Uncertainty.png) - -##### Accuracy vs. Project Length -![McCo 2006, p26](Assets/Softwaretechnik2-Estimationresults.png) -Estimation results from one organization. - -### Commonly Missing Activities -- Functional Requirement Areas - - Setup/installation program - - Data conversion utility - - Glue code needed to use third-party or open-source software - - Help system - - Deployment modes - - Interfaces with external systems -- Non-Functional Requirements - - ...ilities -- SW Development Activities - - Ramp-up time for new team members - - Mentoring of new team members - - Management coordination/manager meetings - - Cutover/deployment - - Data conversion (own development) - - Installation - - Customization - - Requirements clarifications - - Maintaining the revision control system - - Supporting the build - - Maintaining the scripts required to run the daily build - - Maintaining the automated smoke test used in conjunction with the daily build - - Installation of test builds at user location(s) - - Creation of test data - - Management of beta test program - - Participation in technical reviews - - Integration work - - Processing change requests - - Attendance at change-control/triage meetings - - Coordinating with subcontractors - -### Einflussgröße: Personal -![McCo 2006, p63](Assets/Softwaretechnik2-Einflussgröße-Personal.png) - -### Einflussgröße: Programmiersprache -![McCo 2006, p64/65](Assets/Softwaretechnik2-Einflussgröße-Programmiersprache.png) - -Ratio of High-Level-Language Statements to Equivalent C Code - -Source: Adapted from Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000). - -## Estimation Techniques -### Zählen -Which quantities to count? [McCo 2006, p86..88] - -| Quantity to Count | Historical Data Needed to Convert the Count to an Estimate | -| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Marketing requirements | Average effort hours per requirement for development | -| | Average effort hours per requirement for independent testing | -| | Average effort hours per requirement for documentation | -| | Average effort hours per requirement to create engineering requirements from marketing requirements | -| Features | Average effort hours per feature for development and/or testing | -| Use cases | Average total effort hours per use case | -| | Average number of use cases that can be delivered in a particular amount of calendar time | -| Stories | Average total effort hours per story | -| | Average number of stories that can be delivered in a particular amount of calendar time | -| Engineering Requirements | Average number of engineering requirements that can be formally inspected per hour | -| | Average effort hours per requirement for development/test/documentation | -| Function Points | Average development/test/documentation effort per Function Point | -| | Average lines of code in the target language per Function Point | -| Change requests | Average development/test/documentation effort per change request (depending on variability of the change requests, the data might be decomposed into average effort per small, medium, and large change request) | -| Web pages | Average effort per Web page for user interface work | -| | Average whole-project effort per Web page (less reliable, but can be an interesting data point) | -| Reports | Average effort per report for report work | -| Dialog Boxes | Average effort per dialog for user interface work | -| Database Tables | Average effort per table for database work | -| | Average whole-project effort per table (less reliable, but can be an interesting data point) | -| Classes | Average effort hours per class for development | -| | Average effort hours to formally inspect a class | -| | Average effort hours per class for testing | -| Defects found | Average effort hours per defect to fix | -| | Average effort hours per defect to regression test | -| | Average number of defects that can be corrected in a particular amount of calendar time | -| Configurations settings | Average effort per configuration setting | -| Lines of code already written | Average number of defects per line of code | -| | Average lines of code that can be formally inspected per hour | -| | Average new lines of code from one release to the next | - -### Historische Daten -- The organization‘s historical data - - Not personalized! -- Check: working days ≠ calendar days! -- Calibrate by building own charts -- Use _recent_ data of your project to refine estimations - -### Expert Judgement -- Ask people who will do the work -- $ExpectedCase = \frac{BestCase+(4*MostLikelyCase)+WorstCase}{6}$ - -![McCo 2006, p109](Assets/Softwaretechnik2-Expert-Judgement.png) - -De- / Recomposition -- Divide and Conquer - ![McCo 2006, p116](Assets/Softwaretechnik2-Divide-and-Conquer.png) -- Example - ![McCo 2006, p120](Assets/Softwaretechnik2-Decomposition-example.png) - - -Expert Judgement in Groups [McCo 2006, p151] -1. The Delphi coordinator presents each estimator with the specification and an estimation form. -2. Estimators prepare initial estimates individually. (Optionally, this step can be performed after step 3.) -3. The coordinator calls a group meeting in which the estimators discuss estimation issues related to the project at hand. If the group agrees on a single estimate without much discussion, the coordinator assigns someone to play devil's advocate. -4. Estimators give their individual estimates to the coordinator anonymously. -5. The coordinator prepares a summary of the estimates on an iteration form and presents the iteration form to the estimators so that they can see how their estimates compare with other estimators' estimates. -6. The coordinator has estimators meet to discuss variations in their estimates. -7. Estimators vote anonymously on whether they want to accept the average estimate. If any of the estimators votes "no," they return to step 3. -8. The final estimate is the single-point estimate stemming from the Delphi exercise. Or, the final estimate is the range created through the Delphi discussion and the single-point Delphi estimate is the expected case. - -### Proxy-Based Estimates -Classify existing components/features ... (small, medium, large) ... and estimate new features by these classes -[McCo 2006, p138] - -| Example | Size | Average Staff Days per Feature | Number of Features | Estimated Effort (Staff Days) | -| -------------- | ---------- | ------------------------------ | ------------------ | ----------------------------- | -| Temp | Very Small | 48 | 6 | 288 | -| Speed | Small | 53 | 20 | 1060 | -| Daytrip | Medium | 60 | 4 | 240 | -| Heartbeat Zone | Large | 66 | 5 | 330 | -| Navigation | Very Large | 107 | 3 | 321 | -| Total | | - | 38 | 2239 | - -### Function Points -- Developed by Allan Albrecht, IBM, 1970 -- Assess each functional requirement -![Balz 1996](Assets/Softwaretechnik2-Function-Points.png) - - | Category | Criterion | Simple | Middle | Complex | - | -------------- | ----------------------------------------------------------------------------------------------------------------- | ------ | ------------------ | ------------------------------ | - | Input | Number of different data Elements | 1-5 | 6-10 | >10 | - | | Validate Input | Formal | Formal & logically | Formal & logically & DB-access | - | | Required complexity of the user interface | low | average | high | - | Queries | Number of different keys | 1 | 2 | >2 | - | | Required complexity of the user interface | low | average | high | - | Output | Number of colums | 1-6 | 7-15 | >15 | - | | different data elements | 1-5 | 6-10 | >10 | - | | Change of output groups (e.g. three data items to be printed but in two different groups -> grouped GUI elements) | 1 | 2-3 | >3 | - | | Preparation for printing data elements | none | some | many | - | Database | Number of Keys | 1 | 2 | >2 | - | | Different data elements | 1-20 | 21-40 | >40 | - | | Use existing data? (can be re-used) | yes | - | no | - | | Change of an already implemented data(structure) | no | yes | - | - | Reference Data | Read-only-files: Number of different data elements | 1-5 | 6-10 | >10 | - | | Read-only-files: Number of keys | 1 | 2 | >2 | - | | Tables: Number of different data elements | 1-5 | 6-10 | >10 | - | | Tables: Dimensions | 1 | 2 | 3 | - -| Category | Classification | Weight | -| -------------- | -------------- | ------ | -| Input | simple | 3 | -| | middle | 4 | -| | complex | 6 | -| Queries | simple | 3 | -| | middle | 4 | -| | complex | 6 | -| Output | simple | 3 | -| | middle | 5 | -| | complex | 7 | -| Database | simple | 3 | -| | middle | 10 | -| | complex | 15 | -| Reference Data | simple | 3 | -| | middle | 7 | -| | complex | 10 | - -![](Assets/Softwaretechnik2-Function-Points2.png) - -##### Conversion of FP to LOC -![McCo 2006](Assets/Softwaretechnik2-FP-to-LOC.png) - -##### Examples of Productivity -| Product | New Lines of Code Equivalent | Staff Years | Year Built | Approx. Cost in 2006 Dollars | $/LOC | LOC/Staff Year | -| --------------------------------- | ---------------------------- | ----------- | ---------- | ---------------------------- | ----- | -------------- | -| IBM Chief Programmer Team Project | 83,000 | 9 | 1968 | 1,400,000* | $17 | 9,200 | -| Lincoln Continental | 83,000 | 35 | 1989 | 2,900,000 | $35 | 2,400 | -| IBM Checkout Scanner | 90,000 | 58 | 1989 | 4,900,000 | $55 | 1,600 | -| Microsoft Word for Windows 1.0 | 249,000 | 55 | 1989 | 8,500,000* | $34 | 4,500 | -| NASA SEL Project | 249,000 | 24 | 2002 | 3,700,000* | $15 | 10,000 | -| Lotus 123 v. 3 | 400,000 | 263 | 1989 | 36,000,000 | $90 | 1,500 | -| Microsoft Excel 3.0 | 649,000 | 50* | 1990 | 7,700,000 | $12 | 13,000 | -| Citibank Teller Machine | 780,000 | 150 | 1989 | 22,000,000 | $28 | 5,200 | -| Windows NT 3.1 (first version) | 2,880,000 | 2,000* | 1994 | 200,000,000 | $70 | 1,400 | -| Space Shuttle | 25,600,000 | 22,096 | 1989 | 2,000,000,000 | $77 | 1,200 | - -*Estimated - -Sources: "Chief Programmer Team Management of Production Programming" (Baker 1972), -"Microsoft Corporation: Office Business Unit" (iansiti 1994), "How to Break the Software -Logjam" (Schlender 1989), "Software Engineering Laboratory (SEL) Relationships, Models, -and Management Rules" (NASA, 1991), Microsoft Secrets (Cusumano and Selby 1995). - - -### Checklist for individual estimates -1. Is what's being estimated clearly defined? -2. Does the estimate include all the kinds of work needed to complete the task? -3. Does the estimate include all the functionality areas needed to complete the task? -4. Is the estimate broken down into enough detail to expose hidden work? -5. Did you look at documented facts (written notes) from past work rather than estimating purely from memory? -6. Is the estimate approved by the person who will actually do the work? -7. Is the productivity assumed in the estimate similar to what has been achieved on similar assignments? -8. Does the estimate include a Best Case, Worst Case, and Most Likely Case? -9. Is the Worst Case really the worst case? Does it need to be made even worse? -10. Is the Expected Case computed appropriately from the other cases? -11. Have the assumptions in the estimate been documented? -12. Has the situation changed since the estimate was prepared? -[McCo 2006, p110] - -# Testen -## Motivation -Software Testing -- Operate/use a system with a set of known inputs and/or a set of (environmental) conditions -- Observe the reaction of the system and compare against the expected reaction -- -> Test against the requirements -- Measure the quality of a System -- Keep the quality of a system - - While changing the system (-> maintenance) - - Regression Testing - -Reference: ISTQB® Glossary of Testing Terms v2.2 (ANSI/IEEE 610.12-1990) - -## Definition: Error -- Difference between _actual_ and _desired_ behavior (Istverhalten <-> Sollverhalten) - -- Failure: Deviation of the component or system from its expected delivery, service or result. -- Fehlerwirkung: Abweichung einer Komponente/eines Systems von der erwarteten (Daten)Übergabe, Leistung oder dem Ergebnis. (auch: äußerer Fehler, Ausfall) -- Fault -> Defect: A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system. -- Fehlerzustand: Defekt (innerer Fehlerzustand) in einer Komponente oder einem System, der eine geforderte Funktion des Produkts beeinträchtigen kann, z.B. inkorrekte Anweisung oder Datendefinition. Ein Fehlerzustand, der zur Laufzeit angetroffen wird, kann eine Fehlerwirkung einer Komponente oder Systems verursachen. (auch: innerer Fehler) - -## Testprozess -![Spil 2012, 21](Assets/Softwaretechnik2-Testprozess.png) - -![Testklassifikation, Hoff 2008](Assets/Softwaretechnik2-Testklassifikation.png) - -Initial V-Model -![](Assets/Softwaretechnik2-V-model.png) - -## W-Model -![](Assets/Softwaretechnik2-W-model.png) - -Testing Overview mit W-Model z.B. mit SCRUM: jeder Release eine W-model Phase - -### Develop Requirements Test Cases -- Tasks - - Develop Test Case(s) for each requirement - - Setup a _test plan_ , e. g., IEEE 829 -- Check - - Requirements <--> Test Cases -- Review - - Execution Environment - - Test SW (Tessy, LDRA,...), Web-Servers, CAN-Bus / Fieldbus, USB, Scope, ... - - Feasibility - - Do all test cases make sense? - - Requirements tested completely? - - -Test Software: Example, _Tessy_ -![http://www.hitex.com](Assets/Softwaretechnik2-Test-software-example.png) - -Classification Trees -![Matthias Grochtmann, "Test Case Design Using Classification Trees", 1994; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.83.9731](Assets/Softwaretechnik2-Classification-Trees.png) - -### Plan System Test -- Task - - Refine Requirements / Test Cases - - Develop Test Model(s) -- Check - - Requirements refined? - - Test Cases refined? -- Review - - Refinement ok / feasible? - - Completeness? - - Test Case Execution - - Possible? - - Manual / automated execution? - - Estimation of test case execution time - - -Test Plan (IEEE829) [https://cabig.nci.nih.gov/archive/CTMS/Templates] -1. INTRODUCTION - 1. SCOPE - 2. QUALITY OBJECTIVE - 3. ROLES AND RESPONSIBILITIES - 4. ASSUMPTIONS FOR TEST EXECUTION - 5. CONSTRAINTS FOR TEST EXECUTION - 6. DEFINITIONS -2. TEST METHODOLOGY - 1. PURPOSE - 2. TEST LEVELS - 3. BUG REGRESSION - 4. BUG TRIAGE - 5. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS - 6. TEST COMPLETENESS -3. TEST DELIVERABLES - 1. DELIVERABLES MATRIX - 2. DOCUMENTS - 3. DEFECT TRACKING & DEBUGGING - 4. REPORTS - 5. RESPONSIBILITY MATRIX -4. RESOURCE & ENVIRONMENT NEEDS - 1. TESTING TOOLS - 2. TEST ENVIRONMENT - 3. BUG SEVERITY AND PRIORITY DEFINITION - 4. BUG REPORTING -5. TERMS/ACRONYMS - -Example: Testmodell (Statechart) -![](Assets/Softwaretechnik2-Testmodell-statechart.png) - -Behavioral Test Model -![](Assets/Softwaretechnik2-Behavioral-test-model.png) - -### Plan Integration Test -- Task - - Refine Test Model(s) -- Check - - Traces - Requirements <--> Design Elements - - Test Cases refined -- Review - - Test Case Refinement feasible? - - Completeness of Interface Test Cases - - Communication protocols (USB, - fieldbus, SCSI, ...) - - Component interfaces, plug-in APIs - -### Plan Unit Test -- Check - - Traces - Design Element <--> Code - thus, Test Cases <--> Code - - Unit Tests refined (for each function) -- Review - - Unit Tests complete? - - -### Test Implementation -- Check - - Coding style - - Static Analysis - - Metrics, LOC, Cohesion, McCabe ... - - e. g., SPLINT: Null-Pointer - dereferencing, storage, information - hiding, ... -- Review - - Implementation of Test Cases / Test Steps - (-> Test Scripts) - - -Splint: Null pointer dereferencing -![http://www.splint.org/, Splint Manual, page 14](Assets/Softwaretechnik2-splint-null-pointer.png) - -Splint: Variable Usage -![http://www.splint.org/, Splint Manual, page 18](Assets/Softwaretechnik2-splint-variable.png) - -Splint: Information Hiding -![http://www.splint.org/, Splint Manual, page 22](Assets/Softwaretechnik2-splint-information.png) - -Example: [PC-LINT](http://www.gimpel.com/html/lintchks.htm) -- Order of initialization dependencies -- Pointer members not deleted by destructors -- Missing destructors from classes using dynamic allocation -- Creation of temporaries -- Operator delete not checking argument for NULL -- Conflicting function specifiers -- ... -- -> Could also check MISRA rules - -##### MISRA -[Motor Industry Software Reliability Association](http://www.misra.org.uk) -- Conform to ISO 9899 standard (C-Language) -- Multibyte characters and wide string literals shall not be used -- Sections of code should not be commented out -- In an enumerator list the = construct shall not be used to explicitly initialise members other than the first unless it is used to initialise all items -- Bitwise operations shall not be performed on signed integer types -- The _goto_ statement shall not be used -- The _continue_ statement shall not be used -- The _break_ statement shall not be used, except to terminate the cases of a _switch_ statement -- .... - - -### Unit Testing -- Single functions / methods - - ~30min pro Comp.Point (McCabe) - - Priorisierung - - Nach McCabe - - Benutzungshäufigkeit - - Kritikalität -- Equivalence class testing -- Pre- / Post-conditions, Invariants -- "White-Box" testing -- Timing on a fine granularity level (-> functions) - - -Equivalence Class Testing -- A function F has a number of variables - - `void setdate(int day, int month, int year)` -- The variables have the following boundaries and intervalls - ```cpp - 1 ≤ day ≤ 31, for month in (1,3,5,7,8,10,12) - 1 ≤ day ≤ 30, for month in (4,6,9,11) - 1 ≤ day ≤ 28, for month=2 && year%4!=0 - 1 ≤ day ≤ 29, for month=2 && year%4==0 - 1 ≤ month ≤ 12 - -1000 ≤ year ≤ 3000 - ``` - -Equivalence Class Testing -![](Assets/Softwaretechnik2-Equivalence-Class-Testing.png) - -Document Pre-/Postconditions -- E.g. with doxygen - - \pre Pre-condition - - \post Post-condition - - \invariant Invariant - - \test Test Case - - \todo todo‘s left ... - -![](Assets/Softwaretechnik2-doxygen1.png) -![](Assets/Softwaretechnik2-doxygen2.png) -![](Assets/Softwaretechnik2-doxygen3.png) - -##### Check for Memory Leaks -![Windows / Visual Studio](Assets/Softwaretechnik2-memory-leaks.png) - -Check for Memory Leaks -![Linux / Valgrind http://valgrind.org/](Assets/Softwaretechnik2-memory-leaks2.png) - -[Memory Leak](http://www.cprogramming.com/debugging/valgrind.html) -```cpp -#include -int main() -{ - char *x = malloc(100); // or, in C++, - //"char *x = new char[100] - return 0; -} -``` -- ==2330== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1 -- ==2330== at 0x1B900DD0: malloc (vg_replace_malloc.c:a131) -- ==2330== by 0x804840F: main (example1.c:5) - -##### Invalid Pointers -(http://www.cprogramming.com/debugging/valgrind.html) -```cpp -#include - -int main() -{ - char *x = malloc(10); - x[10] = 'a'; - return 0; -} -``` -- ==9814== Invalid write of size 1} -- ==9814== at 0x804841E: main (example2.c:6) -- ==9814== Address 0x1BA3607A is 0 bytes after a block of size 10 alloc'd -- ==9814== at 0x1B900DD0: malloc (vg_replace_malloc.c:131) -- ==9814== by 0x804840F: main (example2.c:5) - -No Bounds Checking! - -##### Use Of Uninitialized Variables -(http://www.cprogramming.com/debugging/valgrind.html) -```cpp -#include -int main() -{ - int x; - if(x == 0) - { - printf("X is zero"); - } - return 0; -``` -- ==17943== Conditional jump or move depends on uninitialised value(s)} -- ==17943== at 0x804840A: main (example3.c:6) - -##### Unit Testing -- A TestCase holds the code of what to test - - ... with the _runTest_ method - - _TestFixture_ ( _TestCase_ + setUP / tearDown methods) - - _RepeatedTest_ -> Test + times to repeat ... -- A TestSuite contains many single Tests - - ... _run()_ all Tests -- A TestListener is implemented as observer pattern to follow the testing progress -- The TestRunner manages the lifecycle of all tests added - -Unit Testing: embUnit ... -![](Assets/Softwaretechnik2-embUnit.png) - -Example: _counter_ -```cpp -typedef struct __Counter Counter; -typedef struct __Counter* CounterRef; - -struct __Counter { - int value; -}; - -CounterRef Counter_alloc(void); -void Counter_dealloc(CounterRef); -CounterRef Counter_init(CounterRef); -CounterRef Counter_counter(void); -int Counter_value(CounterRef); -void Counter_setValue(CounterRef,int); -int Counter_inc(CounterRef); -int Counter_dec(CounterRef); -void Counter_clr(CounterRef); - -CounterRef Counter_alloc(void){ - return (CounterRef)malloc(sizeof(Counter)); -} - -CounterRef Counter_init(CounterRef self){ - self->value = 0; - return self; -} - -CounterRef Counter_counter(void){ - return Counter_init(Counter_alloc()); -} - -int Counter_inc(CounterRef self){ - self->value++; - return self->value; -} - -int Counter_dec(CounterRef self){ - self->value--; - return self->value; -} -``` - -Example: _testcounter.c -```cpp -#include -#include "counter.h" -#include "stdio.h" - -CounterRef counterRef; - -static void setUp(void){ - counterRef = Counter_counter(); -} - -static void tearDown(void){ - Counter_dealloc(counterRef); -} - -static void testSetValue(void){ - Counter_setValue(counterRef,1); - TEST_ASSERT_EQUAL_INT(1, Counter_value(counterRef)); - - Counter_setValue(counterRef,-1); - TEST_ASSERT_EQUAL_INT(-1, Counter_value(counterRef)); -} - -static void testInc(void){ - Counter_inc(counterRef); - TEST_ASSERT_EQUAL_INT(1, Counter_value(counterRef)); - - Counter_inc(counterRef); - TEST_ASSERT_EQUAL_INT(2, Counter_value(counterRef)); -} - -TestRef CounterTest_tests(void){ - EMB_UNIT_TESTFIXTURES(fixtures) { - new_TestFixture("testInit",testInit), - new_TestFixture("testSetValue",testSetValue), - new_TestFixture("testInc",testInc), - new_TestFixture("testDec",testDec), - new_TestFixture("testClr",testClr), - }; - EMB_UNIT_TESTCALLER(CounterTest,"CounterTest", setUp,tearDown,fixtures); - return (TestRef)&CounterTest; -} -``` - -Example: _main.c_ -```cpp -#include -#include "stdio.h" - -TestRef CounterTest_tests(void); -TestRef PersonTest_tests(void); - -int main (int argc, const char* argv[]){ - TestRunner_start(); - TestRunner_runTest(CounterTest_tests()); - TestRunner_runTest(PersonTest_tests()); - TestRunner_end(); - return 0; -} -``` - -### Integration Testing -- Test the correct behavior of interacting components -- Interfaces are the main focus -- "White/Grey-Box" testing -- Correct timing behavior - - -##### Time Measurement -Profiling (e. g., GNU Profiler) - -```cpp -start=clock(); -myfunc(); -clocks=clock()-start; -Seconds = clocks / CLOCKS_PER_SEC; - -*io_pin = 1; -myfunc(); -*io_pin = 0; -``` - -[In-Circuit Debugger](http://www.ghs.com) -[chronSIM](http://www.inchron.de) - -### System Testing -- Test the system against the specification (the test cases of each requirement) -- "Black-Box" testing -- Test before the final delivery -- Testing at the development site -- Testing with testdata (can be formerly "real" data) and/or mock-up data - - -### System Testing -- Requirements Coverage -- Test Model Coverage - - Path Coverage - - -[Coverage](http://en.wikipedia.org/wiki/Code_coverage) -- Function Coverage `foo() called` -- Statement Coverage `foo(1,1)` -- Decision Coverage `foo(1,1); foo(0,1)` -- Condition Coverage `foo(1,1); foo(1,0); foo(0,0)` - -```cpp -int foo(int x, int y){ - int z = 0; - if ((x>0) && (y>0)) { - z = x; - } - return z; -} -``` - -##### Statistical Testing -Paths through the model ... -![](Assets/Softwaretechnik2-statistical-testing.png) - -### Acceptance Testing -- Testing at the customer site (by the customer) -- Testing with "real" data and/or online testing -- "Black-Box" testing -- ->Decision to finalize the project (Payment ... $$) - -## Beispiel: Testen eines Softstarters -Quelle: Florian Kantz, Thomas Ruschival, Philipp Nenninger, Detlef Streitferdt, "Testing with Large Parameter Sets for the Development of Embedded Systems in the Automation Domain", 2nd IEEE International Workshop on Component-Based Design of Resource-Constrained Systems (CORCS) at the 33rd IEEE International Computer Software and - Applications Conference (COMPSAC), Seattle / Washington, 2009. - -##### Development of Embedded Systems -Levels of testing -- Coding / Debugging level -- Functional level -- Component level -- Integration level / black-box testing - -Testing of Embedded Systems -- Behavior of a Softstarter - - Start / stop a motor, "single button" operation - - Monitoring -- Parameters for the Configuration - - Softstarter has about 150 parameters for configuration - -Size of the Task ... --> $1.0 * 10^{110}$ permutations ($1.9*10^104$ years) - -Goal: Reduce the number of permutations to test -> Identify a feasible subset of permutations - -Reduction of the Resulting Test Cases -- Clustering of parameters - - Independent subsets of parameters -- Introducing constraints between parameters - - To reduce the permutations of the parameters being part of a constraint rule. -- Pairwise Testing - - Finally reduce to a feasible number of permutations - -Clustering of Parameters -- Group parameters having no interaction with parameters outside the group -- Based on expert knowledge -- ... and a manual code analysis (-> unit testing) - -Constraints Between Parameters -- Mutual Exclusion -- Function Switching Parameters -- Selection of Ranges - -Pairwise Testing -- n-Way Testing - - Assumption: There are 3 parameters with 2 possible values each - - 8 possible parameter settings are reduced to 4 -- ![Rick Kuhn, http://csrc.nist.gov/groups/SNS/acts/index.html](Assets/Softwaretechnik2-pairwise-testing.png) -- Anwendung - - Medical Devices - - Web Browser - - Server - - Distr. Database - - Traffic Collision Avoid. - -##### Conclusion -![](Assets/Softwaretechnik2-parameter-testing.png) -- Structured way of handling complexity -- Approach is used in addition to the manually developed test cases -- Calculated reduction down to 7.5*10-27% (0,000000000000000000000000000075%) - - Means, if _Roadrunner_ (1456 TFlops) would have an assignment to calculate for 290382 years this approach would reduce it to one single instruction! - - But we would still have 2.26*10^69 to test ... (opposed to 1.0*10^110 ) -- Lessons learned - - Approach has to be _smartly adapted_ to black-box test the complete system - - Approach is very good for sub-systems / sub-problems - - -Pairwise Testing tools -- Jenny (cmd-line tool, C-Code) -- [NIST Tool](http://csrc.nist.gov/groups/SNS/acts/index.html) (open source) -- [http://www.testersdesk.com](http://www.testersdesk.com) (open source) - - -# Software Product Lines -## Beispiel: Cycling Computers ... -![](Assets/Softwaretechnik2-Cycling-Computers.png) - -## History of Terms -Both terms, Systemfamily and Product Line, refer to the same idea with different perspectives! - -- Systemfamily -> Technical Term - - How are the products developed / built? -- Product Line -> Business Term - - What are differences / features for selling the products? - -The term "product line" is now well established for both ideas within the software development domain. - -What is behind Product Lines? -- Make use of Commonalities & Variabilities -- Based on Feature Oriented-Domain Analysis [Kang 1990,1998,2002] -- Reference Architecture for the common parts (and all future products) -- Components for the variable parts (variabilities of each individual product) -- Automated derivation of variants based on the _features_ of a desired product -- SW Product Lines are between mass products and single products -- -> A customizable mass product - -Costs of a Product Line -![Pohl 2005, p10](Assets/Softwaretechnik2-product-line-cost.png) - -Time to Market of a Product Line -![Pohl 2005, p11](Assets/Softwaretechnik2-time-to-market.png) - -## Currently available Software Product Lines -Product Line Examples -- ABB, Gas Turbine Family, 35-270MW, Semantic Graphics Framework, Train Control Product Line -- Boeing, Bold Stroke (operational flight program software) -- CelsiusTech Systems AB, Naval Control Software -- Cummins Inc., Motor Control Software -- Hewlett-Packard, Printer Firmware -- Lucent Technologies, Telephone Switching SW -- Philips, Consumer Electronics -- Philips Medical, X-ray, ultrasonic, tomography -- Bosch, Driver Assistance Systems (e.g., parking pilot) -- Siemens Medical, X-ray, Magnetic Resonance, CT [Pohl 2005], pp.414-434 - - -## Product Line Development Cycle -Product Line Development Concept -![Pohl 2005, p21](Assets/Softwaretechnik2-product-line-development-concept.png) -- Domain Engineering: Domain engineering is the process of software product line engineering to define and realize the commonality and the variability of the product line. -- Application Engineering: Application engineering is the process of software product line engineering to build the applications of the product line by reusing domain artifacts and exploiting the product line variability. - -## The Concept of Variability -- Variation Point (of development/design elements): A variation point is a representation of a variability subject within domain artifacts enriched by contextual information. -- Variant (core + set of elements with variation points): A variant is a representation of a variability object within domain artifacts. -- Variability in Time: Variability in time is the existence of different versions of an artifact valid at different (application lifecycle) times. (-> roadmap ) -- Variability in Space: Variability in space is the existence of an artifact in different shapes at the same time. (-> binding time ) -- External Variability: External variability is the variability of domain artifacts that is visible to customers. -- Internal Variability: Internal variability is the variability of domain artifacts that is hidden from customers. -[Pohl 2005] - -## Modeling of Product Lines using Features -### Features -A feature is a user visible property of a product -> the user is willing to pay for such a property -- Functional Features -- Interface Features -- Parameter Features -- Structural Features -Depicted as ... Feature - -Feature Modeling -![](Assets/Softwaretechnik2-feature-modeling.png) -- mandatory - - ![Hera 2009](Assets/Softwaretechnik2-feature-mandatory.png) - - $Variants = \prod_{i=1}^S Variants(f_i)$ - - $Variants(f_i) = 1 \text{ if } isLeaf(f_i) == true$ -- optional - - ![Hera 2009](Assets/Softwaretechnik2-feature-optional.png) - - $Variants = \prod_{i=1}^S (Variants(f_i) + 1)$ - - $Variants(f_i) = 1 \text{ if } isLeaf(f_i) ==true$ -- XOR - - ![Kang 1990](Assets/Softwaretechnik2-feature-xor.png) - - $Variants = \sum_{i=1}^S Variants(f_i)$ - - $Variants(f_i) = 1 \text{ if } isLeaf(f_i) ==true$ -- OR - - ![Kang 1990](Assets/Softwaretechnik2-feature-or.png) - - $Variants = (\prod_{i=1}^S (Variants(f_i)+1) ) - 1$ - - $Variants(f_i) = 1 \text{ if } isLeaf(f_i) == true$ - -##### Feature Modeling: Example -![](Assets/Softwaretechnik2-feature-modeling2.png) - -- $Variants_{Editor} = \prod_{i=1}^S Variants(f_i) = 1*2 = 2$ -- $Variants_{Encryption} = \prod_{i=1}^S (Variants(f_i) +1 ) = 2*2 = 4$ -- $Variants_{Server_Connection} = \sum_{i=1}^S Variants(f_i)=3$ -- $Variants_{Email_Client} = \prod_{i=1}^S Variants(f_i) = 2*4*3 = 24$ - -##### Example Tool: PureVariants -[Cycle Computer Model](http://www.pure-systems.com) -```java -public void onCreate(Bundle savedInstanceState) { - super.onCreate(savedInstanceState); - setContentView(R.layout.start_screen); - ... - - PV:IFCOND(pv:hasFeature('Geschwindigkeitszeigen')) - TextView tv = (TextView)findViewById(R.id.start_digi_speed); - tv.setTypeface(tf); - PV:ENDCOND - ... -} -``` --> Managed preprocessor directives! - -##### Example online-tool: -[http://www.splot-research.org](http://www.splot-research.org) - - -## Handling Variability -![](Assets/Softwaretechnik2-variability.png) - -### Design Time -Variability of Use Cases -![Pohl 2005, p105](Assets/Softwaretechnik2-Variability-cases.png) -![http://www.oose.de/uml](Assets/Softwaretechnik2-UML-1.png) - -Variability _Traces_ to the Architecture -![Pohl 2005, p125](Assets/Softwaretechnik2-UML-2.png) - -Modeling Variability by Design Patterns -![](Assets/Softwaretechnik2-Design-pattern.png) - -Patterns: -- Implemented/~ing Design Variability -- Structural Patterns - - E. g., Adapter, Decorator, Facade, Proxy, ... -- Behavioral Patterns - - E. g., Strategy -- Creational Patterns - - E. g., Abstract Factory - -##### Factory Pattern -sourcemaking.com -- Intent - - Define an interface for creating an object, but let subclasses decide which classto instantiate. Factory Method lets a class defer instantiation to subclasses. - - Defining a "virtual" constructor - - The new operator considered harmful -- Problem - - A framework needs to standardize the architectural model for a range of applications, but allow for individual applications to define their own domain objects and provide for their instantiation - -##### Factory Method -![](Assets/Softwaretechnik2-factory-method.png) - -Example: Pocket Coffee Machine -- One-Button Operation, -> prepare coffee - - ... one machine per pad type ... -- The machine type shall be "jumpered" at production time -- [http://www.handpresso.com](http://www.handpresso.com) -![](Assets/Softwaretechnik2-CoffeeMachine.png) -![](Assets/Softwaretechnik2-CoffeeMachine2.png) - -```cpp -public static void main(String[] args){ - Abstract_Creator_CoffeMachine theMachineCreator; - switch( getJumperedVersion()){ - case 1: - theMachineCreator = new Create_handpresso_machine(); - theMachineCreator.getAny_machine().prepareCoffee(); - break; - case 2: - theMachineCreator = new Create_micropresso_machine(); - theMachineCreator.getAny_machine().prepareCoffee(); - break; - default: - break; - } -} -``` - -##### Abstract Factory Pattern -![](Assets/Softwaretechnik2-abstract-factory-pattern.png) - -![](Assets/Softwaretechnik2-abstract-factory-god.png) -```cpp -Deus_Ex_Factory* _factory; -God* _god; -_factory=new VeryHighDevLF_Ex_Factory; -_god=_factory->createGod(); -_god->createBigBang(); - -God* VeryHighDevLF_Ex_Factory::createGod(){ - Deus_Ex_Factory::setInstanceOfGod(new VeryHighDev_LF); - return Deus_Ex_Factory::getInstanceOfGod(); -} -``` - -##### Decorator -![](Assets/Softwaretechnik2-Decorator.png) - -### Compile Time -#### Variabiliy at Compile Time -- Exchange C-files before compilation - - "Enabled" in the design - - Replacement / extension -- #ifdef directives - - In the code ... (pre-processor) - - High effort to maintain the code -- Defines - - As environment variable for "make" - -Variability at Linking Time -- Use different libraries (libraries with the same interface) - - Update (-> replace libraries) - - Static linking -- Linker directives, #ifdef - -### Startup Time -Deliver different systems - -### Runtime -Variability at Runtime -- Use different libraries - - Update (-> replace libraries at system startup) -- Configuration files - - switch/if , based on config-files -- Virtual Machines / Scripts, Interpreter - -## Aspect-Oriented Programming -AOP was developed in the mid 90ies by Gregor Kiczales at the Xerox Palo Alto Research Lab (PARC) (now: Professor at the University of British Columbia, Canada) -- Handle cross-cutting concerns in software systems to increase the code maintainability and reusability -- E.g., persistency, authentication/security, error handling -- Cross-Cutting Concern <-->Feature - -![](Assets/Softwaretechnik2-aspect-oriented-programming.png) - -### AOP / AspectJ -New Concepts -- Pointcut - - Choose the methods of the software system - - Select values for several Join Points (hosting the resulting methods) in the program flow - - Execute the code specified in an Advice for each join point - - As replacement for the original method - - To extend the original method (before/after the original method) -- Inter-type declarations - - For the modification of the static structure of the software system (class members and class relationships) -- Aspects - - Are the modules to host crosscutting concerns (e. g., serialization, security) and may include pointcuts, advices, and inter-type declarations - -### Example: _Authentication_ -![](Assets/Softwaretechnik2-aop-routing.png) -![](Assets/Softwaretechnik2-aop-authentication.png) - -```java -public static void main(String[] args) { - System. _out.println("Starting Navigation ...");_ - Routing route0 = new Routing(); - Routing route1 = new RouteShortestTimeWay(); - Routing route2= new RouteShortestPath(); - route0.computeRoute(); - route1.computeRoute(); - route2.computeRoute(); - System. out.println("... shutting down system."); -} -``` -```java -public aspect Asp_Authentication { - pointcut AuthPayment(Routing ep) : - target(ep) && ( call(* Routing+.computeRoute()) ); - before(Routing ep) : AuthPayment(ep){ - if(ep instanceof RouteShortestPath){ - System.out.println(" -- payment by path"); - } - if(ep instanceof RouteShortestTimeWay){ - System.out.println(" -- payment by time"); - } - } - } -} -``` - -- Within the AuthPayment pointcut, ep refers to the object of the adviced method -- call : method call -- execution: execution of the method content -- get/set : reading / writing of attributes -- initialization : ... of the object -- handler : exception handler -- Signature of the method being part of the aspect. -- Wildcards: - - * An arbitrary number of characters - - .. An arbitrary number of characters with the point ‚.‘ - - + Includes the subtypes (here: subtypes of Routing) -- When to inject code? - - before the base method is executed - - after the base method is executed - - around new behavior with existing method referred by proceed() - -Summary: Aspect Oriented Programming -- Very good _separation of concerns_ -- Design of aspects is vital for the success of the development -- Only parts of the system behavior are in the code, all others are in aspects. -- Hard to (statically) analyze the system. -- Testing of such systems ... - -## Domain Specific Languages -Definition: A Domain Specific Language (DSL) is a computer programming language (-> grammar and syntax) to formulate / implement solutions for problems in a specified (limited) domain. - -### Types of DSLs -![](Assets/Softwaretechnik2-Domain-specific-languages.png) - -Example: Graphviz dot -![http://www.graphviz.org/](Assets/Softwaretechnik2-Graphviz-dot.png) -```cpp -digraph finite_state_machine{ - rankdir=LR; - size="8,5" - node [shape = doublecircle]; LR_0 LR_3 LR_4 LR_8; - node [shape = circle]; - LR_0 -> LR_2 [ label = "SS(B)" ]; LR_0 -> LR_1 [ label = "SS(S)" ]; - LR_1 -> LR_3 [ label = "S($end)" ]; LR_2 -> LR_6 [ label = "SS(b)" ]; - LR_2 -> LR_5 [ label = "SS(a)" ]; LR_2 -> LR_4 [ label = "S(A)" ]; - LR_5 -> LR_7 [ label = "S(b)" ]; LR_5 -> LR_5 [ label = "S(a)" ]; - LR_6 -> LR_6 [ label = "S(b)" ]; LR_6 -> LR_5 [ label = "S(a)" ]; - LR_7 -> LR_8 [ label = "S(b)" ]; LR_7 -> LR_5 [ label = "S(a)" ]; - LR_8 -> LR_6 [ label = "S(b)" ]; LR_8 -> LR_5 [ label = "S(a)" ]; -} -``` - -### Example: Test Case Generation -```cpp -model simple_model -tc: |$ // access to the test-api |$ - |$ extern void addtostream(int); - ... - |$ #define SENSOR_SPEED 0x0000 |$ void -testcase_1() - |$ { - |$ - -source [START] - "init" - [S_START] - -[S_START] - "0x55" - tc:|$ addtostream(0x55); -[startheader] -... -``` -```cpp -extern void addtostream(int); -... -#define SENSOR_SPEED 0x0000 -... -void testcase_1() -{ - addtostream(0x55); - addtostream(0x04); - ... - addtostream(0x02); -} -``` - -Example: Compiler Generators -flex/bison the former lex/yacc duo -![](Assets/Softwaretechnik2-compiler-generator.png) - -### Scanner -``` -digit [0-9] -number {digit}+\.?|{digit}*\.{digit}+ -identifier [a-zA-Z]+ -%%[ ] { /* Skip blanks. */ } -{number} { sscanf(yytext, "%lf", &yylval); - return NUMBER; } -\n|. { return yytext[0]; } -``` - -``` -%token NUMBER -%left '+' '-‘ -%left '*' '/‘ -%right UMINUS - -%%lines:lines expr '\n‘ { printf("%.12g\n", $2) } - | lines '\n‘ - | /* empty */ - | error '\n' { yyerror("Re-enter: "); - yyerrok; } - ; - -expr: expr '+' expr { $$ = $1 + $3; } - | expr '-' expr { $$ = $1 - $3; } - | expr '*' expr { $$ = $1 * $3; } - | expr '/' expr { $$ = $1 / $3; } - | '(' expr ')' { $$ = $2; } - | '-' expr %prec UMINUS { $$ = -$2; } - | NUMBER -; -``` - - -# Software Maintenance -## Motivation -- Software won‘t wear out! - - It gets old when it is changed by developers -> Architectural Decay - -Product Life Cycle: months ... many years - -Background -- Why? - - Maintenance: Fix broken software (-> bugs) - - Evolution - - Extend existing software (-> new features/functions) - - Develop (bad ->)good software - - Long Living Software (changes in HW/SW) - - Re-develop software -- When? Product Strategy, Business Rules -- Goals? Changeability, Maintainability, Comprehension - -## Reengineering -![SEI 1998](Assets/Softwaretechnik2-Reengineering.png) - -Terms -- Reverse Engineering - - Reconstruct the plan / the requirements of the ready made software -- Reengineering - - Change a Software System to enhance its Quality (at a higher abstraction level than -> Refactoring) -- Forward Engineering - - Opposite of -> Reverse Engineering. Standard development cycle, e. g., OpenUP, SCRUM, V-Model,... - -System Analysis -- How does the current system look like? -- What do we want to change -- Which rules do we want to follow and which rules are broken? - -- Running Software System - - Observation of the externally visible behavior + reaction - - Use Cases - - Requirements -- Code - - Disassembling / decompilation (not allowed by law!) - - Only for scientific work! OpenRCE (Rerverse Code Engineering, http://www.openrce.org) - - Counterpart: Obfuscation - - Transformation (-5...+5) - - Re-Order Code - - Change Variable Names - - Add branches (if (true) ...), each instruction as subroutine ... - - NOPs - - Encryption (of code) - - Obfuscator vermeiden -- Design & Requirements - - Design by observation (marginal) - - Requriements by observation (as above) - - Manual tasks - - Interview former / current employees - - Interview users of the system - - Deep Search of Documents - - -> Assess ~~the Feasibility of the Project~~ Reverse-Engineering might become Re-Development - - -## Code Smells -### Code - Hard to read -- Rules/Hints for Good Code - Naming - - Names want to tell their intention - - `int x; // average speed ->int averageSpeed;` - - ```cpp - void strcpy(char *a, char *b) -> - strcpy(char *destination, char *source) - strcpy(char *to, char *from) - ``` - - Be careful with e.g., btevhdl -> buttonEventHandler - - Don‘t ...: String noOfWayPoints; - - Where (in different types of lists) to add() / insert(), or how to sort()? - - Names that tell the intention - - List (alphabetically) of (global) variables in the code documentation - - Character similarities (-> the font question ...) - - "Ohhh Zero" O0 - - "Ihh One" I1, I1 - - "smallEL.. largeiI" lI -- Rules/Hints for Good Code - Functions - - Functions have a single, simple and clear behavior - - Don‘t duplicate code (code redundancy) - - Agree, enforce and live a project wide coding style - - Hard to follow call graphs if using function pointers - - Specifically document such occurences - - Don‘t use switch to access different class types - - -> use Polymorphism instead - - switch(typeof(object)) or switch(object.type) - - Reduce the number of arguments of a function/method - - ->use objects for more than three arguments -- Rules/Hints for Good Code - Comments - - Don‘t forget the Copyright Notice - - Comments do not only repeat the function name ... - - Keep comments in sync with the code (-> Review) - - Use exception handling -- Rules/Hints for Good Code - Global ... - - Exchange hand written parsers with -> DSL technology - - Start with non-threaded code, improve towards threads/parallelism - - Carefully select global variables (-> Singletons) - -## Metrics -### The Law of Demeter -- Proposed by Karl J. Lieberherrs research group in 1987 - - Northeastern University, College of Computer and Information Science, Boston, Massachusetts (http://www.ccs.neu.edu/home/lieber/) - - Style rule for the development of a good system design -- Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) - - Method M of Object O - 1. may only invoke methods of O - 2. use parameters of M - 3. use/call methods of any object created in M - 4. may invoke methods of O‘s direct component objects - 5. may access a global variable accessible by O, in the scope of M - - - -@ Design Level -- Overall Architecture -- Use -> static / dynamic analyses to asses - - Cohesion : A class strongly focussing on a single goal has a high cohesion. - - Coupling : A component which highly depends (by method calls) on another component is strongly coupled. - - ... of the architectural components -- Goal: low coupling and STRONG COHESION - -Calculate Cohesion -- *L*ack of *CO*hesion in *M*ethods for a class C - $$LCOM=1-\frac{1}{M*F} \sum_{i=1}^F count(f_i \leftarrow m)$$ - - M = Number of Methods in C - - F = number of fields in C (or attributes) - - fi = field i in the set (i=1...F) of the fields in a given class C - - count(fk <- m) = how many methods m use field fk - $$LCOM_{HS} = \frac{1}{M-1}(M-\frac{1}{F} \sum_{i=1}^F count(f_i\leftarrow m))$$ - - HS = Henderson-Sellers -- $LCOM_{HS}=1$ ![](Assets/Softwaretechnik2-LCOM-1.png) -- $M\rightarrow \infty, LCOM_{HS}\rightarrow 1$ ![](Assets/Softwaretechnik2-LCOM-2.png) -- $F\rightarrow \infty, LCOM_{HS}\rightarrow 1$ ![](Assets/Softwaretechnik2-LCOM-3.png) -- $M, F\rightarrow \infty, LCOM_{HS}\rightarrow 1$ ![](Assets/Softwaretechnik2-LCOM-4.png) - - -Cohesion -- As used in the Eclipse Metrics Plugin - $$LCOM *= \frac{\frac{\sum_{A=1}^n m(A)}{n} -m}{(1-m)}$$ - - $m(A)$ is the number of methods accessing an attribute A - - $n$ is the number of attributes - - $m$ is the number of methods m - - ($LCOM >> 1$ is alarming), small values ($<1$) are better. - - Hint: The class could be split into a number of (sub)classes. -- ![](Assets/Softwaretechnik2-highly-coupled.png) - - Changes in A cause the need to check B, C, D, E, F - - The interface of A might be hard to reuse in future/other projects - - Coupling : A component which highly depends (by method calls) on another component is strongly coupled. -- Afferent Coupling = #Classes outside a package that depend on classes inside the package. -- Efferent Coupling = #Classes inside a package that depend on classes outside the package. - - -Design Level -- "Tell, don‘t ask!" - - Bad: car.getSteeringWheel().getAngle() - - Better: car.getDirectionOfTravel() -- Start with reference architectures and refine ... - - Layers, pipes and filters, plug-in, client / server, MVC -- Use design patterns, (or at least) their concepts -- A class / component interface should hide most of the complexity underneath (-> Facade Pattern) -- 30-Rule, [Rooc 2004], p35 - - Methods <= 30LLOC - - #Methods per Class < 30 - - #Classes per Package < 30 - - #Packages per Subsystem < 30 - - System < 30 subsystems - - #Layers 3 ... 10 - -- Usage / Inheritance Relations - - Inheritance hierarchy < 10 -- In and between Packages - - Keep a small hierarchy (<5) -- In and between Subsystems - - Keep APIs small -- In and between Layers - - Use layers at all! - - Calls should follow the layer structure -- Don‘t use/allow cycles - -### What is the simplest design? -By Kent Beck, [Beck 2000], page 109 -1. The system (code and tests together) must communicate everything you want to communicate. -2. The system must contain no duplicate code. -3. The system should have the fewest possible classes. -4. The system should have the fewest possible methods. - -Requirements Level -- Sometimes hard to find but easy to change at very low costs! - - Inconsistencies - - Redundancy - - Contradictions - - Misspellings - - Wording (domain specific) - - Constraints (missing ~) - - Missing requirements vs. "goldplating" - - ... - -## Refactoring -### Refactoring Overview -- Software changes (beautifying) without changing the behavior! -- "Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior." [Fowl 1999, Martin Fowler, "Refactoring - Improving the Design of Existing Code", Addison Wesley, 1999, page 53.] -- (Highly) dependant on the tool support (-> IDE) - - Reduced errors while refactoring - -![http://www.eclipse.org/org/usagedata/](Assets/Softwaretechnik2-eclipse-refactoring.png) - -### Refactoring Howto -1. Set up the test cases for your code -2. Review the test cases -3. Identify the _smells_ -4. Refactor the code - Stepwise!! -5. Execute all test cases -6. Fix errors - - Go back to 6. unless the test result is green -7. Go to 4. and continue refactoring - -### Composing Methods -#### Extract Method -```cpp -void printMainScreen() { - System. out.println("Main Screen"); - // print details - System. out.println("Speed"); - System. out.println("curr Temp"); -} -``` -zu -```cpp -void printMainScreen () { - System. out.println("Main Screen"); - printMainScreenDetails(); -} -private void printMainScreenDetails() { - System. out.println("Speed"); - System. out.println("curr Temp"); -} -``` -#### Inline Method -```cpp -int getRating(){ - return(hasMoreThanFiveDeliveries())?2:1; -} -boolean hasMoreThanFiveDeliveries(){ - return(noOfDeliveries>5); -} -``` -zu -```cpp -int getRating(){ - return(noOfDeliveries>5)?2:1; -} -``` - -#### Remove Assignments to Parameters -```cpp -int discount(int inputVal, in quantity, in yearToDate){ - if(inputVal>50) inputVal -= 2; - ... -``` -zu -```cpp -int discount(int inputVal, in quantity, in yearToDate){ - int result = inputVal; - if(inputVal>50) result -= 2; - ... -``` - -#### Moving Features between Objects -```cpp -public class SmallCycle{ - DataModel myDM = new DataModel(); - int localValue; - public void calcHeight() { myDM.height = 45; localValue = 100; } - public void calcSurface() { myDM.surface = 452; calcHeight(); } - ... -``` -zu -```cpp -public class SmallCycle { -... - public void calcSurface(){ - myDM.surface = 452; - myDM.calcHeight( this); - } -... - -public class DataModel { - public int height; - public int surface; - public void calcHeight(SmallCycle smallCycle){ - height = 45; - smallCycle.localValue = 100; - } -``` - -#### Extract Class -```cpp -public class BigCycle { -... - String owner; - String ownerBirthday; - public BigCycle(){ - owner = "Harry"; - } -``` -zu -```cpp -public class BigCycle { - ... - Owner localOwner = new Owner(); - public BigCycle(){ - localOwner.setName("Harry"); - } -} -... -public class Owner{ - private String name; - private String birthday; - ... - public void setName(String name){ - this.name = name; - } - ... -} -``` - -### Organizing Data -Replace Magic Number with Symbolic Constant -```cpp -double getLengthPerTireTick(int tiresize){ - return ((tiresize*25.4)/2)*2*3.141 -} -``` -zu -```cpp -... return ((tiresize*MMPERINCH)/2)*2*Math.PI -static final double MMPERINCH = 25.4 -``` - -#### Simplifying Conditional Expressions -- Decompose Conditional -- Consolidate Conditional Expression - ```cpp - double disabilityAmount(){ - if(_seniority <2) return 0; - if(_monthsDisabled >12) return 0; - if(_isPartTime) return 0; - //compute disability amount - } - double disabilityAmount(){ - if(isNotEligableForDisability()) return 0; - //compute the disability amount - } - ``` -- Consolidate Duplicate Conditional Fragments - ```cpp - if(isSpecialDeal()){ - total = price * 0.95; - send(); - } - else { - total = price * 0.98; - send() - } - ``` - zu - ```cpp - if(isSpecialDeal()) - total = price * 0.95; - else - total = price * 0.98; - send(); - ``` -- Replace Nested Conditional with Guard Clauses - ```cpp - double getPayAmount(){ - double result; - if(_isDead) result = deadAmount(); - else { - if(_isSeperated) result = seperatedAmount(); - else { - if(_isRetired) result = retiredAmount(); - else result = normalPayAmount(); - } - } - return result; - } - ``` - zu - ```cpp - double getPayAmount(){ - if(_isDead) return deadAmount(); - if(_isSeperated) return separatedAmount(); - if(_isRetired) return retiredAmount(); - return normalPayAmount(); - } - ``` -- Replace Conditional with Polymorphism - ```cpp - double getSpeed(){ - switch(type){ - case EUROPEAN: - return getBaseSpeed(); - case AFRICAN: - return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts; - case NORWEGIAN_BLUE: - return (_isNailed) ? 0 : getBaseSpeed(_voltage); - } - } - ``` - -### Making Method Calls Simpler -- Rename Method -- Separate Query from Modifier - -### Dealing with Generalization -- Pull Up Field -- Push Down / Pull Up - -### Other Refactorings -- Change Method Signature -- Extract Local Variable -- Extract Local Variable to Field -- Convert Anonymous Class to Nested -- Move Type to new File -- Extract Superclass -- Extract Interface - -## Long Living Software -Mars Rover Software Coding Guidelines -![](Assets/Softwaretechnik2-mars-rover-software.png) - -[Moodle](A. Brown and G. Wilson, The Architecture of Open Source Applications, Volume II , lulu.com, 2012.) -![](Assets/Softwaretechnik2-moodle.png) -- Core: Web-Server (e. g., Apache) hosting the PHP-code - - Server: /var/www/moodle/category.php - - Client: https://moodle2.tu-ilmenau.de/course/category.php?id=92 -- Connects to a database (e. g., MySQL) -- _moodledata_ folder (outside the web root) -- Extensible: moodle Plug-In API (according to plugin types) - - = a folder / -- Documentation @ https://moodle.org/ - -### Compiler Compiler -(e. g., flex/bison) -- Lexer, Yet Another Compiler Compiler -- First compiler-compiler 1960 by Tony Brooker -- YACC initially developed 1970 by Stephen C. Johnson (AT&T Corporation) for Unix -- **L**ook-**A**head **L**eft to right **R**ightmost derivation - Parser - ![http://en.wikipedia.org](Assets/Softwaretechnik2-LALR-Parser-1.png) - ![http://en.wikipedia.org](Assets/Softwaretechnik2-LALR-Parser-2.png) -- ![](Assets/Softwaretechnik2-Lexer.png) - - -### Long Living Systems -How to build long living system in the first place? -- Very broad/extensive requirements engineering phase -- Capture (the needed) Variabilities, (e. g.: Future Workshop) - - Product Lines -- Clear and Understood SW(/HW)-Architecture - - Remove the _smells (periodically)_ , -> Reviews, Refactoring - - Standard Architectures, Design Patterns, COTS -- Prepare all documents and the development environment for "newcomers" and "strangers" -- Good Estimation of ... - - ... the efforts over time - - ... the efforts for changes - - ... the limits of the architecture - - ... the expected SW END OF LIFE + reengineering costs -- ... never touch a running system - -Key Attributes of Long Living Systems -1. Keep your system focussed on what it is(was) supposed to do. -2. Take your time to design your APIs with pride and keep them stable. (-> if at all, only extensions are feasible!) -3. Design the core architecture with well defined extension mechanisms to tailor the application to user needs. (-> Plug-Ins, DSL, DLLs) -4. Take maintenance serious , in terms of the needed/planned effort and the trageted/desired quality. diff --git a/Softwaretechnik.md b/Softwaretechnik.md deleted file mode 100644 index 5409860..0000000 --- a/Softwaretechnik.md +++ /dev/null @@ -1,2853 +0,0 @@ ---- -title: Softwaretechnik 1 -date: Wintersemester 20/21 -author: Robert Jeutter ---- - -> Software: Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die für Ihre Anwendung notwendig oder hilfreich sind [Hesse] - -Gute Software ist schwer herzustellen -- Entspricht Kundenwünsche, Vollständigkeit -- Funktioniert Korrekt -- Kosten- und Termintreue bei der Erstellung -- weitere nicht-funktionale Qualitätsforderungen - - Benutzerfreundlichkeit, Ergonomie - - Sicherheit - - Zuverlässigkeit, Fehlertoleranz - - Performanz - - Ressourcen-Effizienz, Skalierbarkeit, Übertragbarkeit - - Wartbarkeit, Änder- und Erweiterbarkeit - -Softwaretechnik -- Technische Disziplin der Software Herstellung -- Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert] - -Wie kann man Software besser entwickeln? -- Ingenieursmäßige Herangehensweise - - Verwendung bekannter Prinzipien und Methoden - - Systematische Vorgehensweise -- Verwendung von: - - Abstraktion, Modelle, Notation, Simulation - - Wiederverwendung:Muster, Komponenten, Framework -- Organisation - - Arbeitsteilung, Integration, Planung -- Verwendung von Werkzeugen - - IDE (Integrated Development Environment) - - Versionierung, Bugtracker, Modellierungswerkzeug - -# Modellierungskonzepte -> Modell: ist eine Abstraktion eines Systems mit der Zielsetzung, das Nachdenken über ein System zu vereinfachen, indem irrelevante Details ausgelassen werden [Brügge] -$\rightarrow$ Beschreibung eines Ausschnitts der Realität - -- erstellen einer Abstraktion -- abbilden signifikanter Eigenschaften -- Deskriptiv/präskriptiv (real oder geplant) -- Sichtweise auf ein System (Struktur, Verhalten, Zustand,...) -- heißt Weglassen -- setzt Verstehen voraus -- ist nicht automatisierbar - -Verschiedene Modelle: -- Analysemodell -- Entwurfsmodell -- Implementierung (-smodell) -- Vorgehensmodell -- Produktmodell -- Dokumentation, Alternativen-Auswahl - -Modelle für: -- Sichten -- Funktionen -- Daten -- Algorithmen -- Systemumgebung -- Dynamisches Verhalten -- Objektorientierte Modelle - -## Klassische Modelle -- Funktionen: - - Funktionsbaum - - Hierarchische Dekomosition der Fkt - - nummerieren der Ebenen/Funktionen möglich - - Bsp: Abonnement Verwaltung - - Blockschaltbild - - eingebettetes System, HW/SW -- Daten - - Data Dictionary - - Verzeichnis von Daten mit Strukturinformationen - - Backus-Naur-Form, kontextfreie Grammatik - - Entity Relationship Diagram - - Daten und ihre Beziehungen -- Systemumgebung - - Datenflussdiagramm - - Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen - - kein Kontrollfluss -- Algorithmen - - Entscheidungstabelle - - Regelbasierte Beschreibung - - Bedingung - - Aktionen - - Reduktionsregeln - - Pseudocode - - von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus - - Programmablaufplan - - Grafische Beschreibung des Kontrollflusses - - DIN 66001 - - Unstrukturiert - - Struktogramm - - Nassi-Shneidermann-Diagramm - - keine Sprünge -- Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge) - - Zustandsautomat - - Verhalten mit Zuständen und -übergängen - - Automatenmodelle und -theorie - - Ggf zerlegung oder kommunizierende Automaten - - Flow-Chart - - Ereignisgesteuerte Prozesskette (EPK) - - Geschäftsprozesse - - BPM - - Petri-Netz (ggf. mit Zeitmodell) - - Grafische Beschreibung von Nebenläufigkeit und Synchronisation -- Objektorientierte Modelle - - Klassendiagramme - - UML - - -## Objektorientierung -- bessere Strukturierung für komplexe Zusammenhänge -- Abstraktere Sichtweise -- Grundprinzip: Zerlegung; Teile und Herrsche -- ein System besteht aus vielen Objekten -- ein Objekt hat - - definiertes Verhalten - - Menge genau definierter Operationen - - Operation wird beim Empfang einer Nachricht ausgeführt - - inneren Zustand - - Zustand des Objekts ist Privatsache - - Resultat einer Operation hängt vom aktuellen Zustand ab - - eindeutige Identität - - Identität ist unabhängig von anderen Eigenschaften - - Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich -- Klasse - - Gleichartige Objekte mit ggf. verschiedenen Zuständen - - Verhaltensschema – Operationen - - Innere Struktur – Attribute - -Vorteile der Objektorientierung -- Zuständigkeitsbereiche - - Daten, Operationen und Zustand: lokal und gekapselt -- Klare Schnittstellen - - Definiertes Objektverhalten, Nachrichten -- Hierarchie - - Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung -- Baukastenprinzip - - Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung) - - -## Unified Modeling Language -- Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme - - Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software - - Für OO-Softwareentwicklung und -prozess geeignet - - UML ist weder Methode noch Prozess - -Warum UML? -- Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard -- Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen -- Für Analyse, Entwurf, Implementierung und Test einsetzbar -- Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung -- Erweiterbarkeit der UML mit Stereotypen und Tags -- Semi-formale Modelle, z.T. verschiedene Interpretationen -- Offenheit: Erweiterung mit stereotypes, tags, constraints - -Nachteile UML -- UML ist in vielen Facetten nicht präzise festgelegt -- Werkzeuge für Transformation, Analyse etc. fehlen noch -- UML ist keine „kleine Sprache“: Lernaufwand notwendig -- Komponenten sind nicht adäquat darstellbar -- Sprachen wie die UML werden erlernt durch Übung! -- Aber: LV SWT ist kein kompletter UML-Kurs - -### Überblick über Modelle -- 14 Diagrammarten -- Struktur-Diagramme - - Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-, - - Paket- und Verteilungsdiagramm - - Profildiagramm – zur UML-Erweiterung -- Verhaltens-Diagramme - - Use-Case-, Aktivitäts- und Zustandsdiagramms - - Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm - -#### Use-Case-Diagramm -- Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie) -- Erste Anforderungsspezifikation (requirements) -- Planbare Einheiten als Inkremente für die Entwicklung -- Keine Modellierung eines Ablaufs! -- Erstellen von Testfällen (test case generation) -- Grundelemente - - Anwendungsfall: Use Case - - Beteiligte: Aktor -- Verfeinerung mittels Use-Case-Realisierung notwendig - - Textuelle Beschreibung - - Verhaltensdiagramme - -#### Klassendiagramm -- Modellierung der Struktur (Aufbau) eines Systems -- Modellierung von statischen Aspekten -- Modellierung der Struktur von Daten -- Klasse im Mittelpunkt - - Aufbau: Attribute, Operationen - - Beziehungen zueinander: Assoziationen, Vererbung -- Verbreitetstes und bekanntestes Diagramm der UML - -#### Objektdiagramm -- Struktur des Systems zur Laufzeit zu einem Zeitpunkt -- Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt -- Eine detaillierte Sicht auf einen Aspekt - - Keine vollständige Beschreibung (zu komplex) - - Für kompliziertere Abhängigkeiten (z.B. Rekursion) -- Objektdiagramm für alle Arten von Exemplaren - - z.B.: Klasse (Objekt), Komponente, Knoten, ... -- Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme -- Kein Verlauf der Wertebelegung über die Zeit - -#### Paketdiagramm -- Gliederung (Strukturierung) des Systems in Teile (Pakete) -- Zuordnung von Elementen zu einem Paket -- Bildung von Hierarchien (Enthält-Beziehung) -- Abhängigkeiten zwischen den Paketen - - "Include" von Quellcode-Dateien (<>) -- Anwendung: - - Zum Grobentwurf von Systemen - - Definition von Schichten - -#### Komponentendiagramm -- Strukturierung des Systems durch Komponenten -- Komponente: Modulare, austauschbare Einheit (Substitution) -- Modellierung der Abhängigkeiten zwischen Komponenten -- Modellierung der inneren Struktur von Komponenten -- Definition von Schnittstellen - -#### Kompositionsstrukturdiagramm -- Teile-Ganzes-Strukturen -> Kompositionsstruktur -- Strukturell statische Kompositionsstrukturen: - - Kurzschreibweise bei vielen Kompositionen - - Modellierung des Aufbaus komplexer Systeme -- Strukturell dynamische Kompositionsstrukturen: - - Notwendige Strukturen zur Realisierung eines Verhaltens - - Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern -- Starke Verwandtschaft mit dem Klassendiagramm -- Spezialisierte Kompositionsbeziehung -> erweiterte Semantik - -#### Aktivitätsdiagramm -- Modellierung von - - Kontrollflüssen - - Datenflüssen - - Parallelem Verhalten - - Verzweigungen, bedingten und gewichteten Abläufen -- Geschäftsprozessmodellierung möglich -- Abstrakte und detaillierte Verhaltensbeschreibung möglich -- Grundlage zur Codegenerierung -- Zur Verfeinerung von - - Use-Cases - - Operationen / Interaktionen - - anderen Aktionen und Aktivitäten - -#### Interaktionsdiagramme -- Modellierung von - - Kommunikation zwischen Kommunikationspartnern (Lebenslinie) - - Operationen (Modellierung eines Programms) - - Informationsaustausch / Nachrichten -- Gemeinsames Grundkonzept der Interaktionsdiagramme -- Sehr detaillierte Diagramme - - Meist nicht zur vollständigen Beschreibung eines Systems - - Betrachtung eines wichtigen Teilaspekts -- Grundlage zur Codegenerierung - -#### Sequenzdiagramm -- Genaue zeitliche Abfolge von Nachrichten -- Umfangreichstes Interaktionsdiagramm -- Kontrollelemente möglich (Schleifen, Verzweigungen) - -#### Kommunikationsdiagramm -- Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund -- Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen - -#### Timing-Diagramm -- Genaue zeitliche Darstellung von Zustandsübergängen -- Kommunikation abhängiger Zustandsautomaten -- Modellierung einzelner Interaktion - -##### Prinzipieller Aufbau -- Zeitlicher Verlauf senkrecht -- Kommunikationspartner waagerecht (unsortiert) -- Lebenslinie - - Rechteck mit gestrichelter senkrechter Linie - - Start, Ende und Dauer der Ausführung einer Operation - - Rekursive Aufrufe möglich -- Ereignisspezifikation - - Stelle des Sendens / Empfangens der Nachricht - - Definition der Reihenfolge des Auftretens - - Trace: Folge von Sende- und Empfangsereignissen - -##### Weitere Elemente des Sequenzdiagramms -- Nachrichten ohne Sender - - z.B. am Beginn einer Interaktion -- Verlorene Nachrichten (ohne Empfänger) - - Nachricht ohne dargestellten Empfänger - - z. B. am Ende einer Interaktion -- Erzeugen von Lebenslinien - - Gestrichelte Linie mit geöffnetem Pfeil - - Keine Rückgabenachricht - - Zeitliche Einrückung des Rechtecks -- Zerstören von Lebenslinien - - Durchgezogene Linie mit Dreieckende - - Kann Rückgabenachricht erzeugen - -##### Nachrichten in Interaktionsdiagrammen -- Ereignis des Sendens bzw. Empfangens von Nachrichten -- Typen: - - Operationsaufruf (synchron / asynchron) - - Antwort Nachricht - - Signal (asynchron), Create-/ Delete Message -- Operationsaufruf: Parameterliste muss kompatibel sein -- Nachrichtentypen - -#### Zustandsdiagramm -- Modellierung des (vollständigen?) Verhaltens - - Zustände von Klassen / Objekten / Komponenten - - Übergänge zwischen den Zuständen - - Ereignisse, die Zustandswechsel auslösen -- Modellierung von endlichen Automaten (Zustandsmaschinen) - - Deterministische - - Nichtdeterministische -- Verfeinerung von Zuständen möglich -- Modellierung von verteilten Systemen / parallelem Verhalten -- Grundlage zur Codegenerierung - - -# Analyse -- Einordnung in den Projektablauf -- Was ist eine Anforderung? - - Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems - - Notwendig für die Akzeptanz vom Kunden - - Definition (IEEE 610.12-1990) - - Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft - - von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen - - Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen - -- Funktionale Anforderungen - Was soll es tun? - - „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert] - - Was leistet das System - - Welche Funktionen bietet es - - Wie interagiert es mit der Umgebung - - Anforderungen an: - - Verhalten - - Struktur - - (Alternativ: Statik, Dynamik, Logik) -- Nichtfunktionale Anforderungen – Wie? - - „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert] - - Auch Bezeichnet als: - - Quality of Service - - Qualitätsanforderungen - - Arten - FURPS (ISO 9126): - - Functionality (Funktionalität) - - Usability (Benutzbarkeit) - - Reliability (Zuverlässigkeit) - - Performance (Effizienz) / Portability (Übertragbarkeit) - - Supportability (Änderbarkeit/ Wartbarkeit) - -- Funktionalität - - Angemessen, Genauigkeit - - Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit - - (Nicht ausreichend spezifizierte funktionale Anforderung) -- Benutzbarkeit - - Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität -- Zuverlässigkeit - - Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit -- Effizient/ Leistungsanforderungen - - Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit -- Portabilität - - Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit -- Wartbarkeit - - Analysierbarkeit, Änder- und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit -- Weitere: - - Konformität zu Konventionen und Bestimmungen - - Interoperabilität zu anderen Systemen - - Implementierungsanforderungen - - Schnittstellenanforderungen - - Skalierbarkeit (Änderungen des Problemumfangs) - - Betriebliche und rechtliche Rahmenbedingungen - - Liefer- und Verpackungsanforderungen - -### Nichtfunktionale Anforderungen -Schwierigkeit nichtfunktionaler Anforderungen -- Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar -- „Das Auto hat vier Räder“ (Struktur) -- „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten) -- „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit) - -Umgang mit nichtfunktionalen Eigenschaften -- Nicht direkt „by construction“ zu realisieren -- Naive Herangehensweise: Ignorieren! - - Entwerfen und Implementieren der Software ohne Berücksichtigung nichtfunktionaler Eigenschaften - - Testen der nichtfunktionalen Eigenschaften - - Wenn nicht erfüllt: Entwurf und Implementierung ändern! -- Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind! - -Sinnvoller Umgang mit nichtfunktionalen Eigenschaften -- Untersuchung der Projektrisiken bereits in der Analysephase - - größte Risiken zuerst betrachten! - - Immer fragen: Geht das so überhaupt? - - Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen – aber wie? -- Modellbasierter Entwurf - - Modellierung des Systems und seiner Umwelt - - Bewertung des Modells (Simulation) - - Lehrveranstaltungen Systementwurf, KIS, LTS - -Randbedingungen -- „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“ -- Werden nicht umgesetzt -- Schränken Lösungsraum ein -- Beispiele: - - Kosten - - Durchlaufzeit: Time to Market - - Vorgaben durch Marketing und Vertrieb - - Technische Randbedingungen (nichtfunktionale Anforderung) - -![Analysebaum von Sommerville](Assets/Softwaretechnik1_Analyseformen1.png) -![Analysebaum von Sommerville](Assets/Softwaretechnik1_Analyseformen2.png) - -Geforderte (Meta-)Eigenschaften -- Vollständig: alle Szenarien sind beschrieben -- Konsistent: keine Widersprüche -- Eindeutig: nur eine Interpretation möglich -- Korrekt: genaue und richtige Darstellung -- Realistisch: unter geg. Einschränkungen implementierbar -- Überprüfbar: durch Tests am Endprodukt nachweisbar -- Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen) -- Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...) -- Validierung mit dem Kunden - -- Requirements Engineering - - Ermittlung, Analyse und Verwaltung von Anforderungen - - Ausgangspunkt: Projektidee -- Anforderungsermittlung - - requirements elicitation, requirements definition - - Bestimmen und dokumentieren der Anforderungen an das geplante System - - Beteiligt: Entwickler, Kunde, Benutzer - - Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft -- Anforderungs-Analyse - - requirements analysis, system modeling - - Beschreibung im Detail und formal strukturiert - - Beteiligt: Entwickler - - Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft - -![Anforderungsentwicklung von Balzert](Assets/Softwaretechnik1_Anforderungsentwicklung.png) - -| | Anforderungsermittlung | Systemmodellierung | -| -- | -- | -- | -| Ergebnis | Anforderungsspezifikation im Lastenheft, Glossar, Lastenheft | funktionale Spezifikation in Produktdefinition, Analysemodell, Pflichtenheft | -| Notation | Text | Text + (semi-) formales Modell | -| Kommunikation | mit dem Kunden | zwischen Entwicklern | -| Sichtweise | des Anwenders | äußere Systemaspekte | -Vor allem: Kommunikationsleistung! - -Bedeutung: -- Falsche Anforderungen führen zu falschem System -- Frühe Fehler im Entwicklungsprozess sind teuer! - -Fehlerentstehung und Fehlerquellen bei Anforderungserfassung -- 83% sprachliche Fehler (Un- bzw. Missverständlich) -- 75% Logische Fehler (Widersprüchlichkeit, Redundanz) -- 73% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig) - -## Ermiteln von Anforderungen -Woher kommen Anforderungen? -- Ausgangspunkt - - Projektidee, schriftliche Skizze - - Kurz und knapp - - Stichpunkte der wichtigsten Funktionen - - Lastenheft (falls schon existiert) -- Interessenhalter (stakeholder) - - Identifizieren, Wichtigkeit bewerten (berücksichtigen?) - - Ansprechpartner? Interessen und Erwartungen - - Fachexperten, Verantwortliche, Betroffene - -Beteiligte Rollen -- Endbenutzer - - Aufnahme Ist-Zustand, Domänenwissen, Anforderungen -- Kunde - - Definiert Ziel des Systems, Vertragsverhandlung -- Konfigurationsmanager - - Revisionsgeschichte der Dokumente, Nachvollziehbarkeit -- Architekt - - Integration von Anwendungsfall- und Objektmodellen -- Analytiker - - Modelliert das System und erstellt Anwendungsfälle -- Redakteur -- Prüfer - -Wie ermittelt man Anforderungen? -- Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme -- Systematische Vorgehensweise -- Kommunikation mit Kunden -- Geschäftsprozess (business process) - - fachlicher Ablauf, der Wert oder Kosten verursacht -- Akteur (actor) - - Benutzer, Schnittstelle nach außen -- Szenario (scenario) - - Interaktion mit System als Ablauf -- Anwendungsfall (use case) - - Automatisierter Arbeitsschritt, vom System ausgeführt -- Interviews mit Fachanwendern - - Mitschrift, später strukturierter Text und Tabelle -- Strukturierte Spezifikation - - Vorlagen / sprachliche Anforderungsschablonen - - Formulare - - Reduzierung sprachlicher Mehrdeutigkeiten -- Anwendungsfalldiagramm (Use-Case-Diagramm) - - Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird - - Anforderungen an das System modellieren – was soll das System leisten - - Systemgrenzen / Systemkontext festlegen - - Systembeteiligte modellieren - - Planbare Einheiten als Schritte für die Entwicklung - - Verwendung bereits ab Projektbeginn - - Keine Modellierung eines Ablaufs! -- Umgang mit Szenarien und Anwendungsfällen - - Zunächst nur zum Verständnis kurz aufstellen - - Systemgrenze definieren - - Beschreibungen verfeinern - - Änderungen mit Kunden abstimmen - - Prototypen nur zur visuellen Unterstützung - - Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind - -Leitfaden für Anwendungsfälle -- Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere) -- Akteure mit Substantiven benennen (Anwender) -- Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen -- Schritte im aktiven Stil beschreiben (Auto bremst) -- Ursächliche Beziehung zwischen Folgeschritten -- 1 Anwendungsfall = 1 vollständige Transaktion -- Normalfall darstellen; Ausnahmen gesondert beschreiben -- Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden) -- Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen - -- Typische Probleme - - Kommunikations- und Verständnisprobleme - - Viele verschiedene Beteiligte - - Kunden wissen nicht, was sie genau wollen und was geht - - Verwendung von Fachsprachen - - Widersprüchliche Anforderungen, verschiedene Interessen - - Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen - - Zusätzliche Beteiligte können auftauchen - - Anforderungen ändern sich während der Entwicklung -- Anforderungsänderungen - - Sind die Regel -- Tätigkeiten der Anforderungsanalyse - - Anforderungen strukturieren - - Eigenschaften der Anforderungen bestimmen - - Anforderungen priorisieren - - Anforderungen in Textform, Grafiken, Modellen dokumentieren - - Anforderungen modellieren - - Anforderungen auf inhaltliche Qualität prüfen - - Auf Übereinstimmung mit den Zielen prüfen - - Ziel Abnahme der Anforderung - - Hängt mit Analyse des Systems zusammen -- Anforderungen strukturieren - - Unterteilung - - Funktional, Nichtfunktional - - Muss, Kann,... oder Haupt- und Nebenanforderung - - Hierarchische Zerlegung - - Unterteilen, Verfeinern - - Ordnung festlegen, eindeutig Nummerieren - - auf Einmaligkeit achten - - Beziehungen festhalten - - Verwendung von Werkzeugen - - MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,... - - Modellierungswerkzeuge -- Eigenschaften bestimmen - - Wahl der Eigenschaften firmen- bzw. projektspezifisch - - Wichtige Eigenschaften - - Identifikationsnummer - - Kurzbezeichnung - - Beschreibung (Text, ggf. Grafik, Modell) - - Aufwand - - Priorität der Anforderung - - Bearbeitungsstatus / Restaufwand - - Zugeordnet (wer ist verantwortlich / bearbeitet) - - Querverbindungen zu anderen Anforderungen - - Ggf. zusätzliche Dokumente oder Bemerkungen - - Stabilität der Anforderung (Änderungswkt.) - - Kritikalität der Anforderung: Schäden bei Fehlern? - - Entwicklungsrisiko: Erfolgsaussichten der Umsetzung - - Abnahmekriterien / Erfüllungsnachweis durch? - - Anforderungstyp: Funktional, nicht funktional ,... - - Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion - - Mögliche Konflikte - - Autor - - Quelle: Wer möchte die Anforderung umgesetzt haben? - - Status der Beschreibung: Idee, grober Inhalt, detailliert - - Anforderungsversion -- Anforderungen priorisieren - - MuSCoW-Priorisierung - - Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t) - - Ad-hoc: Stakeholder priorisiert Anforderungen - - Priorisierungsmatrix / Kosten-Wert-Analyse - - Eigenschaften bewerten (Punkte vergeben) - - Werte gewichten - - Priorität berechnen $Prioritäten = \frac{Nutzen - Nachteil}{Kosten + Risiko}$ - - Kano-Klassifikation - - Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit) - - Leistungseigenschaften: Sonderwünsche - - Begeisterungseigenschaften: Wird nicht erwartet - - Abfragen per Fragenkatalog - - Reihenfolge festlegen - - -![Kano Klassifikation von Balzert](Assets/Softwaretechnik1_Kano1.png) -![Kano Klassifikation von Balzert](Assets/Softwaretechnik1_Kano2.png) - -## Objektorientierte Analyse und Systemmodellierung -- Übersicht - - Aufgabe: Systemmodell erstellen, funktionale Spezifikation - - Beschreibung der Systembenutzung und des Verhaltens - - Was, nicht wie – Implementierungsaspekte ausklammern - - Nicht: Datenhaltung, Verteilung, Technologien, Architektur, .. - - Zusammenhang mit Anforderungsspezifikation - - OO: Modell des Anwendungsbereichs -- Analysemodell - - Korrekt, vollständig, konsistent und nachprüfbar - - Struktur und Verhalten - - Verschiedene Sichten (OO, Strukturiert, ...) -- Eingangsdokumente - - Lastenheft, Anforderungsspezifikation -- Typische Ergebnisse - - Funktionales Modell - - Geschäftsprozesse und Anwendungsfälle - - Objektmodell - - Dynamisches Modell – Systemverhalten - - Zustands- und Sequenzdiagramme - - Vor- und Nachbedingungen von Systemoperationen - - Prototyp / Spezifikation Benutzungsschnittstelle - - Pflichtenheft -- Objektorientierte Analyse nach [Brügge / Dutoit] - - Verdeutlicht iterativen Ablauf - - Unterteilung des Analysemodells in: - - Funktionales Modell (Anwendungsfälle) - - Objektmodell (Klassen und Objektdiagramme) - - Dynamisches Modell (Zustands- und Sequenzdiagramme) - - Unterscheidung der Objekttypen - -![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge1.png) -![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge2.png) - -- Heuristik Sprache $\rightarrow$ OO-Modell -- Objektarten im Systemmodell - - Entitätsobjekte – vom System verwaltete Informationen - - Grenzobjekte – Interaktion zwischen System und Akteuren - - Steuerungsobjekte – Durchführung der Anwendungsfälle -- Identifizierung von Entitätsobjekten - - Begriffe, die klargestellt werden müssen - - Wiederkehrende Substantive in Anwendungsfällen - - Heuristiken - - Reale Objekte, die das System kennen muss - - Reale Prozesse, die das System verfolgen muss - - Anwendungsfälle - - Datenquellen und -senken - - Artefakte, mit denen der Nutzer interagiert -- Identifizierung von Grenzobjekten - - Elemente der Benutzungsschnittstelle - - Formulare für Eingaben - - Nachrichten, Rückmeldungen - - Endgeräte - - In der Begriffswelt des Anwenders bleiben! - - Schnittstellen grafisch skizzieren bzw. Prototyp! -- Identifizierung von Steuerungsobjekten - - Koordination von Grenz- und Entitätsobjekten - - Abarbeitung von Anwendungsfällen - - Reihenfolge von Schritten - - Informationen übernehmen und weiterleiten - - Oft ein Steuerungsobjekt pro Anwendungsfall - - Beispiel: Simulationsszenario - - Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle - -- Abläufe der Anwendungsfälle modellieren - - Ziel - Objekte finden - - Klassen identifizieren - - Verhalten / Operationen finden -- Use Case durch Interaktion verfeinern - - einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm - - Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung) - - datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung) - - Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm - - zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm - - Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm - - komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm - - komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm - - komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm - -- Dynamische UML-Modelle - - Abläufe - - Aktivitätsdiagramm (activity diagram) - - Kommunikationsdiagramm (communication diagram) - - Sequenzdiagram (sequence diagram) - - Zeitdiagramm (timing diagram) - - Zustandsabhängiges Verhalten von Objekten - - Zustandsautomat (state chart diagram) - -- Aktivitätsdiagramm - - Aktion – einzelner Schritt - - Aktivität - - Beschreibt einen Ablauf / repräsentiert ein Verhalten - - Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten - - Schachtelung von Aktivitäten und Aktionen - - Aktionen in Aktivitäten enthalten - - Aktionen durch Aktivitäten verfeinerbar - - Aktivitäten beschreiben / verfeinern - - Aktionen, Use Cases, Interaktionen, Operationen ... - - Ein- und Ausgabeparameter in Form von Objekten - - Parameterknoten entsprechend Pins der aufrufenden Aktion - - Alternativ: Parameterangabe mit Name und Typ - - Angabe von Vor- und Nachbedingungen möglich - - Optional: Parameter unter Aktivitätsnamen - -- Verfeinerung der Aktionen durch Aktivitäten -- Aktion durch Interaktionen verfeinern - - Detaillierte Diagramme - - Meist entwurfsnah -- Verfeinerung der Aktionen durch StateChart -- Objekte zusammenstellen und klassifizieren - - Toolunterstützung (Möglichkeiten stark toolabhängig) - - Objekte Ergebnis der Verhaltensmodellierung - - Ergebnis Verhaltensdiagramm: Operationen der Klassen - - Klassen generalisieren / spezialisieren $\rightarrow$ Klassenhierarchie -- Übergang zum Entwurf - - Klassenstruktur festlegen -- Spezifikation von Benutzungsschnittstellen - - Skizzieren, Prototyp generieren, Spezialwerkzeuge - - Klassen und Operationen in Funktionen - - Gestaltung MMI, style guides, Standards - -## Dokumentation von Anforderungen -- Lastenheft - - Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis - - Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien -- Pflichtenheft - - Entwurf aus AN-Sicht, Umsetzung des Lastenhefts - - Meist Vertragsbasis -- Inhalt Anforderungsspezifikation - - Zielsetzung - - Allgemeine Beschreibung - - Umgebung, generelle Funktion, Restriktionen, Benutzer - - Spezifische funktionale Anforderungen - - möglichst quantitativ (z.B. Tabellenform) - - eindeutig identifizierbar (Nummern) - - Spezifische nicht-funktionale Anforderungen - - z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform - - Entwicklungs- und Produkt-Standards - - Qualitäts-Zielbestimmung - - Zu erwartende Evolution des Systems, Versionen - - Abkürzungsverzeichnis, Glossar, Index, Referenzen - - -Pflichtenheft (Beispiel) -1. Einleitung, Zielbestimmung -2. Übersicht - - Einsatzbereich, Zielgruppen - - Produkt-Umgebung - - Produkt-Funktionen - - Restriktionen - - Annahmen und Abhängigkeiten - - Vorhandenes System (ggf.) -3. Vorgeschlagenes System - - Übersicht - - Funktionale Anforderungen - - Benutzungsschnittstelle - - Nichtfunktionale Anforderungen - - Systembeschreibung - - Szenarien - - Anwendungsfälle -4. Glossar - - -# Grobentwurf -## Einführung -Systementwurf – Aufgabe -- Sicht des geplanten Systems von innen (Entwickler) -- Wie sollen vereinbartes Verhalten und Funktionen (Analysemodell) intern realisiert werden? -- Von Spezifikation von Anforderungen und Funktionen -> Vorbereitung der Implementierung -- Formal: Transformation des Analysemodells in ein Systementwurfsmodell -- System(grob)entwurf, Feinentwurf/Objektentwurf - -Teile und herrsche -- Grobentwurf - - Entwurfsziele identifizieren - - Grobe Systemstruktur festlegen (Architektur) - - Zerlegung in Subsysteme, Spezifikation - - Schichten, Pakete, Komponenten - - Bewerten der Zerlegung anhand der Entwurfsziele - - Schnittstellen festlegen -- Feinentwurf - - Subsysteme im Detail entwerfen - - Strukturierung der Komponenten - - Klassen, Objekte, Funktionen, Datenstrukturen - - Verhalten, Algorithmen – Teillösungen - - -## Systemzerlegung -Vorgehen -- Zerlegung eines Systems in Subsysteme -- Betrachtung der Lösungsdomäne! -- Subsysteme weiter zerlegen bis Komplexität ausreichend klein ist z.B. für Arbeitspakete - -Was macht ein Subsystem aus? -- Schnittstellen, Funktionen, „Verantwortung“ -- Was bietet es an? -- Was benutzt es? -- Was tut es intern? - -Operation -- Name und Parameter -- Funktion, Prozedur, Methode, Eintrittspunkt ... - -Dienst -- Satz von Operationen, die bereitgestellt werden - -Abhängigkeiten von Subsystemen -- Subsysteme untereinander: Kopplung (coupling) -- Maß für die Abhängigkeit von Subsystemen - -Möglichst lose Kopplung -- Änderungen in einem beteiligten Subsystem haben geringe Auswirkungen (Stabilität) -- Erleichtert Wartbarkeit und Arbeitsteilung - -Mittel zur Verringerung der Kopplung -- Zusätzliche Unterteilung in Subsysteme -- Aber: dann größere Komplexität! - -Abhängigkeiten von Subsystemen -| Kopplungsart | Bemerkung | -| -- | -- | -| Datenkopplung (gemeinsame Daten) | Möglichst vermeiden! Wenn nicht möglich, Verwaltung zentralisieren und Zugriff über Schnittstelle | -| Schnittstellenkopplung (gegenseitiger Aufruf) | Akzeptabel | -| Strukturkopplung (gemeinsame Strukturelemente) | Vermeiden! (z.B. keine Vererbung über Paketgrenzen hinweg) | - -- Elemente eines Subsystems: Kohäsion (cohesion) -- Maß für Zusammengehörigkeit der Elemente -- Möglichst hohe Kohäsion - - Enge Beziehung oder ähnliche Aufgaben der Elemente - - Erleichtert Verständnis, Wartung und Anpassung -- Mittel zum Erreichen hoher Kohäsion - - Datenkapselung, Objektorientierung - - Benutzung geeigneter Patterns (Kapitel 5) - -Metriken für modulare Entwürfe -- Fan-in / fan-out-Metrik [S.Henry, D. Kafura 1981]: - - Fan-in: Anzahl der Stellen, wo Kontrollfluss auf das betrachtete Modul M übergeht (Aufrufe von Funktionen / Prozeduren in M) + Anzahl globaler Variablen, die in M zugänglich sind - - Fan-out: Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden -- Heuristik Kopplung / Kohäsion - - Hoher Fan-out bedeutet hohe Kopplung, minimieren - - Hoher Fan-in kann auf geringe Kohäsion von M hindeuten - -Komplexität beherrschen: "Wenn Du es nicht in fünf Minuten erklären kannst, hast Du es entweder selbst nicht verstanden oder es funktioniert nicht." [Rechtin, Maier: The Art of Systems Architecting 2000] - -Vorgehen: Heuristiken und Erfahrungen -- „Erfahrung ist die härteste Lehrerin. Sie gibt Dir zuerst den Test und anschließend den Unterricht.“ [Ruth 1993] -- „Ein Architekt der zu Beginn seiner Arbeit vollständige und konsistente Anforderungen benötigt, mag ein brillanter Entwickler sein – aber er ist kein Architekt“ [Rechtin 2000] -- „Das Leben von Software-Architekten besteht aus einer langen und schnellen Abfolge suboptimaler Entwurfs-entscheidungen, die teilweise im Dunkeln getroffen werden.“ [Kruchten2001] - -Wie organisiert man Subsysteme? -- Innerhalb einer Verfeinerungsstufe: fachlich orientierte Zerlegung -- Mehrfache Zerlegung: Hierarchie-Graph der Verfeinerung - -Schicht -- Gruppe von Subsystemen in der Zerlegungshierarchie -- Verwandte Dienste -- Ähnlicher Abstraktionsgrad -- Abhängigkeit nur von darunter liegenden! - -- Geschlossene Schichtenarchitektur - - Beispiel: OSI-Modell für Kommunikationssysteme -- Offene Schichtenarchitektur - - Beispiel: Java Swing auf X11-Plattform - -Prinzipien des OO-Entwurfs -- So-einfach-wie-möglich-Prinzip (KISS) -- Fehler berücksichtigen (Strukturierung, Kapselung, Modularisierung, Wiederverwendung) -- Entwerfen nach Verantwortlichkeiten -- Hohe Kohäsion / Geringe Kopplung -- Zyklische Abhängigkeiten vermeiden -- Auf Schnittstellen konzentrieren - - Abhängigkeiten nur von Schnittstellen - - Abtrennung von Schnittstellen (eher viele kleine als eine große) - - Umkehr der Abhängigkeiten (dependency inversion-Prinzip) -- Offen / Geschlossen Prinzip - -Zyklische Abhängigkeiten vermeiden -- Änderungen wirken sich auf beide Komponenten aus -- Probleme beim Löschen und Initialisieren -- Auflösen durch - - Gemeinsame Klassen in separates Paket - - Gemeinsame Schnittstellen definieren - -Symptome schlechten Designs -- Starrheit - - Einfache Änderungen schwierig realisierbar - - Einfache Änderungen führen zur Modifikation einer Vielzahl von Komponenten -- Zerbrechlichkeit - - Änderungen an einer Stelle führen zu Fehlern an völlig anderer Stelle -- Schlechte Wiederverwendbarkeit - - Komponenten können Aufgrund spezieller Anhängigkeiten kaum wiederverwendet werden - -Wann ist ein Entwurf „gut“? -- Korrekt - - Erfüllung der Anforderungen - - Wiedergabe aller Funktionen des Systemmodells - - Sicherstellung der nichtfunktionalen Anforderungen -- Verständlich und präzise, gut dokumentiert -- Anpassbar -- Hohe Kohäsion innerhalb der Komponenten -- Schwache Kopplung zwischen den Komponenten -- Wiederverwendung -- Kriterien gelten auf allen Ebenen des Entwurfs! (Architektur, Subsysteme, Komponenten) - -## Architekturmodelle -- Modellierung mit UML - - Bisher: logische Sicht - - Technisch: Organisation in Paketen, Namensraum, Import -- Paketdiagramm - - Gliederung (Strukturierung) des Systems in Teile - - Zuordnung von Elementen zu einem Paket - - Hierarchien und Abhängigkeiten zwischen den Paketen - - Anwendung: Definition von Schichten -- Enthält-Beziehung - - Definiert, in welchem Paket ein Element enthalten ist - - Ermöglicht qualifizierten Zugriff auf enthaltene Elemente - - Löschen des Pakets bewirkt Löschen beinhalteter Elemente - - Definition von Sichtbarkeit / Zugriffsrechte - - Auswirkung auf weitere Enthält-Beziehung - - '+' - public (default) - - '-' - private -- Paket- / Element-Import - - Unqualifizierter Zugriff auf Elemente eines anderen Namensraums (Paketes) -- Komponentendiagramm - - Komponente – modulare, austauschbare Einheit - - Strukturierung des Systems durch Komponenten - - Modellierung der - - Abhängigkeiten zwischen Komponenten - - inneren Struktur von Komponenten - - Definition von Schnittstellen - - Verwendung von Elementen aus Klassen- und Objektdiagramm - - Stärkere dynamische Sicht -> kein Verhalten - - Komponente <> - - Kapselt Funktionalitäten (Physisch gruppierte Klassen) - - „Spezialisierte“ Klasse (Vererbung, Exemplare möglich) - - Stellt Funktionalitäten über Schnittstellen bereit - - Definiert benötigte Schnittstellen - - Enthält Klassen oder weitere Komponenten - - Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund - - Black-Box-Darstellung - - Zur Verfügung gestellte Funktionalität `<>` - - Benötigte Funktionalität `<>`‚ - - White-Box-Darstellung - - Interner Aufbau der Komponente `<>` - - Artefakte `<>`‚ Realisierende physische Einheit (z.B.: .dll) - -Schnittstellen / Interfaces -- Definition Diagrammunabhängig - - Meist Klassendiagramm -- Ähnlich Semantik einer Klasse - - Nur public-Attribute und Operationen -- Definiert Verpflichtung zur Implementierung von - - Operationen - - Merkmale -> Attribute dürfen definiert werden - - Verpflichtungen (z.B.: Vor- / Nachbedingungen) -- Meist abstrakte Klassen mit abstrakten Operationen -- Abstrakt – muss überschrieben werden -- Notation - - Stereotyp: <> - - Meist kursiv geschrieben, da abstrakte Klasse - -Schnittstellenrealisierung, Implementierungsbeziehung -- Schnittstellen werden realisiert, nicht instanziiert -- Schnittstellenkonform - - Klasse realisiert alle Attribute und Operationen -- Schnittstelle kann von anderen Schnittstellen erben -- Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen -> Generalisierung verwenden -- Darstellung - - Gestrichelte Linie mit nicht gefülltem Dreieck an der Seite der Superklasse - - Alternativ: Lollipop-Darstellung - - -## Softwarearchitekturmuster -- Wiederverwendung auf sehr hoher Abstraktionsstufe -- Falls geplante Anwendung passt, anwenden! - -Schichten-Architektur (layers) -- Problem - - Komplexität: Strukturierung des Systems, unterschiedliche Abstraktionsebenen - - Änderungen sollen möglichst lokal bleiben - - Teilsysteme sollen austauschbar, wiederverwendbar und getrennt entwickelbar sein - - Schnittstellen sollen stabil sein -- Lösung - - Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene - - Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an - -Client-Server (Klient/Anbieter) -- Client (front-end) - - Benutzungsschnittstelle - - Einbindung in Geschäftsprozesse - - Entkoppelt von Netztechnologie und Datenhaltung -- Server (back-end) - - Datenhaltung, evtl. Fachlogik -- Genauer: Two-tier client/server architecture -- Asynchroner Kontrollfluss -- Aufteilung Funktionen Client / Server - - Mehr Funktionen im Server: - - zentrale Verwaltung, Wartungsaufwand geringer, Portabilität, einfache Client-Hardware (Net PC) - - „Thin Client“ – nur GUI - - Mehr Funktionen im Client: Flaschenhals Server wird entlastet, individuellere Client-Funktionen - - „Fat Client“ – Teil der Anwendung im Client - - Entscheidet mit über Umsetzung (Java Script, ...) - -Three-Tier / Four-Tier Architecture -- Client/Server mit weiterer Aufteilung ähnlich Repository - -Bewertung Client-Server -- Vorteile - - Leicht verständlich - - Änderungen bleiben lokal - - Geringere Kopplung zwischen den Schichten - - Schichten austauschbar und wiederverwendbar - - Getrennte Entwicklung der Schichten möglich - - Vorhandene / stabilere Schnittstellen -- Nachteile - - Geringere Performance - - Zusätzlicher Verwaltungs- oder Datenoverhead - - Manche Änderungen führen zu Änderungen in allen Schichten (z.B. neues Datenfeld) - -Pipes and Filters -- Datenstrom- oder Kontrollflussorientiertes System -- Lose verbundene Berechnungskomponenten -- Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig -- Leicht erweiterbar System gewünscht -- Parallele Verarbeitung vorteilhaft -- Verwendung von globalen Steuerungskontrollstrukturen (Parallelisierung, Verzweigung, Schleifen) gewünscht -- Vorteile - - Stark entkoppelte Komponenten - - Hohe Flexibilität gegenüber Änderungen & Erweiterungen - - Hoher Wiederverwendungsgrad der Komponenten - - Unabhängige Entwicklung der Komponenten - - Leichte Parallelisierung der Berechnungen möglich - - Überprüfung der Datenkompatibilität dynamisch / statisch -- Nachteile - - Schwierige Fehlerbehandlung, kein expliziter Kontrollfluss - - Fehler durch inkompatible Datentypfehler erst zur Laufzeit - - Häufig zusätzliche Datenkonvertierungen notwendig - - -Plug-In Architektur (Microkernel) -- Zielstellung - - Stabile, verbreitete Standard-Anwendung (Kern) - - Funktionalität soll durch Komponenten leicht erweiterbar sein - - Dritte sollen Komponenten leicht erstellen können -- Lösung - - Möglichst schlanker zentraler Kern - - Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration -- Plugin - - Komponente mit Standard-Schnittstelle - - Erweitert Funktionalität (extension point) -- Vorteile - - Robustes Verhalten - - Trennung der Zuständigkeiten - - Erweiterbar, Austauschbar, Wiederverwendbar - - Geringe Kopplung zu den Komponenten - - Anpassung an eigene Bedürfnisse möglich - - Leichte Aufteilung der Entwicklung der Arbeitspakete -- Nachteile - - Höherer initialer Aufwand - - Verwaltungsoverhead zur Laufzeit - - Versionsverwaltung der Komponenten nötig - - Abhängigkeiten unter den Komponenten schwierig realisierbar - - Geschickte Definition der Extension Points nötig - -Repository (Depot, blackboard) -- Zentrale Datenhaltung - - Datenbankmanagementsystem, Dateisystem -- Anwendungen tauschen Daten nur über Repository aus -- Kontrollfluss z.B. über Signale oder Semaphore -- Gut für datenintensive Verarbeitungsaufgaben geeignet - -Peer-to-peer -- Gleichberechtigte Partner, “Föderation” -- Verteilte kommunizierende Subsysteme -- Orts- und Umgebungsunabhängigkeit - -Model-View-Controller (MVC) -- Modell / Sicht / Steuerung -- Trennung verschiedener Aufgabengebiete: - - Model: verwaltet Domänenwissen, Daten und Zustand; häufig Datenbank - - View: Darstellung, Anzeige, GUI - - Controller: Steuerung der Interaktion, Nutzerbefehle -- Erlauben Austausch von Anzeige- und Speichersystem -- Kontrollfluss - - Controller steuert - - View wird über Datenänderungen benachrichtigt (callback) -- Geeignet für interaktive Systeme -- Problem - - Lose Kopplung zwischen verschiedenen Komponenten - - Daten werden in verschiedenen Sichten dargestellt - - Realisierung von GUI‘s -- Lösung durch drei Komponenten - - Daten (Model) enthält die Kernfunktionalität / Durchführung der Geschäftsprozesse, kapselt und Speichert die Daten - - Sichten bzw. Dialoge (View) stellt die Daten für den Anwender in unterschiedlicher Art dar - - Logik bzw. Steuerung (Controller) Realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell, legt die Darstellungsart der Sichten fest -- Vorteile - - Unabhängige Entwicklung der Komponenten - - Änderung der Oberfläche ohne Änderung des Modells - - Unterschiedliche Oberflächen für das selbe Modell -- Nachteile - - Performance - - Erhöhter initialer Entwicklungsaufwand - - -## Frameworks -Was ist ein Framework? -- A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize for specific computing solutions [Taligent] -- Ein framework (Rahmenwerk, Anwendungsgerüst) ist eine Menge von zusammengehörigen Klassen, die einen abstrakten Entwurf für eine Problemfamilie darstellen [nach Pomberger/Blaschek] - -Ziele -- Wiederverwendung von Code, Architektur, Entwurfsprinzipien und Verhaltensschema -- Ähnliche Benutzungsschnittstelle - -Klassifikation I -- Anwendungs-Framework (application framework) - - Gibt Systemarchitektur für typische Anwendungsstruktur vor - - GUI-Framework: Motif, Qt, Swing, ... -- Bereichsspezifisches Framework (domain framework) - - Expertenwissen für Anwendungsbereich - - für typische Anwendungen u.a. in den Bereichen Luftfahrt, Produktion, Finanzwesen, Automotive, ... - - Beispiel: AUTOSAR -- Infrastrukturgerüst (support framework) - - Gerätetreiber, Anpassung an Hardware - - Middleware: DCOM, Java RMI, CORBA, WebSphere, ... - -Klassifikation II -- Offene Programmgerüste (white box) - - Erweiterbarkeit durch Vererbung und dynamische Bindung - - Funktionen konkretisieren durch Ableitung von Basisklassen des Programmgerüsts und Überschreiben vordefinierter Methoden -- Geschlossene Programmgerüste (black box) - - Erweiterbarkeit durch Definition von Schnittstellen für Module, die für eine konkrete Anwendung in das Gerüst eingesetzt werden können - - Wiederverwendung durch Komponenten, die sich an Schnittstellen halten; Aufruf über Delegation - - -Webframeworks – Angular JS -- Clientseitiges Webframework von Google -- Frei verwendbar (Open Source) -- Erstellung von Single-Page-Webanwendungen -- Model View Prinzip - -- Vorteile - - Weitergabe von Expertenwissen - - Durchdachtes Design: langfristige Aufwandsersparnis - - Wartungsaufwand reduziert, systematische Tests möglich - - Prinzipiell sehr hohe Produktivität möglich - - Erleichtert Integration und Konsistenz verwandter Anforderungen -- Nachteile - - Erstellung und Einarbeitung aufwändig - - Zusätzlicher Dokumentations- und Wartungsaufwand - - Fehlersuche erschwert durch Overhead des Frameworks - - Kombination verschiedener Frameworks sehr schwierig - -## Systemarchitektur und Verteilung -Systemarchitektur -- Aufbau und Elemente der Ablaufumgebung, Hardware -- Häufig enger Zusammenhang mit Softwarearchitektur - - Architekturmuster - - Ablaufmuster -- Besonders bei eingebetteten Systemen -- Systemarchitektur hat Einfluss auf Softwarearchitektur - - Grenzobjekte, Schnittstellen, ... -- Gute Systemarchitektur? - - Nichtfunktionale Anforderungen - - Modellierung und Simulation, Lastmessungen - - -Typische Strukturen -- Zentralrechner (mainframe) mit Terminals -- Server und einfache Stationen -- PCs und Server -- Kommunikationsverbindungen, Sensoren, Speicher, ... - - -- Blockdiagramm - - Klassisches Beschreibungsmittel für Systemaufbau - - Nicht Teil von UML -- Konfigurationsdiagramm - - meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten - - Nicht Teil von UML -- Verteilungsdiagramm (UML deployment diagram) - - Darstellung der Hardwaretopologie - - Zuordnung von Artefakten zu Hardwareeinheiten (Knoten) - - Verteilung von Systembestandteilen auf Hardware - - Kommunikationsverbindung und Abhängigkeiten zwischen Knoten - - Relativ spät im Projekt Installation / Wartung des Systems - -## Globaler Kontrollfluss -Globaler Kontrollfluss -- Ablaufsicht der Architektur - - Definition nebenläufiger Systemeinheiten (z.B. Prozesse) - - Steuerung der Abfolge von Einzelfunktionen - - Synchronisation und Koordination - - Reaktion auf externe Ereignisse - - Darstellung z.B. durch Sequenzdiagramme -- Nebenläufigkeit auf Architekturebene - - Threads , Prozesse, verteiltes System - - Asynchroner Nachrichtenaustausch -- Einfluss auf Architektur / abhängig von Architektur! -- Ablaufmuster - - Zentral - - Call/Return (prozedural, synchron) - - Master/Slave (nebenläufig mit zentraler Steuerung) - - Dezentral - - Ereignisgesteuert (event-driven) - - interrupts - - publish-subscribe (ähnlich observer) - - (selective) broadcast - - Datenflussgesteuert (data flow architecture) - -## Sonstiges -Ablauf des OO-Systementwurfs [B. Oesterreich] -- Schichtenmodell definieren -- Verteilungsmodell definieren -- Fachliches Subsystemmodell definieren -- Ablaufverantwortlichkeiten definieren -- Komponentenspezifisches Klassenmodell entwickeln -- Komponentenschnittstelle entwerfen -- Zustandsmodelle weiterentwickeln -- Objektfluss modellieren -- Interaktionsmodelle entwickeln, Attribute definieren -- Dialoge spezifizieren -- Design-Diskurs -- Testgetriebene Entwicklung - -Weitere Aufgaben beim Grobentwurf -- Entwurf einer persistenten Datenverwaltung - - Dateisystem, Datenbank -- Sicherheit - - Zugriffskontrolle - - Fehlertoleranz (Daten und Hardware) - - Protokollfunktionen -- Kontrollfluss - - Ausnahmen - - Starten, Initialisieren und Beenden der Anwendung - - „Randanwendungsfälle“ - -Notwendigkeit der Architekturdokumentation -- Quellcode aufgrund niedrigen Abstraktionsniveaus ungünstig für Dokumentation -- Überblick und Arbeitsteilung -- Lebensdauer von Systemen länger als geplant -- Fehler und Probleme leichter finden und beseitigen -- Neue Anforderungen mit angemessenem Aufwand erfüllen -- Vereinfachung der Wartung, Pflege, Erweiterung, Wiederverwendung - -## Dokumentation -- Grundprinzipien - - Verständlich aus Sicht des Lesers formulieren (Glossar) - - Das Warum beschreiben (Entwurfsentscheidungen) - - Annahmen, Voraussetzungen, Randbedingungen dokumentieren - - Wiederholungen vermeiden - - Notation erklären oder Standards verwenden (UML) - - Legende hinzufügen - - Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität) - - Verschiedene Sichten für verschiedene Zielgruppen - -# Feinentwurf - -| Analyse-Modell | Entwurfs-Modell | -| -- | -- | -| Fachliche Domäne | Lösungsdomäne | -| Teilweise unvollständig in Attributen und Operationen | Vollständige Angabe aller Attribute und Operationen | -| Datentypen und Parameter können noch fehlen | Vollständige Angabe von Datentypen und Parametern | -| Noch kaum Bezug zur Realisierungssprache | Auf Umsetzung in gewählter Programmiersprache bezogen | -| Keine Überlegungen zur Realisierung von Assoziationen | Navigationsangaben, Qualifikation, Ordnung, Verwaltungsklassen | -| | Entscheidung über Datenstrukturen, Anbindung GUI | - -Schließen der Lücke zwischen Grobentwurf und Implementierung -- Identifizieren und Entwerfen von Klassen der Lösungsdomäne -- Identifikation und Verwendung von Entwurfsmustern -- Detaillierte Beschreibung der Klassen -- Beschreibung von Schnittstellen -- Iterativer Prozess! - - Verbesserung des Entwurfs – Refactoring - - Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen - -Objektorientierter Feinentwurf -- Ausgangspunkt - - Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen) - - Verteilungskonzept - - Ablaufmodell -- Ergebnis - - OO-Modell für jedes Subsystem der Architektur - - OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien - - Spezifikationen der Klassen - - Spezifikationen von externen Schnittstellen - -## Klassen- und Objektentwurf -- Klassen der Lösungsdomäne - - Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen -- Entstehungsgründe - - Architektur von Software und System - - nichtfunktionale Anforderungen - - Beispiele: Kommunikation, Fehlertoleranz, Adapter, Datenhaltung, Effizienz, Benutzerschnittstellenobjekte, Middleware, ... - - Sichtbare (Grenz- und Steuerungsobjekte) werden schon in der Analyse identifiziert - -Klassen identifizieren (responsibility-driven design (Wirfs-Brock, McKean)) -> Verantwortlichkeits-Prinzip: Sichtweise: Objekte und Klassen sind nicht nur Behälter für Verhalten und Daten, sondern erfüllen in Zusammenarbeit mit anderen Objekten bestimmte Aufgaben eigenverantwortlich - -Responsibility-Driven Design – Begriffe -- Sichtweise auf Softwaresystem -- Application = set of interacting objects -- Object = implementation of role(s) -- Role = set of related responsibilities -- Responsibility = obligation to perform a task or know information -- Collaboration = interaction of objects or roles -- Contract = agreement outlining collaboration terms - -Arten von Rollen -||| -|--|--| -| Information holder | knows and provides information | -| Structurer | maintains relationship between objects and information about relationships | -| Service provider | performs work, offers computing services | -| Coordinator | reacts to events by delegating tasks to others | -| Controller | makes decisions and directs other’s actions | -| Interfacer | transforms information and requests between system parts | - -Hilfsmittel: CRC-Karten -- Candidate (or class), Responsibility, Collaboration -- Informelles Mittel zum - - Finden, - - Beschreiben und - - iterativen Verändern von Klassen - -Ein Objekt -- implementiert eine Schnittstelle und beeinflusst andere Objekte -- wird in drei Teilen entworfen - - Öffentliche Schnittstelle - - Art und Weise der Benutzung - - Innere Details der Funktionsweise -- Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren! - - -## Entwurfsprinzipien -- Kapselung - - Probleme: Zugriff auf private oder ebenen-fremde Attribute - - Verwenden von get- und set-Operationen - - Zusicherungen einhalten - - Zugriffe zentralisieren - - Verbalisierung - - Zugriffsbeschränkung -- Zerlegung - - Teile und Herrsche - - Zerlegen in Komponenten - - Verantwortlichkeitsprinzip: Komponente ist klar für eine Aufgabe verantwortlich - - Eigenschaften und Schnittstellen im Klassendiagramm - - Beziehungen zwischen Klassen: Assoziationen - - Aggregation - - „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“ - - Schwache Bindung der Teile mit dem Ganzen - - Notation: ungefüllte Raute am Ganzen - - Komposition - - Wie Aggregation, jedoch stärkere Bindung - - Teil nur einem Ganzen zugeordnet - - Nur Multiplizität von 1 oder 0..1 möglich! - - Gefüllte Raute am Ganzen -- Polymorphie - - Reaktion auf eine Nachricht abhängig vom Typ des Objektes - - Variablen können Objekte verschiedener Klassen aufnehmen (Voraussetzung: Typ der Variablen ist eine gemeinsame Basisklasse der (davon) abgeleiteten Klasse(n) der Objekte) - - Überladen von Operationen - - gleicher Operationsname, unterschiedliche Signatur - - abstrakte Operationen: Virtuelle Operationen ohne Implementierung - - abstrakte Klasse: Klasse mit abstrakten Operationen - - Folgen - - von abstrakten Klassen können keine Objekte angelegt werden (Implementierung fehlt) - - Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können - -Vererbung im Entwurf -- In der Analyse: Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien -- Verringerung von Redundanz und damit Inkonsistenzen - - Funktionalität nur einmal implementieren! - - Spezifikations-Wiederverwendung - - Implementierungs-Wiederverwendung -- Verbesserung der Erweiterbarkeit - - Abstrakte Schnittstellen einsetzen! - -Vererbung oder Assoziation -- Schlüsselwort Vererbung: ist ein -- Schlüsselwort Assoziation: besteht aus, ist Teil, hat,... -- Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator) -- Vermeide Vererbung, wenn es Alternativen gibt -- Mehrfachvererbung - - Problem: Unabhängige Aspekte der Vererbungshierarchie - - Vermeidung: abstrakte Klassen oder Komposition - -Abstrakte Klassen -- Nur Unterklassen, keine Instanzen -- Attribute in Unterklassen füllen -- Notation: Kursiv oder Stereotyp <> - -Offen / Geschlossen-Prinzip [Meyer 1988] -- Erweiterbarkeit eines Entwurfs -- Offen für Erweiterungen, - - z.B. durch Vererbung / Polymorphie - - Virtuelle Operationen verwenden - - Verändert vorhandenes Verhalten nicht - - Erweiterung um zusätzliche Funktionen oder Daten -- Geschlossen für Änderungen - - private Attribute - - Möglichst protected Operationen -- Beschränkung der Erweiterbarkeit - - Keine Einschränkungen der Funktionalität der Basisklasse! - -Liskovsches Ersetzungsprinzip -- Wenn S eine Unterklasse von T ist, dann können Objekte des Typs T in einem Programm durch Objekte des Typs S ersetzt werden, ohne die Funktion des Programms zu verändern. [Barbara Liskov 1987] -- Engere Definition als „ist-ein“-Beziehung -- Kein unerwartetes Verhalten eines Objektes eines Subtyps -- Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren -- Zusicherungen der Basisklasse müssen von der abgeleiteten Klasse erfüllt werden! - -Gesetz von Demeter (LoD) -- Gesetz von „schüchternen“ Objekten -- Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren -- Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ... - - unmittelbarer Bestandteil des Objekts von M sind (super) - - M als Argument übergeben wurden - - direkt in M erzeugt wurden - - (oder sich in globalen Variablen befinden) -- Als Metrik überprüfbar - -Ein Objekt sollte -- Nur Methoden aufrufen, die zur eigenen Klasse gehören -- Nur Methoden von Objekten aufrufen, die: - - Von Attributen referenziert werden - - Als Parameter übergeben wurden - - Selbst erzeugt wurden - - -## Entwurfsmodelle -Klassendiagramm -- Eigenschaften - - Modellierung der statischen Struktur (Aufbau) - - Modellierung der Struktur von Daten - - Klasse im Mittelpunkt (Aufbau, Beziehungen zueinander) - - Wichtigstes und bekanntestes Diagramm der UML! -- Elemente des Klassendiagramms - - Klasse (Attribute, Operationen) - - Vererbung / Realisierung - - Assoziationen - - Beziehungen / Abhängigkeiten -- Attribute - - Klassenattribut: "X" static – statisch, nur einmal pro Klasse vorhanden - - Sichtbarkeit - - "+" public – im Namensraum sichtbar - - "#" protected – nur in abgeleiteten Klassen sichtbar - - "~" package – im Paket sichtbar - - "-" private – nur in der Klasse selbst sichtbar - - Ableitung "/" derived – abgeleitetes Attribut -- Weitere Eigenschaften - - readOnly – nach Initialisierung nicht änderbar - - composite – Aggregation: Composition - - redefines X – überschreibe Attr. der Oberklasse - - subsets X – Teilmenge - - union – Attribut ist Vereinigung der subsets - - unique – Elemente eindeutig (Schlüsselattribut) - - ordered – Elemente sind geordnet (unordered) - - sequence – Speicherung der Elemente als Liste - - bag – Elemente sind Multimenge -- Parameterlisten - - in: Eingangsparameter - - out: Ausgangsparameter - - inout: Eingangs- und Ausgangsparameter - - return: Rückgabewert -- Beziehungen - - navigierbar/unspezifiziert/nicht-navigierbar - - ungerichtete/gerichtete Relation/assoziation - -Aktive Klassen -- Reagieren nicht nur, sondern werden von sich aus aktiv -- Z.B. Steuerobjekte -- Als Thread oder Prozess realisiert - -## Schnittstellen -- Vereinbarung über Art des Aufrufs - - Homogenität gleicher Funktionen - - Enthält - - Spezifikation von Operationen - - keine Implementierung ( Java, nicht UML!) - - keine Attribute - - In Java außerdem anstelle von Mehrfachvererbung -- Schnittstellen in UML - - Funktion ähnlich abstrakter Klasse - - Meist für technische Aspekte - - Notation: Stereotyp <> oder grafisch (lollipop notation) -- Verträge („design by contract“) - - Schnittstelle sagt bisher nichts über Effekt der Klasse aus - - Vollständige Beschreibung wäre Programm? - - Vereinfachte Beschreibung für Abfolgen: - - Vorbedingung: Prädikat, das vor Aufruf gelten muss <> - - Nachbedingung: Prädikat, das nach Aufruf gelten muss <> - - Invariante: Prädikat, das immer gilt <> - - Jeweils Einschränkungen! - -Protokollrollen - Dynamisches Verhalten von Schnittstellen -- Ohne Sicht auf innere Implementierung (anders als beim Objektlebenszyklus) -- Protokoll = Kollaboration von Protokollrollen (protocol, protocol role) -- Modell: Zustandsautomat - - Genauer: Spezialisierung - - Beschreibung der Synchronisation von Objekten - -## Entwurfsmuster -- Warum Wiederverwendung? - - Geringerer Aufwand - - Das Rad nicht noch einmal neu erfinden - - Verwenden üblicher, aus Erfahrung gewachsener Strukturen -- ... und warum nicht? - - Aufwand für Anpassung kann hoch sein! - - Einarbeiten in teilweise komplexe Schnittstellen - - Abhängigkeit von externen Komponenten, Zwang zu späterer Portierung - -> Was ist ein Entwurfsmuster? Eine schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster) -- Wie helfen Muster im Entwurf? - - Identifizieren von Klassen (Anwendungs- und Lösungsdomäne) - - Regeln sind abstrakt oder an realen Objekten orientiert - - Muster: Arten von Rollen bzw. Lösungshinweise für typische Strukturierungsaufgaben - - Änderbarkeit und Lesbarkeit des Entwurfs verbessern -- Arten von Entwurfsmustern - - Erzeugungsmuster - - Strukturmuster - - Verhaltensmuster -- Erzeugungsmuster - - Factory Method, Fabrikmethode - - Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert - - Abstract Factory, Abstrakte Fabrik - - Schnittstelle zur Erzeugung von Familien verwandter Objekte - - Prototype, Prototyp - - Objekterzeugung durch Vorlage und Kopie - - Builder, Erbauer - - Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen - - Singleton - - Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet - -Strukturmuster -- Adapter - - Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle -- Bridge, Brücke - - Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis -- Decorator, Dekorierer - - Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen) -- Facade, Fassade - - Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff -- Flyweight, Fliegengewicht - - Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand) -- Composite, Verbund, Kompositum - - Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur -- Proxy, Stellvertreter - - Kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt - - Gründe: Schutz, entfernter Zugriff (remote proxy), smart pointer, Erzeugung on demand - -Adapter -- Vorteile - - Kommunikation unabhängiger Softwarekomponenten - - Einfache Erweiterung um zusätzliche Funktionalität - - Austausch der Komponente durch Änderung des Adapters leicht möglich -- Nachteile - - Zusätzlicher Adaptierungsschritt benötigt Zeit - - Schlechte Wiederverwendbarkeit der Adapter -- Bekannte Verwendung, Spezialfälle - - Fassade: Adapter eines Teilsystems - - Proxy: erweitert die Funktionalität bei gleicher Schnittstelle - - Brücke: keine Anpassung, sondern vorherige Strukturierung - -Verhaltensmuster -- Command, Befehl - - Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen) -- Observer, Beobachter - - 1-zu-n-Beziehung zwischen Objekten, so dass die Änderung des zentralen Objekts zu einer Benachrichtigung und Aktualisierung der n (abhängigen) Zustände führt -- Visitor, Besucher - - Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird -- Interpreter - - Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache -- Iterator - - Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung -- Memento - - Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können -- Template Method, Schablonenmethode - - Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden -- Strategy, Strategie - - Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte -- Mediator, Vermittler - - Objekt, welches das Zusammenspiel einer lose gekoppelten Objektmenge in sich kapselt. Vermeidet direkten Bezug der Objekte untereinander und ermöglicht unabhängige Änderung des Zusammenspiels -- State, Zustand - - Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt -- Chain of Responsibility, Zuständigkeitskette - - Vermeidet direkte Kopplung von Auslöser und Empfänger einer Anfrage bzw. Operation. Mehrere Objekte werden nacheinander benachrichtigt, bis die Anfrage erledigt ist - -Bewertung Observer -- Vorteile - - Entkopplung von Komponenten und Schichten möglich - - Broadcast und selective Broadcast möglich -- Nachteile - - Bei vielen Beobachtern: Benachrichtigung aufwendig - - Unerwartete Änderung, Änderungskaskaden und Rekursion - - Abmelden der Beobachter vor dem Löschen -- Bekannte Verwendung, Spezialfälle - - Verwendung im Model-View-Controller Muster - - Qt: Signal / Slot-Prinzip ähnlich - -Anwendung von Entwurfsmustern -- Untersuche Anwendbarkeit und Konsequenzen -- Analysiere Struktur, Teilnehmer und Kollaborationen -- Wähle aus dem Anwendungskontext Namen für Teilnehmer -- Spezifiziere die teilnehmenden Klassen - - Deklariere Schnittstellen, Vererbung und Variablen - - Identifiziere existierende Entwurfsklassen, die durch das Muster beeinflusst werden -- Wähle anwendungsspezifische Namen für Operationen -- Implementiere Operationen entsprechend den Verantwortlichkeiten und Kollaborationen des Musters - -## Klassenbibliotheken und Komponenten -Klassenbibliotheken -- Zusammenfassung von Modulen, Klassen, etc. -- Mit einem bestimmten (abstrakten) Zweck - - Abstrakte Datenverwaltung, Templates - - Grundlegende System-Aufgaben - - Untere Kapselungs-Schicht des Laufzeitsystems oder der Programmierumgebung - - Numerische Routinen, Simulation, ... -- Wird in Anwendung eingebunden (importiert), API - - Objekte instanziieren oder Klassen ableiten -- Meist passiv: Kontrollfluss wird von Anwendung gesteuert -- Beispiele: stdlib, MFC, GNU scientific library, Java 3D, IPP - -Komponentenbasierte Entwicklung -- Bausteinorientierte Programmierung (component-ware) -- Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen -- Entsprechung für Wiederverwendung: Generische Bausteine (components) - - Anpassbar, zusammensetzbar -- Werkzeuggestützte bzw. grafische Kompositionsmechanismen -- Beispiele: Java Beans, Enterprise Java Beans (EJBs), Microsoft COM+ -- Komponenten-Entwicklung oft auch projektspezifisch -- Warum Komponenten - - Monolithische, proprietäre Software führt zunehmend zu Problemen - - Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung - - Zusammensetzen der Funktionalität aus standardisierten Elementen, die über offene Schnittstellen kommunizieren - - Komponenten sollen Flexibilität bei sich ändernden Anforderungen erhöhen - - Weg aus der „Software-Krise“? -- Eigenschaften von Komponenten - - müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein - - Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen - - Kapseln ihre angebotenen Funktionen - - Werden immer als ganze Einheit eingesetzt; alle Bestandteile sind enthalten (Archiv-Datei) - - Sind nicht von Kopien ihrer selbst unterscheidbar - - Klare Spezifikation der Schnittstelle nötig; explizit definierte Interaktionen mit Komponenten und Umgebung - - Komposition durch Dritte: Endbenutzer, Komponenten-Hersteller und Komponenten-Integrator; meist nur kompilierter Code verfügbar - -Komponenten für Client/Server-Architekturen -- Wichtige Aspekte - - Transaktionen - - Sicherheit - - Ressourcenverwaltung - - Persistenz -- Komponentenkonzept für Server-Komponenten - - meist unsichtbare Komponenten - - standardisierte Realisierung der wichtigen Eigenschaften für Client/Server-Anwendungen - - Realisierung: Enterprise Java Beans (EJBs) innerhalb eines Java Enterprise Edition Servers - -## Dokumentation -Dokumentation des Feinentwurfs -- Möglichkeiten - - Eigenständiges Dokument - - Erweiterung des Lastenhefts / Grobkonzepts - - Eingebettet in den Quellcode (Werkzeug, z.B. Javadoc) -- Inhalt - - Ähnlich Grobkonzept - - Zusätzlich detaillierte Modelle - - Abwägungen des Objektentwurfs - - Klassenschnittstellen - -# Implementierung -Aufgaben der Implementierung -- Aus Spezifikationen Programm(code) erzeugen -- Aufbauend auf Ergebnissen des Feinentwurfs - - Algorithmen konzipieren - - Datenstrukturen realisieren - - Umsetzen in konkreter Programmiersprache - - Dokumentation - - Untersuchung des Zeit- und Speicherbedarfs - - Test und Verifikation -- „Programmieren im Kleinen“ - -## Konventionen und Werkzeuge -Konventionen beim Programmieren -- (Coding Rules, -conventions, -standards) -- Regeln für verständliche Programme - - „wie“ sollte Quellcode formal und strukturell gestaltet sein - - Bezeichner, Einrückungen, Dokumentation, Dateien, ... - - Strukturierung: Block, Methode, Klasse, Package -- Firmenspezifische Regeln - - Festlegung Entwurfsprinzipien (z.B. keine Mehrfachvererbung) - -Namenskonventionen -- Klasse - - (mit) Substantiv, „UpperCamelCase“ - - Beispiele: Account, StandardTemplate -- Methode - - (mit) Verb, Imperativ (Aufforderung), „lowerCamelCase“ - - Beispiele: checkAvailability(), getDate() -- Attribut, Variable - - (mit) Substantiv, „lowerCamelCase“ - - Beispiele: anzahlAutos, fensterBreite -- Konstante - - Nur Großbuchstaben, Worte mit "_" zusammengesetzt - - Standardpräfixe: "MIN_", "MAX_", "DEFAULT_", ... - - Beispiele: NORTH, BLUE, MIN_WIDTH, DEFAULT_SIZE - -Formatierungs-Richtlinien -- Entsprechend Schachtelungstiefe einrücken, aber nicht zu weit -- Einheitliche Verwendung von Leerzeilen und Leerzeichen -- Einheitliche Dateistruktur verwenden - - Eine .java-Datei pro Klasse - - Ein Verzeichnis für jedes package -- Werkzeuge: source beautifier, oft in IDEs enthalten -- Editor: syntax highlighting -- Navigationswerkzeuge - - Auf- und Zuklappen, Inhaltsverzeichnis, tagging - - doxygen, Eclipse etc. - -Änderungsfreundlicher Code -- Wahl von Variablen, Konstanten und Typen orientiert an der fachlichen Aufgabe, nicht an der Implementierung: - - `typedef char name [NAME_LENGTH]` - - `typedef char firstName [FIRST_NAME_LENGTH]` -- Symbolische Konstanten statt literaler Werte verwenden, wenn spätere Änderung denkbar -- Algorithmen, Formeln, Standardkonzepte in Methoden/Prozeduren kapseln -- Übersichtlichkeit: Zusammenhängende Einheit nicht größer als Editorfenster (40-60 Zeilen, 70 Zeichen breit) -- Strukturierte Programmierung (Regeln je nach Schärfe) - - Kein goto verwenden (in anderen Sprachen als Java) - - switch nur mit break-Anweisung nach jedem Fall - - break nur in switch-Anweisungen verwenden - - continue nicht verwenden (Effekt ähnlich goto) - - return nur am Ende zur Rückgabe des Werts -- Übersichtliche Ausdrücke - - Seiteneffektfreie Ausdrücke, schlecht: y += 12*x++; -- Variablen möglichst lokal und immer private deklarieren -- Wiederverwendung "äußerer" Namen vermeiden - -Werkzeuge -- Integrated Development Environments (Eclipse, KDevelop) -- Compiler, Linker; Build / Make; Versionskontrolle (git, svn) - -## Code-Qualität -Portierbarer Code -- Code, den man ohne Änderungen in ein anderes System (Compiler, Betriebssystem, Rechner) übertragen kann - - Kein implementierungsabhängiges Verhalten! -- ANSI C++ Standard ist nicht vollständig definiert -- Ist das Verhalten nicht festgelegt, unterscheidet der ANSI C++ Standard zwischen: - - Implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten -- Code, welcher auf implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten basiert, ist - - Nicht portabel und somit häufig verboten - - Wird unter Umständen ungewollt wegoptimiert - -Implementierungsabhängiges Verhalten -- Compiler übersetzen bestimmte Sprachkonstrukte unterschiedlich, Ergebnis unterscheidet sich -- Voraussetzung - - Verhalten ist konsistent festgelegt und dokumentiert - - Kompilierung von standardkonformem Code ist erfolgreich -- Beispiel: Speichergröße von Integer-Typen - - char kann signed oder unsigned sein: Nicht damit rechnen! - - 32 Bit System ist wie erwartet - - 16 Bit System: Multiplikation wird mit int durchgeführt -> Überlauf -> undefiniertes Verhalten - -- Unspezifiziertes Verhalten - - Wie implementierungsabhängiges Verhalten - - Compiler muss sich für ein bestimmtes Verhalten entscheiden - - Muss nicht dokumentiert sein - - Beispiel: Evaluierungsreihenfolge von Funktionsargumenten `tuWas(zuerstDas(),oderDochLieberDas());` -- Undefiniertes Verhalten - - Keinerlei Vorgaben - - Compiler muss mögliches Problem nicht melden - - Keine Voraussage welches Resultat eintritt - - Bereits die Kompilierung kann fehlschlagen - - Oder das laufende Programm kann falsche Resultate liefern. - - Effekt: „Bei mir läuft es aber!?“ - - „undefiniertes Verhalten nutzen grenzt an Sabotage!“ - -Sicherer Code mit const -- Const Variable – Konstante - - Stellt sicher, dass sich der Wert nicht verändert -- Const Parameter - - Übergabeparameter ändert sich nicht innerhalb der Operation - - Z.B. bei Übergabe komplexer Daten als Referenz bzw. Zeiger `long calcMeanValue(const image &i){...}` -- Const Operationen - - Sicherstellen, dass Operation das Exemplar nicht ändert - - Aufruf der const Operation bei const Variablen möglich -- Verwende const wenn möglich - - -## Dokumentation -- Selbstdokumentierende Programme? - - 2001 Int. Obfuscated C Code Contest Winner, Short Program - -Integrierte Dokumentation -- Verständlichkeit, Wartbarkeit – auch für Programmierer! -- Code selbst sollte möglichst verständlich sein -- Dokumentation in Programm schreiben und aktualisieren -- Beschreibung der Bedeutung des Codes! -- Als Konventionen festschreiben -- Programmvorspann -- Kurzbeschreibung Datei / Klasse / Funktion ... -- Verwaltungsinformationen - - Autor, Datum, Version, Projekt, ToDo, FixMe, ... - - Zustand: geplant, in Bearbeitung, vorgelegt, akzeptiert -- Laufende Kommentare im Quellcode - -Programmierer-Dokumentation -- Als eigenes Dokument elektronisch oder gedruckt -- Einstieg in Programmverständnis (z.B. Bachelor-Arbeit) -- Konsistenz mit Quelltext? Verweise? -- Technische Unterstützung: JavaDoc (Java), doxygen (C++) -- Ergänztes Java-Programm  Dokumentation HTML, PDF, - ```js - /** @author name Mustermann */ - /** @param name description */ - /** @return description */ - ``` - -Benutzerdokumentation -- Benutzer-Handbuch, Online-Dokumentation -- Unterstützung ohne Support? -- Vollständige und fehlerfreie Beschreibung der Benutzung - - Beispiele, screen shots -- Arten: Tutorial, Beschreibung, Referenz - -Benutzer-Unterstützungssysteme -- Integrierte Hilfe (Suchfunktion, balloon help / tool tips) -- Assistenz-System (Zustandsabhängige Anleitung) -- Tutor-System zum Erlernen -- Bug-Listen, Mailinglisten, Diskussionsforen - -## Codegenerierung -Bezug zwischen Modell und Programmcode -- Vorwärtsmodellierung: Modell - Code -- Rückwärtsmodellierung: Code - Modell - - Außerdem: Modelltransformation, Refaktorisierung -- Idealfall: Automatische Übersetzung durch SW-Werkzeug (in beiden Richtungen) - - „Modellbasierte Entwicklung“ -- Statisch: Beispiel Klassendiagramm - Quelltext der Klassen mit allen Vererbungsbeziehungen, Attributen und Methodensignaturen (Klassen-Stümpfe mit leeren Methodenrümpfen zum Ausfüllen) -- Dynamisch: Beispiel Zustandsdiagramm - Quelltext der Zustandssteuerung einer Klasse - -![Codegenerierung](Assets/Softwaretechnik1_Codegenerierung.png) - -Weitere statische Transformationen -- Abbildung von Assoziationen auf Sammlungen -- Abbildung von Verträgen auf Ausnahmen -- Abbildung von Objektmodellen auf Datenbankschemata -- Abbildung von Entwurfsmustern auf Codefragmente - -Optimierung des Entwurfsmodells -- Grund: nichtfunktionale Eigenschaften -- Zugriffspfade -- Klassen in Attribute umwandeln -- Verzögerung von Berechnungen -- Zwischenspeicherung aufwändiger Ergebnisse - -Codegenerierung aus StateCharts -- Einfachste Möglichkeit: Switch (Case) Statement -- Zustände werden durch Datenwerte repräsentiert - - Aktueller Zustand: einzelne skalare Variable -- Jedes Ereignis wird durch Methode implementiert -- Ausgehend von aktivem Zustand wird bei Eintreffen eines Ereignisses der entsprechende Programmcode ausgeführt -- Abhängig von Zustandsvariable wird Aktion ausgeführt und der Folgezustand eingestellt -- Wird in einer Klasse realisiert -- Sinnvoll für einfache, “flache” Modelle - - Sonst Logik für Hierarchie nötig - -Anpassung der Generierung -- Verschiedene Zielsprachen (Java, C++, ...) -- Model2Text-Transformationen - - Verschiedene Generatoren, z.B. Eclipse Modelling Project -- Generierung aus dem Modellierungswerkzeug - - Parametrisierung der Codegenerierung - - Generierungsvorlagen - -Weitere Werkzeuge -- Compiler-Compiler: Syntaxbeschreibung wird in lexikalische Analyse (tokenizer) und Syntaxanalyse-Programm transformiert (lex & yacc / flex & bison / antlr) -- Codegenerierung für grafische Benutzungsoberflächen aus grafischer Beschreibung: GUI toolkits -- XML-Parser - - XSLT, DOM, SAX, ... - -## Implementierung aktiver Objekte -Realisierung aktiver Entwurfsobjekte -- Reagieren nicht nur (Methodenaufruf), sondern implementieren eigenes Verhalten -- Aktive Klassen, z.B. Steuerobjekte - -Arten von Programmabarbeitung -- Sequentiell: es gibt immer genau einen nächsten Schritt, alle Schritte werden nacheinander ausgeführt -- Parallel: Spezielle Hardware bzw. Mehrkernprozessor, mehrere Befehlsfolgen werden echt parallel bearbeitet -- Quasi-parallel: Ein Prozessor arbeitet mehrere Befehlsfolgen in freier Einteilung ab -- Nebenläufig: Oberbegriff für Parallel und Quasi-parallel - - concurrent - -Vorteile -- Höhere Geschwindigkeit -- Kein aktives Warten auf Ereignisse -- Getrennte Implementierung unabhängiger Aspekte - -Ergebnisse eines Programms -- Ein Programm, dessen Ablauf eindeutig vorherbestimmt ist, nennt man deterministisch (deterministic) -- Ein Programm, das bei gleichen Eingaben gleiche Ausgaben produziert, heißt determiniert (determined) -- Programme in üblichen Programmiersprachen sind sequentiell, deterministisch und determiniert -- Grund: Herkömmliche Programmiersprachen sind durch das von-Neumann-Modell geprägt -- Determinismus nicht notwendig für Determiniertheit! - - Determiniertheit nebenläufiger Programme: Synchronisation - - Vermeidung von Schreib/Schreib und Schreib/Lese-Konflikten - -Java Threads -- Verwaltung durch die Java Virtuelle Maschine (JVM) -- Realisierung der Threads ist je nach Implementierung der JVM unterschiedlich - - Abbildung auf Betriebssystem-Threads (z.B. unter Windows weitverbreitet) - - Realisierung durch die JVM (z.B. unter Unix und in Java-fähigen Browsern) - - Nachteile: Keine Ausnutzung von Multiprozessorsystemen durch die VM; Zuteilungsstrategie für Threads ist in derzeitigen Implementierungen unterschiedlich -- Threads arbeiten immer im Adressraum der JVM (eigener Prozess) und sind außerhalb dieser nicht sichtbar - -Erzeugung eines Threads -- Unterklasse der Basisklasse „Thread“ bilden `class MyThread extends Thread` -- Problem: keine Mehrfachvererbung, daher Alternative nötig (Beispiel: Applet): - - Schnittstelle „Runnable“ implementieren - - `class MyThread implements Runnable` -- Die vordefinierte Schnittstelle Runnable ist definiert als - ```java - public interface Runnable - { public abstract void run(); } - ``` - -Starten eines Threads -- Eine Klasse, die Runnable implementiert, muss wie Unterklassen von Thread immer eine run()-Methode definieren -- Seiteneffekt der Runnable-Schnittstelle - - Instanzen der Klasse werden nebenläufig zu den anderen laufenden Threads ausgeführt - - Ausführung beginnt mit der Methode run () -- Ablauf - - Thread-Objekt erzeugen - - Thread starten mit t.start() - - start() ruft implizit run() auf - -Synchronisation von Threads -- Gezielte Einschränkung der Nebenläufigkeit -- Gründe - - Zugriffsbeschränkung, gegenseitiger Ausschluss - - Abhängigkeiten, einseitige Synchronisation -- Methoden: Semaphore, Monitore, Schlossvariablen, ... - -Java: Monitore -- Zugriffsoperationen werden in Klassen zusammengefasst -- Gegenseitiger Ausschluss: Spezifikation der betroffenen Zugriffsoperation als synchronized - -## Verifikation und Testen -Wie erreicht man qualitativ hochwertige Software? -- Wissen, Erfahrung und Methodenkompetenz der Programmierer -- Projektstruktur, klare Verantwortlichkeiten -- Kosten- und Zeitdruck? Änderungen? -- Programmier- und Testmethoden - - pair programming, code reading etc. - - Qualitätsverantwortlicher, automatisiertes Testen -- Technische Unterstützung - - Z.B. Versionierung, Dokumentation, Testen, Entwicklungsumgebung - -Begriffe -- Zuverlässigkeit: Maß für Übereinstimmung des Systemverhaltens mit Spezifikation -- Grund für Unzuverlässigkeit: - - Fehler (bug, fault): fehlerhafter Programmcode o.ä. - - Der Begriff „Bug“: - - Schon vor Computern als Begriff für Fehler benutzt - - Motte im Relais des Computers Mark II Aiken (1947) - - Fehlerhafter Zustand (error): Fehler hat zur Laufzeit zu einem internen fehlerhaften Zustand geführt, der möglicherweise zu einem Ausfall führt - - Störfall, Ausfall (failure): Abweichung vom spezifizierten Verhalten, meist mit negativen Folgen - -Vergleich System / Systemmodell -- Anspruch guter Software: System entspricht Systemmodell (Korrektheit) -- Problem: System nicht vollständig automatisch erzeugbar! -- Auswege - - Fehlervermeidung (Inspektion, pair programming, ...) - - Nachweis, dass System dem Modell entspricht - Verifikation - - Überprüfen, ob System dem Modell entspricht - Testen - - Fehlertoleranz (durch Redundanz) - -Verifikation -- Mathematisch formaler Beweis, dass ein Programm einer Spezifikation genügt -- Vorteil: wenn anwendbar, dann vollständiger Beweis -- Problem: für viele (realistisch große) Fälle nicht anwendbar - - Zu aufwändig - - Umgebung muss ebenfalls verifiziert werden - - Auch in der Theorie nicht immer entscheidbar: Halteproblem, Gödelscher Unvollständigkeitssatz -- Theoretische Informatik: Berechenbarkeitstheorie, formale Semantik; aktives Forschungsgebiet - - model checking - -Testen -- Systematischer Versuch, Defekte in der Software zu finden -- Ingenieurtechnik zur Erhöhung des Vertrauens in Softwaresysteme, aber: unvollständig! - - Kann nur die Anwesenheit von Fehlern nachweisen, aber nicht Korrektheit (Abwesenheit von Fehlern)! -- Aufgabe: Unterschiede zwischen Modell und System finden -- Destruktiv im Gegensatz zu sonstigen SWE-Aufgaben - - Daher sollten nicht (nur) Entwickler selbst testen - -Testplanung -- Testen ist aufwändig, deshalb ist gute Planung nötig! -- Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)! -- Typische Bestandteile einer Test-Spezifikation (Testdrehbuch) - - Phasenmodell des Testprozesses - - Zusammenhang zur Anforderungsspezifikation, z.B. dort festgelegte Qualitätsziele - - Zu testende Produkte - - Zeitplan für die Tests - - Abhängigkeiten der Testphasen - - Aufzeichnung der Testergebnisse - - Hardware- und Softwareanforderungen - -Arten von Tests -- Komponententest: Fehler in einzelnen Objekten oder Subsystemen, losgelöst vom umgebenden System - - Umgebung muss nachgebildet werden -- Integrationstest: Zusammenspiel von Komponenten - - Vollständiges System: Systemtest; Szenarios -- Strukturtest: innere Zustände, Interaktionen -- Funktionstest: Anforderungen aus Lastenheft -- Leistungstest: nichtfunktionale Anforderungen -- Benutzbarkeitstest: Fehler in der Benutzungsschnittstelle, Verständlichkeit, Akzeptanz bei Anwendern - - Prototypen -- Akzeptanztest, Installationstest: Kunde, Abnahme - -Komponententests -- Überprüft Verhalten einer Systemkomponenten im Vergleich zur Spezifikation -- Da Tests bereits frühzeitig stattfinden sollten, ist Umgebung meist nicht vollständig implementiert - - Teststumpf (stub, dummy) simuliert aufgerufene Komponenten - - Testtreiber simuliert aufrufende Komponenten -- Vorgehensweisen - - Bottom-up - - Top-down - - Sandwich - - Schichtenweises Testen - -Systematisches Testen -- Testfall - - Beschreibung, Name - - Zu testende Komponente, Testgegenstand (Pfad, Aufrufart) - - Eingabedaten (Testdaten) - - Erwartete Ergebnisse („Orakel“) - - Protokoll (erzeugte Ausgaben) - - Bewertung des Ergebnisses -- Weitere Begriffe - - Regressionstest: erneute Durchführung eines Tests anhand einer geänderten Version des Testgegenstands - - Alphatest: Test eines Prototypen durch Benutzer - - Betatest: Test der vollständigen Software durch Benutzer - -Funktionaler Test (black box test) -- Testfallauswahl beruht auf Spezifikation -- Ohne Wissen über inneren Aufbau -- E/A-Zusammenhang - -Äquivalenzklassen im funktionalen Test -- Problem: alle Kombinationsmöglichkeiten der Eingangsdaten sind zu umfangreich für vollständigen Test -- Mögliche Einschränkung: Bildung von Äquivalenzklassen der Eingangsdaten, für die ähnliches Verhalten erwartet wird -- Basierend auf Anwendungsdomäne -- Äquivalenzklasse = Teilmenge der möglichen Datenwerte der Eingabeparameter -- Test je eines Repräsentanten jeder Äquivalenzklasse -- Finden von Äquivalenzklassen - - Zulässige / unzulässige Teilbereiche der Datenwerte - - Unterteilung der Bereiche nach erwarteten Ausgabewerten - -Grenztests -- Ergänzung von Äquivalenztests: Spezialfälle -- Rand der Äquivalenzklasse -- Außerdem: Sonderfälle, erwartete Problemfälle (technisch) - -Strukturtest (white box test, glass box test) -- Testfallauswahl beruht auf Programmstruktur -- Wie erreicht man möglichst vollständige Abdeckung? -- Kontrollflussorientiert - - Anweisungsüberdeckung anhand Quellcode - - Zweigüberdeckung und - - Pfadüberdeckung anhand des Flussgraphen reduzierte Variante: bounded interior Pfadtest -- Datenflussorientiert - - defines / uses-Verfahren: Abarbeitungspfade von Definition zu jeder Verwendung von Variable oder Objekt durchlaufen -- Zustandsorientiert - -## Testaktivitäten und Werkzeuge -Wann wird getestet? -- Während der Implementierung! - - Auch wenn Schreiben von Tests scheinbar unproduktiv ist - - Tests sind unbeliebt, da Probleme aufgezeigt werden - - Aber: spätes Testen erhöht Aufwand! -- Inkrementell, d.h. für jede überschaubare Änderung -- Spezielle Vorgehensweise: test first-Ansatz - -Wie wird getestet? -- Geplant, systematisch, möglichst automatisiert, dokumentiert, wiederholbar - -Testplanung -- Iterative Erstellung eines Testplans / Testdrehbuchs -- Aktivitäten – Festlegen von - - Teststrategie (Testumfang, Testabdeckung, Risikoabschätzung) - - Testziele und Kriterien für Testbeginn, -ende und -abbruch - - Vorgehensweise (Testarten) - - Testumgebung (Beschreibung) - - Hilfsmittel und Werkzeuge zum Testen - - Testspezifikation - - Testorganisation (Termine, Rollen, Ressourcen) - - Fehlermanagement (Werkzeugunterstützung) -- Ergebnis: Inhalt des Testplans - -Testspezifikation -- Auswahl der zu testenden Testfälle -- Definition einzelner Testfälle - - Grundlage: Anwendungsfälle, Anforderungen, Fehlermeldungen (Zuordnung notwendig) -- Aktivitäten - - Testfallfindung und Testfalloptimierung - - Testfälle beschreiben (was genau ist zu testen) - - Randbedingungen finden (Abhängigkeiten zu anderen Testfällen) - - Festlegen und Erstellen der Eingabedaten - - Festlegungen zum Testablauf und zur Testreihenfolge - - Festlegen Soll-Ergebnis - - Festlegung der Bedingung(en) für 'Test erfüllt'; ... - -Testvorbereitung -- Tätigkeiten im Vorfeld des Tests -- Aktivitäten - - Vorbereitung der Tests entsprechend Testplan - - Bereitstellen der Dokumente (Testspezifikation) - - Verfügbar machen von Werkzeugen (Fehlermanagement) - - Aufbauen der Testumgebung(en) - - Integration der Entwicklungsergebnisse in die Testumgebung (Software installieren, konfigurieren, ...) - - Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung - - Benutzer und Benutzerrechte anlegen - -Testdurchführung -- Durchführung der spezifizierten Tests - - Manuell - - Automatisiert -- Aktivitäten - - Auswählen der zu testenden Testfälle - - Bereitstellen der Testdaten - - Starten, Überwachen, Abbrechen, Beenden - - Erfassung des Ist-Ergebnisses zur Auswertung - - Besondere Vorkommnisse dokumentieren - - Umgebungsinformationen für den Testlauf archivieren, ... - -Testauswertung -- Überprüfung der Ergebnisse -- Vergleich Ist-Ergebnis mit Soll-Ergebnis -- Entscheidung Testergebnis (ok / Fehler) -- Bei Fehler: - - Klassifizierung (z. B.: Fehlerursache, Fehlerschwere etc.) - - Fehler reproduzieren! - - Angemessene Fehlerbeschreibung und –erläuterung: Nur ausreichend dokumentierte Fehler sind gültig und können bearbeitet werden! - - Fehler im Fehlermanagement eintragen (Bug report) - - Testfall bleibt offen - -Bugbeschreibung -- Möglichst genaue Beschreibung des Fehlers -- Ziel ist die Reproduzierbarkeit des Fehlers -- Zuordnung zu Projektplan: Meilenstein, Version -- Fehlerklassifikation - - defect: Fehler in einer bestehenden Funktionalität - - enhancement / feature: Funktionale Anforderung oder Erweiterung der bestehenden Funktionalität - - task: Allgemeine Aufgabe -- Priorität festlegen - - Unterschiedliche Stufen - - Festlegung innerhalb eines Unternehmens / Projektes -- Prioritäten von Fehlern (bugs) - -| Stufe | Bedeutung | Verhalten | -| -- | -- | -- | -| blocker | Schwerwiegender Fehler. Führt zur Arbeitsunfähigkeit anderer (Entwicklung, QA, Produktion,...). | Verdrängt alle anderen Aufgaben! Muss sofort gelöst werden, um Arbeitsfähigkeit wieder herzustellen. | -| critical | Schwerer Fehler. Eine grundlegende Funktionalität des Systems ist nicht gegeben. Fehler muss bis zur nächsten Version behoben werden. System kann nicht verwendet werden. | Alle anderen Fehler (außer blocker) werden später gelöst. Bis zum nächsten Release muss dieser Bug gelöst sein. | -| major | „normaler“ Fehler. Es tritt ein Fehler innerhalb einer Funktion des Systems auf. Das System kann jedoch weiterhin verwendet werden. | Fehler wird normal eingeplant. | -| minor | Kleiner Fehler. Fehler behindert nicht weiter die Funktionsfähigkeit des Systems. Einfacher Work-Around vorhanden? | Je nach Aufwand und Zeitplanung erledigen. | -| trivial | Schönheitsfehler. Fehler stört während des Betrieb des Systems nicht. | Je nach Aufwand „zwischendrin“ erledigen. Alle anderen Bugs bevorzugt lösen. | - -Testabschluss -- Zusammenfassen der Tests -- Gesamtstatus dokumentieren und kommunizieren -- Entscheidungen herbeiführen  z.B.: Auslieferung? - - Ziele erreicht - nächste Schritte (Auslieferung) - - Tests vorzeitig beenden oder unterbrechen - - Gründe dokumentieren - - Vollständiger Nachtest oder Teiltest möglich? -- Unterlagen archivieren - -Testautomatisierung -- Automatische Code-Validierung - - Statisch: lint (C), Compiler - - Dynamisch: run-time checking, memory leaks etc. -- Beispiel: Test-Framework JUnit - -Behebung funktionaler Fehler -- Log-Ausschriften bzw. Signale -- Debugger: Vorwärts / Rückwärts -- Haltepunkte setzen: Bedingte Haltepunkte für Schleifen -- Darstellung der Variablenbelegung, Werte setzen -- Analyse des Aufruf-Stacks - -Behebung nichtfunktionaler Fehler -- Geschwindigkeit: profiling z.B. mit Eclipse TPTP -- Aufrufe, Zeitverbrauch in Methoden usw. - -Memory Leaks, JProbe -- Runtime heap summary: Welche Objekte verbrauchen Speicher? -- Reference graph: Wer referenziert diese Objekte, so dass sie nicht per garbage collection gelöscht werden? - -## Softwareverteilung -Softwareverteilung (deployment) -- Prozess zur Installation von Software auf - - Anwender-PC‘s, Servern, Maschinen in Produktion ... -- Steuerung der Installation der Software -- Voraussetzungen für die Software schaffen - - Schulungen planen und durchführen -- Softwareverteilung ist ein kritischer Prozess! - - Fehler können zu vielen Störungen und Ausfällen führen -- Ziele - - Automatische Installation, Konfiguration und Wartung einer großen Anzahl von Systemen mit geringem Aufwand - - Erreichen eines störungsarmen und sicheren Betriebs - - Möglichst einheitliche Softwareversionen auf allen Systemen - -Installationsarten -- Erstinstallation -- Software-Update (Software-Aktualisierung) - - Aktualisierung der Software, Daten oder Konfiguration -- Hotfixes und Service Packs - - Nur bestimmte Teile der Software werden aktualisiert - - Meist nur Fehlerbehebung, keine neuen Features -- Upgrade - - Erweitert eine Software deutlich um neue Funktionen -- Unbeaufsichtigte (automatische) Installation - - Installation erfolgt ohne Benutzereingriff - - Periodisch, durch Aufruf des Anwenders, beim Programmstart - - Einstellungen in einem Skript festgelegt oder werden als Parameter übergeben - -Installationshilfsmittel -- Installationsprogramm (Installer) - - Windows: Windows Installer, InstallShield - - Linux: RPM, Port, APT - - MAC-OS: Installer, WarpIn -- Installations-Script -- Installationsanweisung - -Software-Rollout -- Vorgang des Veröffentlichens und Verteilens von Softwareprodukten auf entsprechende Clients -- Anzahl der Clients kann weit über 10.000 liegen! -- Rollout abhängig von verschiedenen Kriterien (Vorherige Installation, Hardwarekonfiguration, Zeit, Kunde) -- Rollout-Varianten - - Zentral / Dezentral - - Manuell (Benutzer löst Installation aus) - - Automatisiert (ohne Benutzerinteraktion) - -Vollständige Verteilung (big bang) -- Alle Installationen werden mit einem Mal installiert -- Sehr hohes Risiko -- Eventuelle Fehler führen zu vielen fehlerhaften Zuständen oder Störfällen - führt zu hohem Druck -- Eventuelle Fehler müssen schnell gelöst werden (Provisorium) -- Sehr kurze Einführungsphase -- Rollback-Mechanismus sehr empfohlen - -Rollback -- Wiederherstellung des Ursprungszustands -- Technische Realisierung muss ermöglicht werden - -Pilotierte Einführung -- Einführung für wenige ausgewählte Installationen -- Sehr hohe Sicherheit -- Festlegung der späteren Rollout-Schritte -- Benötigt zusätzliche Zeit -- Geringere Auftrittswahrscheinlichkeit von Fehlern - -Schrittweise (iterative) Einführung -- Einführung erfolgt schrittweise mit einer definierten Anzahl -- von Installationen (Rampe – ramp-up) -- Höhere Fehlerwahrscheinlichkeit -> Bessere Reproduzierbarkeit -> schnelleres Finden von Fehlern -> Erfahrungsgewinn -- Begrenztes Risiko, mittlerer Zeitaufwand - -# Vorgehensmodelle -## Einführung -Wie läuft Softwareerstellung ab? -- (oder besser, wie sollte sie ablaufen?) -- Aufgaben und Phasen siehe vorangegangene Kapitel -- Wann wird was getan? Abhängigkeiten? - - Sequentiell / nebenläufig, -- Prozessmodelle der Softwareentwicklung - - Regelwerke, Erfahrungen, best practices für große Projekte - - Aktives Entwicklungsgebiet -- Erweiterbar zum Software-Lebenszyklus mit Inbetriebnahme, Wartung, Außerdienststellung usw. - -Softwareentwicklungsprozess/Vorgehensmodell -- Methode zur Erstellung von Softwaresystemen -- Systematisch, rational und schrittweise erfolgender Weg vom Problem zur Lösung -- Ziel: Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar -- Zerlegung des Softwareentwicklungsprozesses in überschaubare Einheiten -- Unternehmensspezifisch, anpassbar, erweiterbar - - Eigene Varianten, evtl. projektabhängig - - An spezielle Bedürfnisse des Informationsbereichs angepasst - - Kein allgemeingültiges Vorgehen - - Einsetzbar in verschiedenartigen Projekten - -Phasen -- Überwiegend zeitliche Zerlegung -- Zeitlich begrenzte Phasen -- Auch inhaltlich und organisatorisch begrenzte Phasen möglich -- Teilprozesse / Aktivitäten - - Inhaltliche Zerlegung - - Satz von Aufgaben - - Verteilung der Teilprozesse / Aktivitäten auf verschiedene Phasen - - Begleitet von unterstützenden, übergreifenden Aktivitäten - -Aufgabe -- Erzeugt Arbeitsergebnis (Artefakt) -- Verbraucht Ressourcen (z.B. Arbeitskraft, Zeit, Ausrüstung) - -Arbeitsergebnis (oder Artefakt) -- Dokument, Modell, System, Programmcode Lastenheft, Spezifikation, Glossar, Handbuch usw. -- Intern zu lieferndes Ergebnis - -Teilnehmer und Rollen -- Verantwortungsbereich eines Teilnehmers (z.B. Kunde, Projektmanager, Entwickler, Architekt) -- Rolle bearbeitet / enthält Satz von Aufgaben - -Unterstützungsprozesse / -Aktivitäten -- Projektmanagement - - Projektplanung, -verfolgung und -steuerung - - Risikomanagement -- Anforderungsmanagement - - Im Gegensatz zur Anforderungsaufnahme und -analyse -- Qualitätsmanagement - - Problem Management - - Softwaremetriken (Messung von Softwareeigenschaften) - - Statische + dynamische Analyse (Bestimmung von Schwachstellen) -- Konfigurationsmanagement - - Versionsverwaltung, Änderungsmanagement -- Dokumentation - -## Sequenzielle Modelle -- Wasserfallmodell - - Abhängigkeiten zwischen Teilergebnissen - - Ursprung in System- Hardwareentwicklung - - Wurde für die SW-Entwicklung übernommen - - Auch heute verbreitetes Vorgehen bei HW-Entwicklung - - Sequenzielles Phasenmodell (Abschluss der Phasen) - - Stark Dokumentengetrieben (Ergebnisse der Phasen) - - Unterteilung in abgeschlossene Phasen: - - Analyse - - Design/Entwurf - - Implementierung - - Test & Integration - - Einführung, Betrieb & Wartung - - Alternativ: - - Planung - - Definition - - Entwurf - - Implementierung - - Test & Integration - - Einsatz und Wartung - - Vorteile - - Einfach und verständlich, bekannt und verbreitet - - Erleichterte Planung und Steuerung - - Nachteile - - Idealisierte Annahme rein sequentiellen Ablaufs - - Starke Abhängigkeiten zwischen Teilergebnissen - - Ungeeignet, falls Anforderungen zu Beginn unklar - - Unflexibel gegenüber Änderungen - - Erst sehr spät greifbare Ergebnisse -- Erweitertes Wasserfallmodell - - Verbesserung für Änderungen und Fehler – Rückschritte -- Alternative Arten von Phasenmodellen - - Sequenziell - - Phasen strikt nacheinander, Dokumenten-orientiert - - Keine Änderungen abgeschlossener Artefakte - - Nebenläufig - - Phasen laufen teilweise parallel für bessere Zeitnutzung - - Weiterhin keine Änderungen fertiger Dokumente - - Inkrementell - - Unterteilung des Produkts in Teile - - Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen - - Alternative: Evolutionär - - Anforderungen entwickeln sich im Projekt - - Ausgelieferte Versionen ergeben neue Anforderungen -- V-Modell [Boehm] - - Explizite Adressierung der Qualitätssicherung - - ![VModell](Assets/Softwaretechnik1_VModell.png) - - Entwicklung des V-Modells in Deutschland - - Leitfaden, in Bundesbehörden ab 1990er verbindlich - - Version V-Modell 97 erweitert um Werkzeuganforderungen, Rollen und Submodelle der Beteiligten - - Kritik: schlecht skalier- und anpassbar, zu unflexibel, - - bürokratisch, nicht an moderner OO-SWEntw. orientiert - - V-Modell XT (extreme tailoring) - - Aktuelle Version ab 2004/05 - - Einfache projektspezifische Anpassbarkeit - - Assistent www.v-modell-xt.de (kleines Projekt ~40 Dok.!) - - Überprüfbarer Projektfortschritt - - AG/AN-Sichten und Schnittstellen, Ausschreibungen - - Gesamter SW-Lebenszyklus - - -## Iterative Modelle -Iterativer Entwicklungsprozess -- Spezifikation, Entwurf und Implementierung müssen immer wieder verändert und angepasst werden -- Häufiges Integrieren, Validieren und Testen -- "You should use iterative development only on projects that you want to succeed." [Fowler] - -Inkrementelle Entwicklung -- Wenn möglich, sollte es immer einen lauffähigen (unvollständigen) Prototypen geben -- Neue Funktionen sofort integrieren -- Neue Versionen gegenüber Anforderungen Validieren - -![Spiralmodell](Assets/Softwaretechnik1_Spiralmodell.png) -Spiralmodell -- Risikogetrieben: Größte Projektrisiken identifizieren und als erstes bearbeiten (Prototyp?) -- Spirale = iterativer Zyklus durch dieselben Schritte -- Ziele jedes Durchlaufs aus alten Ergebnissen ableiten -- Kosten/Nutzen abwägen -- Regelmäßige Überprüfung des Prozessmodells -- Anpassbar -- Hoher Management-Overhead, große Projekte - -Unified Process -- Vorgehensmodelle zur objektorientierten Softwareentwicklung - - Ivar Jacobson, Grady Booch and James Rumbaugh: The Unified Software Development Process, (Rational/IBM), 1999 -- Phasen der Entwicklung - - Anfang, Ausarbeitung, Erstellung, Überleitung - - Unterteilung in Iterationen - - Definition von Meilensteinen -- Definition von Kernprozessen, die in den Phasen ablaufen - - Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse & Design, Implementierung, Test, Auslieferung - - In unterschiedlichen Anteilen parallel ablaufend! - -Prinzipieller Ablauf des Unified Process -![Unified Process](Assets/Softwaretechnik1_UnifiedProcess.png) -- Haupteigenschaften des UP - - Inkrementell, iterativ, evolutionär - - Anwendungsgetrieben - - Architekturzentriert - - Risikoorientiert - - Ereignisorientiert - - Nutzt die UML als Notationssprache - - Erweiterbar / Anpassbar -- Verbreitete Vertreter - - Rational Unified Process – RUP (Rational / IBM) - - Open Unified Process – OpenUP (Eclipse Foundation) - - Object Engineering Process – OEP (oose GmbH) -- Vorteile - - Vorteile der Eigenschaften (iterativ, inkrementell, anpassbar, ...) - - Berücksichtigung des Risikos - - Passend für objektorientiertes Paradigmas und UML - - Tool-Unterstützung - - Reaktion auf Änderungen möglich - - Industriestandard -- Nachteile - - Hoher Bürokratischer Aufwand -> Tailoring notwendig! - - Relativ hohe „Lernkurve“ aller Beteiligten - - Keine schnelle Reaktion auf Änderungen - - Keine integrierte Qualitätssicherung - -## Agile Methoden -- Ausgangspunkt - - Ziv's Unsicherheitsprinzip des Software Engineering: "Unsicherheit ist im Software-Entwicklungsprozess und den Produkten inhärent und unvermeidlich." (Ziv, 1996) - - Humphrey's Prinzip der Anforderungsunsicherheit: "In einem neuen Software System werden die Anforderungen solange nicht komplett bekannt sein, bis die Anwender damit arbeiten." (Humphrey, 1995) - - Wegner's Lemma: "Es ist unmöglich, ein interaktives System komplett zu spezifizieren." (Wegner, 1995) -- Ziele - - geringer bürokratischer Aufwand - - Hauptziel ist die Softwareentwicklung - - nur wenige Regeln bzw. Verhalten definiert - - sehr flexibel gehaltenes Vorgehen - - stark Anwendungs- und Ereignisorientiert - - iterativ / inkrementell / evolutionär - - sehr schnelle Entwicklungsiterationen - - meist Architekturzentriert - - auch testgetriebenes Vorgehen möglich - - Berücksichtigung sozialer Aspekte - - Softwareentwicklung: Kreative Arbeit von Kreativen - -Das Agile Manifest (2001) -- Individuen und Interaktionen bedeutender als Prozesse und Tools -- Funktionierende Software bedeutender als übermäßige Dokumentation -- Stetige Zusammenarbeit mit dem Kunden bedeutender als Vertragsverhandlung -- Mut und Offenheit für Änderungen bedeutender als Befolgen eines Plans - -Eigenschaften agiler Vorgehensmodelle -- Team ist für Ergebnis verantwortlich und organisiert sich selbst -- Kleine Teams 5-8 Personen -- Definition von Richtlinien, Werten und Prinzipien -- Beispiele für Werte - - Kommunikation (Kommunikation statt Dokumentation) - - Einfachheit (KISS „Keep it small and simple“) - - Feedback - - Mut - - Respekt -- Beispiele für Prinzipien - - Beidseitiger Vorteil - - Fehlschläge hinnehmen - - Ständige Verbesserungen - - Ständige Lauffähigkeit des Codes - - Kleine Schritte - - Wiederverwendung bestehender / bewährter Lösungen -- Beispiele für Praktiken - - Pair-Programing, Coding Rules - - Kollektives Eigentum / Gemeinsamer Codebesitz - - Testgetriebene Entwicklung - - Ständiges Refactoring - - Keine Überstunden -- Vorteile agiler Methoden - - Geringer bürokratischer Aufwand - - Besseres Arbeitsklima (Berücksichtigung Sozialer Aspekte) - - Ständige Verfügbarkeit einer lauffähigen Version - - Mögliche / nötige Einflussnahme des Kunden - - „Freie“ Wahl der Prinzipien/Regeln - - Vermeidung von Spezialistentum und individuellem Besitz -- Nachteile - - Schwierigeres Projektmanagement - - Chaotische Vorgehen - - Schwere Planbarkeit des Ergebnisses - - Notwendige Beteiligung des Kunden - - Ergebnis ist schwer vorherzusagen - -### eXtreme Programming (XP) -- Beck 1999, aus Kritik an „monumentalen Modellen“ -- Evolutionäre Entwicklung in kleinen Schritten - - Möglichst einfaches Design -- Konzentration auf Programmcode als Analyseergebnis, Entwurfsdokument und Dokumentation -- Weglassen von explizitem Design, ausführlicher Dokumentation und Reviews -- Code wird permanent lauffähig gehalten (täglich) -- Schnell und flexibel -- Erfordert Disziplin der Teilnehmer -- Rollen: Projektleiter, Kunde (verfügbar), Entwickler - - Max. 5-10 Entwickler -- Kunde bestimmt Anforderung und Prioritäten - - planning game; story cards (use cases) -- Implementierung in kleinen Schritten - - pair programming, collective code ownership - - Häufige Releases inkl. Integration - - Refactoring bei Designänderungen - - Programmier-Konventionen -- Regelmäßiges automatisiertes Testen - - test-first Ansatz -- Morgendliches Meeting im Stehen ohne Diskussionen -- 40h-Woche -- XP - - Sammlung von 12 "best practices" - - Test-getrieben - - Flexibel, effizient - - Kleine Teams - - Erfordert Disziplin der Teilnehmer - - ![XP](Assets/Softwaretechnik1_XP.png) - -### Scrum -- [Ken Schwaber, Jeff Sutherland und Mike Beedle] -- Haupteigenschaften - - Iterativ / Inkrementell, Evolutionär - - stark Anwendungs- und Ereignisorientiert - - schnelle Entwicklungsiterationen -- Sprint - - eine schnelle Iteration: Dauer ca. 30 Tage - - Festlegung welche Features umgesetzt werden -- Product Backlog - - Liste der gewünschten Features des Produkts - - Vom Produkt-Owner priorisiert / Aufwand vom Team geschätzt - - Jeder kann Einträge beisteuern -- Rollen - - Product Owner - - Erfasst Bedürfnisse der Kunden und Stakeholder - - Pflegt Backlog, definiert, priorisiert Features pro Sprint - - Scrum Master - - Berät das Team, Überprüft Einhaltung von Werten und Techniken, moderiert die Meetings - - Schützt das Team vor äußeren Störungen - - Repräsentiert Team gegenüber Management - - Scrum Team (ca. 5-9 Personen) - - Team organisiert sich und die Aufgaben selbst - - Team bedeutet: Zielgerichtet und funktionsübergreifend arbeiten, gemeinsames Ziel verfolgen, selbstloses Handeln, Teamentscheidungen vertreten - -Sprint Backlog -- Für die aktuelle Iteration ausgewählte Aufgaben - - Aufgabe nicht länger als 2 Tage Aufwand -- Team-Mitglieder wählen Tasks aus – keine Zuweisung -- Restaufwand wird täglich aktualisiert – Burndown Chart -- Team-Mitglied kann Tasks hinzufügen, löschen, ändern -- Darstellung an prominenter Stelle - -Daily Meeting -- ca. 15 Minuten -- Kurze Statusmeldung, Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt? -- Weiterführende Diskussionen erst im Anschluss - -![Scrum Vorgehen](Assets/Softwaretechnik1_ScrumVorgehen.png) - -Sprint Review-Meeting -- Präsentation des Erreichten (Feature Demo) -- Product Owner, Kunde usw. geben Feedback - - Neue Anforderungen hinzufügen / Neu priorisieren - - Qualitätsansprüche ändern - -Sprint-Retrospektive -- Rückkopplungsschleife - - Was war gut und was hat nicht funktioniert? - - Was kann verbessert werden? -- Nach jedem Sprint -- Diskussion der identifizierten Probleme -- Identifikation von wenigen „Action Items“ - -Burndown Chart -- Darstellung der offenen und erledigten Aufwände / Tasks -- ![Burndown Chart](Assets/Softwaretechnik1_Burndownchart.png) - -## Zusammenfassung -- Software-Entwicklungsmethode - - Elemente - - Darstellung – Notation und Semantik für Modelle, Diagrammtypen, Dokumentvorlagen (Artefakte) - - Vorgehensmodell – Phasen, Arbeitsschritte - - Verfahren – Regeln, Anweisungen, Aktivitäten (+Rollen) - - Werkzeuge - - Industriestandards: RUP + UML - - Öffentliche Auftraggeber: V-Modell - - Firmenintern: eigene Varianten, evtl. projektabhängig - - Weitere Themen - - Reifegradbeurteilung CMMI, SPICE, ISO 9000 -- Charakterisierung von Vorgehensmodellen - - Sequenziell - - Teilprozesse strikt nacheinander - - Keine Änderungen abgeschlossener Artefakte - - Nebenläufig - - Teilprozesse laufen teilweise parallel für bessere Zeitnutzung - - Dokumentgetrieben - - Erstellung von Dokumenten (Artefakte) im Vordergrund - - Festlegung der Dokumente pro Phase -- Charakterisierung von Vorgehensmodellen - - Iterativ - - Definition einer sich wiederholenden Abfolge von Teil-Prozessen bzw. Aktivitäten - - Schnelles Wiederholen dieser Abfolgen - - Inkrementell - - Definition und Kontrolle des Fortschritts pro Iteration - - Kleine Erweiterungen - - Evolutionäres Vorgehen - - Schnelle Prototypen - - Lauffähiger Prototyp jederzeit vorhanden - - Toolunterstützung (Versionierung) -- Charakterisierung von Vorgehensmodellen - - Ereignisorientiert - - Schnelle Reaktion auf Anforderungsänderungen - - Keine starre Abfolge von Tätigkeiten / Prozessen - - Voraussetzung: Prozesse laufen parallel ab - - Architekturzentriert - - Starke Gewichtung der Architektur - - Verwendung von Modellen, Mustern und vorhandenem Wissen - - Anwendungsgetrieben - - Orientierung an den Anwendungsfällen - - Umsetzen, was einem Anwendungsfall zugeordnet werden kann - - Anwender steht im Mittelpunkt (User Stories) - - Risikoorientiert - - Risiko der Entwicklung wird in Planung berücksichtigt - - Risiko- / Nutzen-Analyse - - Test- / Qualitätsgetrieben - - Qualität steht im Vordergrund - - Test wird während oder sogar vor der Implementierungs-phase erstellt - - Erweiterbar / Anpassbar (tailoring) - - Nur Rahmen des Vorgehens festgelegt - - Konkretes Vorgehen wird an die Bedürfnisse angepasst - - Grundlegende Eigenschaft von Vorgehensmodellen -- Softwareprojekt im Sommersemester - - Auswahl aus 3 Vorgehensmodellen - - Klassisches Vorgehen - - Unified Process - - Agiles Vorgehen - -# Projektmanagement - -Was ist ein Projekt? -- Merkmale von Projekten - - Zielgerichtetes Vorhaben - - Einmaligkeit - - Zeitliche, finanzielle und personelle Rahmenbedingungen - - Abgrenzung zu anderen Vorhaben - - Projektspezifische Organisation - - Komplexität (Unterteilung in abhängige Teilaufgaben nötig) -- Unsicherheit vor allem in den Frühphasen -- Risiko durch unbekannte Aufgabe - -Was ist Projektmanagement? -- Überbegriff für planende und durchsetzende Aktivitäten zur Vorbereitung und Durchführung eines Projekts -- Management des Problemlösungsprozesses - - Nicht die Lösung selbst, eigene Disziplin -- Aufgaben - - Problemabgrenzung - - Zielfestlegung, Ablaufplanung - - Planung und Bereitstellung personeller, finanzieller und sachlicher Ressourcen - - Führen der Projektgruppe und Koordination der Aktivitäten - - Steuerung und Überwachung des Projektablaufes - - Zum großen Teil Planungs- und Kommunikationsleistung! - -## Projektplanung -Planung des Projektablaufs -- Zunächst wieder: Teile und Herrsche! -- Projektstruktur - - Teilung der Projektaufgabe in Arbeitspakete (work packages) und darin enthaltenen Aktivitäten (activities) - - Einteilung möglich anhand Produktstruktur, fachlicher Struktur oder Phasenmodell des Entwicklungsprozesses -- Überblick weiterer Planungsaufgaben - - Bestimmen der Abhängigkeiten - - Ermitteln der nötigen Ressourcen - - Schätzen der Aufwände - - Zeitplan aufstellen - - Meilensteine definieren -![Projektstruktur](Assets/Softwaretechnik1_Projektstruktur.png) - -Ablaufplanung -- Abhängigkeiten (Anordnungsbeziehungen) zwischen Vorgängen A und B: 4 Möglichkeiten - - Ende-Anfang (Normalfolge) - - B kann begonnen werden, sobald A beendet worden ist - - Anfang-Anfang (Anfangsfolge) - - B kann begonnen werden, sobald A begonnen worden ist - - Anfang-Ende (Sprungfolge) - - B kann beendet werden, sobald A begonnen worden ist - - Ende-Ende (Endfolge) - - B kann beendet werden, sobald A beendet worden ist -- Netzplantechnik - - Planungsarten - - Vorwärtsplanung (ab Startzeitpunkt) - - Rückwärtsplanung (ab gewünschtem Projektende) - - Berechnete Daten für Vorgänge - - Frühester und spätester Anfangszeitpunkt (FAZ / SAZ) - - Frühester und spätester Endzeitpunkt (FEZ / SEZ) - - Pufferzeiten, z.B. freier Puffer (Verzögerung ohne Verschiebung des Nachfolgers), Gesamtpuffer (Verzögerung ohne Gefährdung des Projektendes) - - Notation unterschiedlich - - Allgemein - - Kritischer Pfad (Verzögerung vergrößert Projektdauer) - - Kritische Vorgänge: Teil des kritischen Pfades - -Beispiel: -- Arbeitspakete laut Pflichtenheft (z.B.: Use Case) -- Aufgaben festlegen -- Abhängigkeiten festlegen -- Vorwärtsrechnung durchführen -- Rückwärtsrechnung durchführen -- Kritischer Pfad und Puffer finden -- ![Projektplanung](Assets/Softwaretechnik1_ProjektplanungBeispiel.png) - -Aufwandsschätzung -- Aus Erfahrungswerten systematisiert -- Versuch, wichtige Einflussfaktoren zu erfassen - - Metriken für Spezifikationen - - Komplexität von Teilfunktionen - - Menge der Funktionen - - Anpassung durch individuelle Faktoren, z.B. abhängig von Erfahrung in der Projektorganisation -- Methoden - - Function Point Analyse - - CoCoMo - -### Function Point Analyse -- Ursprung IBM Ende 1970er Jahre -- Funktionsumfang und Schwierigkeitsgrad von Software -- Verschiedene Verfahren - - für Echtzeit- (Full Function Point Method) und „normale“ Software (Int. Function Point User Group, ISO14143) -- ![FPA](Assets/Softwaretechnik1_FPA1.png) -- Jeweils Anzahl x Gewicht -- Summe aller Werte = Unadjusted Function Points (UFP) -- Function Points = UFP x EG -- Einflussgrad EG = 1 + 0.01 x SummeEinflussfaktoren -- Einflussfaktoren: Einfluss auf Anwendungsentwicklung -- ![FPA2](Assets/Softwaretechnik1_FPA2.png) -- Berechnung der Personen-Monate aus Erfahrungen vorangegangener Projekte - - Aufwand, der von einer Person in einem Monat unter Idealbedingungen erledigt werden kann -- Umrechnung mit Tabelle (nichtlinearer Verlauf) -- ![FPA3](Assets/Softwaretechnik1_FPA3.png) - -### CoCoMo II -- Constructive Cost Model [Boehm2000] -- Ausgangspunkt: geschätzte Anzahl Zeilen Quellcode - - SLOC, source lines of code (zB. aus UFP schätzen) -- Aufwand Personen-Monate (PM) $PM = A * Size^E \prod_{i=1}^n EM$ mit $E=B+0,01*\sum_{j=1}^5 SF_j$ -- Faktoren $A=2.94$ und $B=0.91$ (anpassbare Koeffizienten) -- Effort multiplier $EM: n=6..16$, Tabelle nach Boehm - - Beispiele: Komplexität, Wiederverwendbarkeit, ... - - Werte $0,7 .. 3,0$ -- Scale factor SF: Fünf Einflüsse auf Rentabilität der Softwareentwicklung -- Notwendige Entwicklungszeit (time to develop) $TDEV = C * PM^F$ mit $F = D + 0,2 * ( E - B )$ -- Faktoren $C=3,67$ und $D=0,28$, anpassbar -- Ressourcenplanung ![Ressourcenplanung](Assets/Softwaretechnik1_Ressourcenplanung.png) -- Zeitplanung - - Zeitplan aus Abhängigkeiten, Aufwänden und Ressourcen sowie festen Terminen - - Darstellung als Gantt-Chart / Balkendiagramm - -## Projektdurchführung -Projektorganisation -- Teilnehmer: Personen, Rollen, Verantwortung, Teams -- Linienorganisation: - - hierarchisch ![hierarchisch](Assets/Softwaretechnik1_Organisation_hierarchisch.png) - - Matrixorganisation ![matrix](Assets/Softwaretechnik1_Organisation_matrix.png) - - Reine Projektorganisation: Mitarbeiter werden aus Organisation herausgelöst und Projektleiter unterstellt - -Projektmanager - Rolle und Aufgaben -- Planung, Start, Kontrolle und Beenden des Projekts -- Schnittstelle zur Umgebung des Projekts - - Kunden, Unterauftragnehmer, interne Kontakte, Verträge -- Team zusammenstellen und steuern - - 5-7 Mitglieder gemischter Qualifikation - - Team von äußeren Aufgaben abschirmen - - Teilaufgaben definieren, vergeben und koordinieren - - Fortschritt kontrollieren und Probleme beseitigen -- Weitere Ressourcen bereitstellen -- Notwendige Planänderungen erkennen und reagieren -- Wichtiger Dienstleister für den Projekterfolg - -Projektstart -- Nach Abschluss der Planungsphase -- Festlegung von ... - - Arbeitsstil und interne Organisation - - Aufgabenverteilung und Themen-Verantwortung - - Erste Aufgaben, Verantwortliche und Termine - - Einigung über Meilensteine und Termine - - Art und Termine der Projekttreffen - - Informationen und Kommunikationswege - - Technische Infrastruktur (Versionskontrollsystem, Entwicklungsumgebung, Dokumentverwaltung, Rechnerzugang, verwendete PM-Software usw.) -- Starttreffen des Projekts (kick-off meeting) - -Meetings / Projekttreffen -- Regelmäßige Abstimmung der Projektteilnehmer - - Außerdem zu wichtigen Meilensteinen -- Inhalt und Ablauf: geplant (Tagesordnung), Moderator - - Protokoll des letzten Treffens korrekt? - - Aktueller Stand - - Bericht über individuelle Aufgaben - - Planung des nächsten Termins -- Protokoll - - Datum, Zeit, Ort, Teilnehmer, Moderator - - Bezeichnung - - Tagesordnung mit einzelnen Punkten - - Kurz und knapp, neutral bei Diskussionen! - -Fortschrittskontrolle -- Meilensteine - - Klar definiertes Zwischenresultat zur Beurteilung des Projektfortschritts - - Beispiele: Feinentwurfsdokument fertiggestellt und an Auftraggeber übergeben oder Paket XYZ implementiert und fertig getestet -- Besprechung in Projekttreffen - - Besprechung des Status jedes Meilensteins / jeder Aufgabe - - Welche Aufgaben sind bereits erledigt? - - Welche Probleme sind aufgetreten / gelöst? - - Verbleibender Aufwand – Terminverschiebung nötig? - - Planung der nächsten Schritte (Aufgabe, Verantwortlicher, Termin) - -Meilenstein-Trendanalyse -- Technik zur Fortschrittskontrolle -- Überwachung des Projektfortschritts zur Erkennung von Terminverzögerungen -- Bei Verzögerungen: - - Ressourcen erhöhen - - Termine verschieben - - Funktionen reduzieren - -Wie viel Planung? -- Planung ist wichtig, aber nicht übertreiben! -- Aufwand und Detaillierungsgrad der Planung an Projektgröße und „echten“ Aufwand anpassen -- Pläne müssen sich ändern können! - - Projekte sind einmalig und daher unvorhersehbar -- Adaptiv planen: nächste Aufgaben genau, spätere grob -- Einsatz von Projektmanagement-Software -- Projektende - - Abschlusstreffen - - Bewertung von Ergebnis und Organisation - was kann in Zukunft besser gemacht werden? \ No newline at end of file