2009

OOAA Object Oriented Analysis Advanced Arie Bubberman 12/10/2009

Contents 1 Analyse ............................................................................................................................................3 Kiezen van een ontwikkelproces .....................................................................................................3 Agile –Methoden ............................................................................................................................3 Deelprocessen in het OO-ontwikkelproces .................................Fout! Bladwijzer niet gedefinieerd. De plaats van analyse in het ontwikkelproces..................................................................................5 Agile methods .................................................................................................................................7 2 Statisch modelleren .........................................................................................................................8 Bepalen van Analysis Classes...........................................................................................................8 Opstellen van een initieel Domeinmodel .........................................................................................9 Uml – diagrammen .........................................................................................................................9 3 Statisch Modelleren – Detailleringen.............................................................................................. 11 Associaties en Attributes ............................................................................................................... 11 Toepassen van Inheritance............................................................................................................ 11 Uitbreiding Use Case Notatie ........................................................................................................ 11 4 Dynamisch modelleren .................................................................................................................. 11 Objecten en Klassen ...................................................................................................................... 11 Interactie tussen domeinobjecten ................................................................................................. 11 Interactiediagrammen .................................................................................................................. 11 Toestanden en gedrag van objecten .............................................................................................. 12 5 Modelmanagement....................................................................................................................... 12 Analysis Packages.......................................................................................................................... 12 Case Tools ..................................................................................................................................... 12 Quality Assurance ......................................................................................................................... 12

2

1 Analyse Kiezen van een ontwikkelproces Voor het ontwikkelen van software is een standaard aanpak noodzakelijk. Een software ontwikkelingsmethode biedt 2 vormen van ondersteuning: 1) Een proces(stappenplan) dat men kan volgen, gebaseerd op het maken van modellen 2) Een aantal gestandaardiseerde notaties om de modellen in neer te schrijven. Watervalmethode/traditioneel ontwikkelen In deze aanpak vinden alle stappen sequentieel plaats. Voordat er aan een volgende fase begonnen kan worden, moet de vorige fase dus volledig voltooid zijn. Het waterval proces wordt ook wel cascade genoemd. Erg geliefde methode bij projectleiders, door duidelijk afgelijnde ‘milestones’. Requirements Analysis  Design  Program  Testing Nadelen van de watervalmethode: 1) Het systeem houdt geen rekening met de evolutie van vereisten(Requirements) 2) Testen kan pas helemaal aan het einde van het volledige proces 3) Er zijn hoge kosten voor aanpassingen op het moment dat het systeem niet voldoet aan de wensen van de klant

Agile –Methoden Om aan de tekortkomingen van het waterval proces te beantwoorden is er een werkwijze ontwikkeld die een incrementele en iteratieve aanpak vooropstelt 1) Incrementeel: functionaliteiten deelsgewijs ontwikkeld en toegevoegd aan een continu groeiende applicatie. 2) De verschillende fases van het ontwikkelingsproces worden meerdere keren herhaald. Agile manifesto Dit is de definitie van een doeltreffende en moderne software- ontwikkelmethodologie. Het bestaat uit 4 punten: 1) Medewerkers en onderlinge interactie primeren over processen en tools 2) Werkende software is belangrijker dan uitgebreide documentatie 3) Goede samenwerking met de klant primeert over contractonderhandeling 4) Proactief inspelen op veranderingen is belangrijker dan het volgen van een planning. Iteratieve ontwikkeling Agile staat veelal bekent door de iteratieve aanpak. Enkele voordelen hiervan zijn: 1) Het gebruik van korte iteraties werkt motiverend voor medewerkers 2) Als er ergens iets fout gaat binnen een iteratie, en de klant is niet tevreden met het resultaat, dan verliest men maximaal 2 tot 6 weken in plaats van maanden of zelfs een jaar. 3) Deze aanpak houdt rekening met de werkelijkheid. In het begin van het project is het namelijk onmogelijk om de vereisten van de klant nauwkeurig te beschrijven. In de iteraties worden de eisen en wensen verder verfijnt. Relatie met OO Doordat er kleine componenten (stukken functionaliteit) worden opgeleverd, worden hier wel zwaardere en specifieke eisen aan gesteld. E moeten gemakkelijk aanpasbaar en onderhoudbaar zijn. Daarnaast moeten componenten duidelijk beschreven interfaces hebben zodat ze onderling kunnen samen werken. Hiervoor is een objectgeoriënteerde taal eigenlijk onontbeerlijk. Unified Process Unified Proces, ofwel UP is een volledig ingevulde methode en bied werkwijzen, technieken, richtlijnen, standaarden en afbeeldingwijzen. Het is ontstaan uit de behoefte naar een goed 3

gedocumenteerd en beschreven software- ontwikkelingstechniek. Vaak wordt er verwezen naar RUP, waarbij de R staat voor Rational. Het is samengesteld uit verschillende werkwijzen. 1) Het is een verzameling van ‘best practices’ in een modern softwareproces 2) Het is een aanpasbaar kader waarin aangewezen processen voor je organisatie/probleem aangemaakt kunnen worden. UP heeft een processtructuur waarbij er twee dimensies zijn te onderkennen: De core flows. De core flows lopen over de gehele project, door de verschillende fasen van het project heen 1) Requirements: Dit is het verzamelen van de vereisten en het formuleren van de vereisten die door zowel door de teamleden als de klant kunnen worden begrepen. De vereisten worden verwerkt in use case diagrammen. Deze beelden de relatie tussen de gebruiker en de functionaliteiten uit. Een hulpmiddel om te controleren of aan alle vereisten zijn voldaan is: FURPS (Functionality, Usability, Relability, Performance en Supportability) 2) Analyse: Specificeren wat ontwikkeld moet worden. Het omvat het analyseren van het probleemdomein en het maken van een domeinmodel. Het systeem wordt van buiten af beschreven. 3) Design: Deze fase omvat het ontwerp van de architectuur van het systeem. Nadruk ligt op de interne werking van het systeem, en de uitwerking van de functionaliteit in termen van hardware en implementatiespecifieke technologie. Ook worden er beslissingen over strategieën genomen (database schema’s etc.) 4) Implementatie: In deze fase wordt het systeem gebouwd. Ontwerpmodellen worden vertaald naar code. Klassendiagrammen kunnen hier het beste voor gebruikt worden 5) Test: In deze fase wordt het systeem getest. Er wordt gekeken of het systeem voldoet aan de verwachtingen, maar ook om defecten uit de software te halen De fasen. UP bestaat uit 4 fasen: 1) Inception: Dit wordt ook wel de initieele fase genoemd. Deze fase bestaat uit 1 enkele iteratie. Er wordt geen software gebouwd in deze fase. De volgende dingen worden gedaan: a. De scope van het project opstellen b. Een uitgbreide risicoanalyse uitvoeren c. Een ‘proof of concept’ bouwen d. Een visie(Vision) document opstellen. Aan de hand van dit document wordt bepaald of het project al dan niet doorgaat 2) Elaboration: De gewenste functionaliteit wordt verder uitgediept. De volgende dingen worden gedaan: a. Mogelijke kritieke punten in de architectuur en het ontwikkelpad worden onderzocht. b. Componenten worden gedefinieerd. Deze zijn van hoge kwaliteit en maken deel uit van de uiteindelijke applicatie. Vereisten en analyse activiteiten zijn erg belangrijk, design en implementatie worden belangrijker, vooral aan het einde van de fase. c. Het skelet van de applicatie, ook wel kernarchitectuur genoemd, maken. 3) Construction: Design en implementatie worden hier belangrijker, vereisten en analyse komt meer op de achtergrond te staan. In deze fase wordt het volgende gedaan: a. Het skelet van de applicatie uitbreiden tot een volledig systeem b. Aan het einde van elke iteratie worden de afzonderlijke componenten uitvoerig getest en gelinkt. Deze releases kunnen in een testomgeving geplaatst worden. 4) Transition: In deze fase wordt er langzaam overgegaan naar de nieuwe situatie. De volgende dingen worden gedaan:

4

a. Opstarten piloot project waarbij de bètasoftware op een aantal pc’s geïnstalleerd wordt. b. Na feedback kleine aanpassingen in de code aanbrengen c. Productdocumentatie maken d. Eindgebruikers trainen e. Uitrollen van de final release DSDM DSDM staat voor Dynamic Systems Development Method. Het is een Rapid Application Development methode (RAD). Wordt voornamelijk gebruikt bij ontwikkeling van gecomputeriseerde informatiesystemen. Tijdens de ontwikkeling met DSDM komen steeds meer gedetailleerde specificaties boven water. Deze worden vervolgens op basis van prioriteiten ingedeeld. Timeboxes: Dit is een specifieke, afgebakende tijdsplanning. Hierin worden eerst de zaken opgeleverd die het belangrijkste zijn voor de bedrijfsbehoeften. Op deze manier kan snel resultaat behaald worden. XP XP staat voor Extreme Programming. Ook deze methode heeft een iteratieve werkwijze. Het is een erg pragmatische aanpak. De klant moet bij deze methode deel uitmaken en beschikbaar zijn voor het ontwikkelteam. Geschikt voor kleine projecten. XP promoot het gebruik van ‘pair programming’. Een medewerker richt zich volledig op de code, terwijl de andere fouten in de code of aanpak probeert te vinden. Na een tijd wisselen de medewerkers van rol FDD FFD staat voor Feature Driven Development. Dit is een aanpak waarbij het proces gedreven wordt door de features van het systeem.De onderscheidende processen binnen FFD zijn: 1) Bouwen featurelist 2) Opstellen planning per feature 3) Maken van design per feature 4) Bouwen van applicatie per feature

De plaats van analyse in het ontwikkelproces Analysis- model Het doel van het analysis- model is het verfijnen en structureren van de verzamelde vereisten. Dit model is een verzameling van diagramme, waarmee de vereisten van het systeem in beeld gebracht kunnen worden. Het zorgt er voor dat het systeem makkelijker begrepen kan worden. Materiële en technische aspecten komen niet ter sprake. Use case diagrammen en het domeinmodel zijn erg belangrijk. Use case model: Een use case bepaalt een reeks interacties tussen de externe actoren en het systeem dat we willen bouwen. Actoren zijn partijen die interactie aangaan met het systeem. Dit kunnen gebruikers zijn, maar ook een ander systeem Concept: Een concept is een voorstelling van iets dat ‘echt’ bestaat in het kader van het project dat men wil uitvoeren. Een concept hoeft niet per se tastbaar te zijn, ‘tijd’ kan bijvoorbeeld ook een concept zijn. Een concept wordt ook wel een conceptuele klasse genoemd. 5

Domeinmodel: Dit is een verzameling van concepten, samen met de associaties die bestaan tussen de concepten onderling. Representational gap: Deze term slaat op het verschil (‘gap’) dat bestaat tussen de concepten die verzameld worden in een domeinmodel (op basis van vereisten), en de klassendiagrammen die na grondige analyse en design worden aangemaakt. Artifacts van OO- Analyse Use case Model: Een use case bepaalt een reeks interacties tussen de externe actoren en het systeem dat we willen bouwen. Actoren zijn partijen die interactie aangaan met het systeem. Dit kunnen gebruikers zijn, maar ook een ander systeem. Er wordt onderscheid gemaakt tussen primaire en secundaire actoren: 1) Primaire actor: deze heeft bepaalde doelstellingen, en de actor gebruikt het systeem direct om deze te bereiken 2) Secundaire actor: deze heeft indirect baat bij het systeem. Het beschrijft een opeenvolging van succes en optionele faal interacties tussen actoren en het systeem, die noodzakelijk zijn om de dienst te leveren die het doel tevreden stelt. Een use case maakt gebruik van een black box aanpak. Het beschrijft dus alleen wat de functionaliteit is van het systeem, niet hoe dit technisch gerealiseerd wordt. De beschrijvingen worden geschreven in de taal van de klant. Use Case realization: Dit beschrijft de interne werking van de Use case. Voor elke Use case wordt de interne communicatie getoond door gebruik van een of meerdere diagrammen. Het toont de functionaliteit op systeemniveau. Dit is in de taal van de ontwikkelaar. Er worden twee stromingen onderscheiden tijdens de analyse: 1) Use case driven Development: Use Cases staan centraal in de UP methodologie. Alle UMLartefacten (afbeeldingen en diagrammen) worden hieruit afgeleid. 2) Responsibility driven development: Dit is het ombuigen van de gebruikelijke analyseaanpak naar een werkwijze waarbij objecten centraal staan. Een object is een voorstelling van een fysisch of logisch concept dat is afgeleid uit de vereisten van het project. Patterns: Hierin is vastgelegd welk werk een object krijgt toebedeeld. Objecten werken op een bepaalde manier samen. a. Controleur: 1 van de objecten speelt de baas b. Expert: welk object weet het antwoord op een bepaalde vraag c. Creator: wie is verantwoordelijk voor het aanmaken van nieuwe objecten d. Low Coupling: objecten moeten met een minimaal aantal andere objecten kunne praten e. High Cohesion: objecten hebben graag gerelateerde verantwoordelijken. Er zijn een aantal regels die belangrijk zijn: 1) Iedere Use case(weergeven als ellips) is gerelateerd aan minstens 1 actor, of een andere Use case 2) Iedere Use case stelt een bedrijfsproces voor, dat bestaat uit verschillende stappen 3) Iedere Use case moet een toegevoegde waarde hebben voor de organisatie.

6

Use case scenario: Dit is een specifiek geval van een use case, het vertegenwoordigd 1 enkele weg door de use case. Het beschrijft de opeenvolging van stappen die worden gevolgd, vanaf de start tot een van de uitkomsten. Meestal werkt met met een basisscenario, ook wel ‘Happy path’ genoemd, waarna de verschillende uitzonderingen of alternatieven onder het basisscenario worden vermeld. Happy Path: Deze aanpak betekent dat de use case zonder problemen, en dus zoals verwacht wordt doorlopen. Sequence diagram: Dit diagram wordt gebruikt om de interacties te tonen tussen de actoren en het systeem. Ze worden ook wel ‘System Sequence Diagrams’ genoemd (SSD). Het legt de speciale nadruk op de volgorde waarmee de interacties tussen de actors en het systeem plaatsvinden. In dit diagram worden de actoren en het systeem als objecten voorgesteld boven aan het diagram, en elk object heeft zijn eigen ‘lifeline’(levenslijn). Deze lifeline wordt voorgesteld als een verticale onderbroken lijn, en de tijd verloopt van boven naar beneden. De interacties tussen de objecten worden weergeven in de vorm van pijlen met de naam van de interactie en eventuele parameters. Dit diagram is de eerste opstap naar het realiseren van een Use case, en wordt in een taal geschreven die meer aanleunt bij de ontwikkelaar. Elke ellips uit het Use Case diagram zal leiden tot 1 Sequence diagram. Soms wordt een event meerdere malen verstuurd, en is er sprake van herhaling. In het diagram wordt dit weergeven als een grote nota, met daarin een lus(loop) conditie. Deze bepaalt hoe vaak de lus wordt uitgevoerd. Message to ‘self’: Dit is de term die gebruikt wordt als een systeem interne dingen moet doen. Dit wordt weergeven als een pijl vanaf het systeem naar zichzelf. Een bericht naar het systeem toe kan parameters bevatten, een bericht vanaf het systeem naar de gebruiker kan nooit parameters bevatten! Domain model Een domeinmodel (domain model) bevat concepten die verzameld worden op basis van een analyse van de requirements. Naast de concepten zijn er ook associaties tussen de concepten, multipliciteit en attributen. De notatie van een domeinmodel is identiek aan een klassediagram, met uitzondering van enkele punten: Methodes en pijlpunten ontbreken. Alle associaties in een domeinmodel zijn bidirectioneel. De concepten in het domeinmodel worden getekend als rechthoeken met 2 vakken. In het eerste vak staat de naam, in de 2e staan de belangrijkste attributen. Class diagram Een klassendiagram (class diagram) is het uiteindelijke doel van de ontwikkelcyclus binnen 1 iteratie. Dit model kan worden omgebouwd naar code in een willekeurige object georiënteerde taal. Een klassendiagram is afgeleid uit een domeinmodel. De klassen in het model worden getekend als rechthoeken met 3 vakken. In het eerste vak komt de naam, in het 2 e vak komen de attributen en in het 3e vak komen de methodes. Meestal wordt er een kopie gemaakt van het domeinmodel, waar vervolgens de methodes aan toegevoegd worden. Activity Diagram Een activity diagram speelt een interessante rol tijdens de analyse. Het diagram is geschikt om een ‘if-then-else’ beslissing of workflow in te weergeven. Dit diagram wordt gebruikt om de 7

gedetailleerde Use case tekst aanschouwelijk te maken. Dit diagram bestaat uit een aantal ‘Swim lanes’. Deze lanes staan voor de verschillende actors. Dit zijn zowel personen als het systeem zelf. Het diagram start altijd met een zwart bolletje. Vanuit daar wordt de eerste activiteit gestart. Activiteiten worden weergeven als rechthoeken met afgeronde hoeken. Tussen de activiteiten staan pijlen waarmee de richting van het bericht wordt aangegeven. Voor plekken waar een beslissing (ja/nee) gemaakt wordt, wordt een ruit gebruikt. Test-first approach: met het diagram kan de applicatie getest worden voordat er een regel code geschreven is. State diagram Dit is een optioneel diagram en wordt ook wel State Machine genoemd. Dit diagram geeft de status van elk aspect binnen de ontwikkelcyclus weer, zoals de status van een bepaalde Use case. Meestal worden in dit diagram objecten gebruikt, omdat deze dynamisch zijn, en kunnen op basis van hun status bepaald gedrag vertonen. Een State diagram is alleen nuttig als er meerdere statussen zijn.

Agile methods Analysis Patterns Een pattern is een combinatie van een veel voorkomend probleem met een bijbehorende standaardoplossing. Patterns worden niet gemaakt, eerder ontdekt. Het voordeel van een geformaliseerd pattern is het vergemakkelijken van de communicatie tussen de leden van het project team. GRASP: General Responsibility Assignment Software Patterns. Deze patterns zijn geschikt om vragen met betrekking tot de ‘responsibility’ van de objecten te beantwoorden. Hieronder staan een aantal best practices: 1) Low Coupling: hier wordt getracht het aantal associaties tussen de concepten/klassen te beperken 2) High Cohesion: Hier dienen de verantwoordelijkheden binnen een klasse gerelateerd te zijn. 3) Expert: Hier wordt gekeken naar welk concept/klasse de informatie bezit om een taak uit te voeren 4) Creator: Hier wordt gekeken wie er verantwoordelijk is voor het aanmaken van een object. 5) Controller: Hier wordt gekeken naar welk concept/klasse de interface van het systeem voortsteld 6) Don’t talk to Strangers: Hier mogen de objecten alleen met de directe omgeving ‘praten’ 7) My creator is my savior: Hier is de object creator geschikt om het nieuwe object weg te schrijven. GOF patterns: Gang of Four. Deze patterns zijn technischer dan GRASP patterns. Deze worden later in de designfase ingezet door de designers, die het klassendiagram op stellen. GOF kent 23 patterns.

2 Statisch modelleren Statische modellen zijn erg geschikt voor het weergeven van de structuur van een systeem.

Bepalen van Analysis Classes 8

Use Case View en Analysis View Elk teamlid heeft een ander zicht (view) op een systeem. Binnen Unified Process zijn er 6 views gedefinieerd. De dikgedrukte views zijn het belangrijkste binnen deze studie. 1) Use case view 2) Analysis view 3) Design view 4) Implementation view 5) Deployment view 6) Test view Deze views komen niet exact overeen met de views die men in een case tool zal terugvinden. Case tools zijn namelijk niet gebonden aan een enkele methodologie.

Domain Modeling

Noun Phrase Identification

Common Concept Category List

Domain Model

Bouwen van een Domain Model

Opstellen van een initieel Domeinmodel Glossary

Analysis (conceptual) classes

Bepalen van Responsibilities

Operation Contract

Uml – diagrammen Uml class diagram

Operations

9

Associations

Attributes

UML object diagram

10

3 Statisch Modelleren – Detailleringen Associaties en Attributes Derived Attributes Multipliciteit Role Compositie Aggregatie Association Class Qualified Association Operations

Toepassen van Inheritance Polymorphisme Multiple Inheritance Inheritance andAnalysis Patterns

Uitbreiding Use Case Notatie Include Extend Inheritance

4 Dynamisch modelleren Objecten en Klassen Interactie tussen domeinobjecten Objecten en methodes Use Case Realization

Interactiediagrammen UML Interactiediagram UML Sequence Diagram UML Communicatiediagram 11

CRC Card UML Interaction Overview Diagram

Toestanden en gedrag van objecten UML State Machine Diagram UML Timing Diagram Constraints Object Constraint Language

5 Modelmanagement Analysis Packages Architectuur UML Package diagram Opdelingscriteria

Case Tools Waarom Case Tools? Code generation Reverse Engineering Round- trip Engineering Teamwork

Quality Assurance Model review & peer review Model walkthrough Usage scenario testing Prototype walkthrough

12