Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Deel II: Modelleren en software ontwikkeling Hoofdstuk 7 Software ontwikkeling - Overzicht © 2005 Prof Dr. O. De Troyer, | pag. 1

Naïeve benadering • De vereisten voor het systeem worden geformuleerd en op basis hiervan wordt de code geschreven

Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 2

1

Naïeve benadering • Deze benadering leidt vrijwel altijd tot problemen: – Meer tijd nodig dan voorzien – Meer middelen (geld) nodig dan voorzien – Voldoet niet aan de verwachtingen

• Methoden voor het ontwikkelen van software zijn noodzakelijk Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 3

Software ontwikkelingsmethode • Een software ontwikkelingsmethode biedt twee vormen van hulp: – Een stappenplan (proces) dat men kan volgen • Meestal gebaseerd op het maken van modellen

– Een aantal notaties om de modellen in neer te schrijven • Meestal grafisch


2

Software ontwikkelingsmethode • UML is vrij populair als standaard notatie voor OO ontwikkeling • Er is minder eensgezindheid over het te gebruiken proces


Het waterval proces


3

Het waterval ontwikkelingsproces • Elke stap (fase) vertegenwoordigt een andere activiteit • Basis aannames van het waterval ontwikkelingsproces – De verschillende stappen vinden sequentieel plaats – Elke fase moet volledig beëindigd zijn voor de volgende kan aangevangen worden

• Meestal is er wel een vorm van feedback tussen de verschillende fasen Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 7

Het waterval ontwikkelingsproces • Oudste ontwikkelingsproces • Goed voor wel gekende systemen met weinig problemen en stabiele requirements • Dit is echter zelden het geval

• Nadelen • Het succes van het systeem enkel te verifiëren door testen • Testen kan pas op het einde van het volledige proces • Hoog risico: – We kunnen enkel zien of het systeem voldoet wanneer al het werk al gedaan is Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 8

4

Iteratief ontwikkelingsproces • Antwoord op de tekortkomingen van het waterval proces: – Incrementeel: volledig systeem wordt deel per deel ontwikkeld – Iteratief: de verschillende fasen van het ontwikkelingsproces worden verschillende keren herhaald

• De moderne ontwikkelingsprocessen zijn allemaal iteratief en incrementeel Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 9

Spiraal proces model • Uitgangspunt: – Meestal onmogelijk om iets van de eerste keer juist te hebben – Daarom worden de verschillende fasen verschillende malen herhaald

• De 4 kwadranten vertegenwoordigen de belangrijkste fasen • Geen vast proces Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 10

5

Unified Process (UP)

Verschillende activiteiten (workflows) in verschillende iteraties Elke fasen bevat verschillende iteraties

Verschillende fasen

De balans tussen de activiteiten is verschillend voor verschillende fasen


UML en UP • UML kan gebruikt worden met verschillende ontwikkelingsprocessen • Omdat UP ontwikkeld werd door de ontwerpers van UML wordt UML vaak gebruikt in combinatie met UP


6

Ontwikkelingsfasen • • • • • • • •

Systeem conceptie Analyse Design Implementatie Testen Training Ingebruikname Onderhoud


Ontwikkelingsfasen • Systeem conceptie – Bedenken van de applicatie; formuleren van de initiële vereisten


7

Ontwikkelingsfasen • Analyse – Doel is specificeren wat moet ontwikkeld worden; niet hoe het zal gebeuren – Het probleem/systeem moet men begrijpen voor men het kan oplossen/maken – Input: bestaande documenten, interviews, bestaande toepassingen, ... – Modellen om de problematiek te begrijpen


Ontwikkelingsfasen Analyse omvat: – Domein analyse • Het analyseren van het domein – deel van de reële wereld dat relevant is voor het systeem

• Het maken van het domein model – Beschrijft de relevante objecten en relaties in het domein

– Applicatie analyse (ook wel systeem analyse genoemd) • Focus is nu op de applicatie/het systeem zelf. – Verschillende gebruikers, gevraagde functionaliteit – E.g. Applicatie objecten ipv domein objecten » bestaan niet in het domein maar zijn relevant voor de applicatie

• Het applicatie model beschrijft het systeem van buiten af (niet de implementatie - zwarte doos principe) Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 16

8

Ontwikkelingsfasen • Systeem Design – Ontwerp van de architectuur van het systeem • Architectuur: – Hoog niveau plan van het systeem

– Beslissen over strategieën

• Klasse Design – Meer gedetailleerde modellen gericht op het realiseren van het systeem – Gebaseerd op de resultaten van de analyse fase en rekening houdend met het systeem design Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 17

Ontwikkelingsfasen • Implementatie – Het programmeren – Ontwerp modellen moeten vertaald worden naar code – Tools kunnen tot op zeker niveau automatisch code genereren


9

Ontwikkelingsfasen • Testen – Om fouten uit de software te halen – Om na te gaan dat het systeem inderdaad aan de verwachtingen voldoet • Zowel wat betreft functionaliteit • Als wat betreft gebruikersgemak

– Testen is niet enkel op het einde van het ontwikkelingsproces maar gedurende het gehele traject! Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 19

Ontwikkelingsfasen • Training – Opleiden van de gebruikers – Hoeveelheid afhankelijk van het systeem en de gebruikers


10

Ontwikkelingsfasen • Ingebruikname (deployment) – Installatie scripts nodig – Interactie met andere systemen mogelijk – Verschillen wat betreft OS – Soms lokalisatie nodig (aanpassen aan de lokale gewoonten - taal, cultuur, ...)


Ontwikkelingsfasen • Onderhoud – Oplossen van bugs – Nieuwe vereisten


11

Overzicht


Analyse • Probleembeschrijving (in natuurlijke taal) is de input – Onvolledig, niet precies, niet consistent

• Analyse moet dit omzetten naar precieze, ondubbelzinnige modellen • Domein Analyse & Applicatie Analyse


12

Overzicht


Domein analyse • Beschrijving van de domein (deel van de reële wereld) – Domein klassenmodel – Domein toestandsmodel – Domein interactiemodel


13

Domein Klassenmodel • Domein klassenmodel – klassen en relaties van het domein – Statische structuur is meestal stabieler dan de andere aspecten • Daarom belangrijk vertrekpunt

– Initieel model bevat meestal tekortkomingen • Verbeteren door iteraties


Domein toestandsmodel • Maak een toestandsmodel indien relevant – Identificeer klassen met toestandsafhankelijk gedrag – Maak de toestandsdiagrammen


14

Domein interactiemodel • Een interactiemodel is zelden relevant voor domein analyse – Nadruk ligt op de structuur van het domein


Overzicht


15

Applicatie analyse • Beschrijving van de applicatie – Applicatie interactiemodel – Applicatie klassenmodel – Applicatie toestandsmodel


Applicatie interactiemodel • Stappenplan – Baken de grenzen van het systeem af • Bepaal de actoren • Bepaal use cases

– Komen tot sequentiediagrammen • Maak scenario’s voor de use cases • Voeg variaties en uitzonderingen toe • Maak sequentiediagrammen voor de scenario’s

– Maak activiteiten diagrammen voor complexe use cases – Organiseer de actors en use cases – Check af met het domein model Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 32

16

Baken de grenzen af • Use cases delen het systeem op in delen en tonen wie betrokken is met elke deel • Ze beschrijven echter niet het dynamisch gedrag





17




Maak activiteitendiagrammen • Maak activiteitendiagrammen voor complexe use cases – Sequentiediagrammen geven niet duidelijk weer wanneer er keuze en alternatieven zijn


18




Organiseer actors en use case • Toevoegen van include, extend en generalizatie


19




Check af met domein model • De modellen moeten consistent zijn met het domein model – Actors, use cases, scenario's moeten gebaseerd zijn op klassen en concepten uit het domein model – Check of het domein model voldoende is voor de diverse scenario's


20

Applicatie analyse • Beschrijving van de applicatie – Applicatie interactiemodel – Applicatie klassenmodel – Applicatie toestandsmodel


Applicatie klassenmodel • Definieert nu de klassen van de applicatie zelf


21

Applicatie toestandsmodel • De klassen van de applicatie hebben meestal belangrijk toestandsafhankelijk gedrag • Stappenplan – Zoek de applicatieklassen met toestandsafhankelijk gedrag – Maak de toestandsdiagrammen – Check met de andere modellen voor consistentie Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 43

Voeg operaties toe aan applicatie klassenmodel • Definieer operaties voor de applicatie klassen – Basis operaties om attributen en associaties op te vragen/wijzigen • Mogen gedurende analyse weggelaten worden

– Operaties afkomstig van de interactie modellen – Operaties afkomstig van reële wereld operaties Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 44

22

Overzicht


Klasse Design • Doel – Analyse model verder uitwerken richting implementatie rekening houdend met de systeem design

• Niet nodig om te veranderen van techniek want OO geschikt voor analyse, design en implementatie • Niet nodig om een nieuw model te maken; we kunnen vertrekken van de applicatie klasse uit het applicatie klassenmodel Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 46

23

Klasse Design • Applicatie klassen verder uitwerken rekening houdend met – Uitvoeringstijd – Geheugen – Ander kostfactoren

• • • •

Beslissen over algoritmen Opsplitsen van complexe operaties Detail toevoegen - aanpassingen maken Iteratief proces


Implementatie • Implementatie door middel van OO taal is meest voor de handliggend, bijv. Java, C++, C# • OO talen hebben ook klassen en instanties • Voor sommige zaken is er geen overeenkomstig implementatie constructie: – associaties – toestandsdiagrammen

• Gebruik een systematisch en consistente benadering voor het implementeren ervan


24

Implementeren van klassen en instanties • Klasse en instanties – Ook in OO-talen – Terminologie kan licht verschillen, voorbeelden: • Instantie variabelen ipv attributen • Extend/derive ipv inherit • Static methods ipv Klasse methoden

– Er kunnen beperkingen of relaxaties zijn • Bijv. geen multiple inheritance • Bijv. Geen standaard encapsulatie van attributen

– Pure OO talen (bijv. Smalltalk) hebben geen ingebouwde datatypen en dus ook geen waarden (enkel objecten) – Meestal expliciete constructor – Opgelet met inheritance (zie later) Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 49

Implementatie Type verificatie en polymorfisme Polymorfisme Verschillende operaties in verschillende klasse kunnen dezelfde naam hebben. Vraag: welke methode moet gebruikt worden wanneer zo’n operatie opgeroepen wordt voor een object Oplossing late binding bij uitvoering wordt opgezocht tot welke klasse het object behoort. Indien in deze klasse een methode bestaat die de operatie implementeert dan wordt deze methode gebruikt


25

Implementeren van associaties in een programmeertaal • Associaties kunnen worden geïmplementeerd via referentie (pointers) attributen • Maar: – Laten maar navigatie toe in één enkele richting

• Leg de verantwoordelijkheid voor het bijhouden en wijzigen van de referentie bij slechts één klasse – Andere klassen hebben enkel toegang via een interface (operaties: getXXX, setXXX)


Implementeren van associaties in een programmeertaal • Geval 1: associatie wordt maar in één richting doorlopen – Implementeer de associatie via een referentie (pointer) attribuut naar het object in de vertrekklasse – Is de multipliciteit 1 dan simpele referentie zoniet verzameling van referenties • Een data structuur zoals een vector kan hiervoor gebruikt worden


26

Implementeren van associaties in een programmeertaal


Implementeren van associaties in een programmeertaal • Multipliciteit moet in de code gecheckt worden public Person(Company c) { if (c == null) { // throw NullLinkError } Employeer = c ; }


27

Implementeren van associaties in een programmeertaal • Geval 2: associatie wordt in beide richtingen doorlopen Implementeer maar 1 richting • via een referentie (pointer) attribuut in één van de 2 klassen

– De andere richting moet dan via een zoekfunctie Enkel zinvol wanneer de niet geïmplementeerde richting maar sporadisch dient gebruikt te worden


Implementeren van associaties in een programmeertaal • Geval 2: associatie wordt in beide richtingen doorlopen Implementeer beide richtingen • Beide richtingen via een referentie (pointer) attribuut naar het object • Voordeel : voor beide richtingen snelle toegang • Nadeel: bij update moeten beide referenties aangepast worden • Maak slechts 1 van de 2 klassen verantwoordelijk voor het onderhoud van de links


28

Implementeren van associaties in een programmeertaal


Implementeren van associaties in een programmeertaal • Geval 2: associatie wordt in beide richtingen doorlopen – Implementeer via een associatie object


29

Implementeren van associaties in een programmeertaal • Toegang minder snel dan bij het gebruik van referenties • Hashing techniek voor constante toegangstijd • Goed wanneer niet alle objecten van de klassen links hebben – Enkel ruimte voor de bestaande links


Implementeren van een associatie klasse • Associatie met een associatieklasse – Introduceer klasse voor associatie


30

Implementeren van een associatie klasse

class Registration { Registration(Student st) { student = st ; mark = 0 ; } private Student student ; private int mark ; } Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 61

Implementeren van een associatie klasse

public class Module { private Vector registrations ; public void enrol(Student st) { registrations.addElement( new Registration(st)) ; } } Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 62

31

Implementeren van klassen in een database • Relationele database

Indien een identificerend attribuut

Indien geen identificerend attribuut Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 63

Implementeren van associaties in een database Relationele database 1-to-many case


32

Implementeren van associaties in een database Relationele database many-to-many case


Implementatie van compositie • Sommige OO talen (bijv C++) laten toe dat objecten andere objecten bevatten – dus compositie

• Andere talen (bijv Java) laten alleen een referentie naar een ander object toe. – De eigenschappen van compositie (gelijktijdig bestaan) moet afgedwongen worden door middel van code Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 66

33

Implementeren van toestanddiagrammen Oplossing 1: door het bijhouden van de toestand door middel van een attribuut public class Account private final private final private final

{ int InCredit = 0 ; int OverDrawn = 1 ; int Suspended = 2 ;

private int state ; // … }


Implementeren van toestanddiagrammen


34

Implementeren van toestanddiagrammen •

•

Initiële toestand implementeren via de constructor public Account() { state = InCredit ; } Implementeren van de operaties via een switch public void withdraw(double amt) { switch (State) { case InCredit: if (amt > bal) { state = Overdrawn; } bal -= amt ; break ; case Overdrawn: case Suspended: break ; }

}


Implementeren van toestanddiagrammen • Groepeer toestanden voor samengestelde toestanden public void suspend() { switch (state) { case InCredit: case Overdrawn: state = Suspended ; break ; case Suspended: break ; } }


35

Implementeren van toestanddiagrammen (2) • Oplossing 2: – Representeer elke toestand door een klasse (toestandsklasse) – Elke toestandsklasse implementeert dan het gedrag voor elke operatie geldig in die toestand


Implementeren van toestanddiagrammen (2)

Algemeen geval: • De context klasse representeert de klasse met toestandsafhankelijk gedrag • De toestanden worden voorgesteld door instanties van de Stateklassen: – Elk context-object is geassocieerd met juist 1 state-object op elk moment in de tijd

• Wanneer een context-object een request krijgt delegeert hij dit daar het relevante state-object (door polymorfisme) Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 72

36

Implementeren van toestanddiagrammen (2)


Implementeren van toestanddiagrammen (2) • Or more general


37

Implementeren van toestanddiagrammen • Een gevolg is dat elke toestandsklasse toegang moet hebben tot het interne van de context klasse (zondigt tegen het principe van encapsulatie)


Goede en slechte programma ontwerpen • Wanneer is een programma ontwerp goed? • Goed – Modelleert een systeem dat aan de verwachtingen van de gebruiker zal voldoen – Is flexibel • Requirements veranderen snel! • De impact van veranderingen moet zo klein mogelijk zijn

– Realiseerbaar


38

Ontwerpprincipes voor programma’s 1. 2. 3. 4. 5. 6.

Lage graag van koppeling: “low coupling” Abstractie Hoge graad van samenhang:“high cohesion” Hergebruik Vervangbaarheid “Open-closed” principe


Low coupling: encapsulatie • Het principle van encapsulatie ondersteunt het principe van “low coupling” – Hoe minder koppelingen, hoe gemakkelijker dingen kunnen gewijzigd worden zonder veel impact op de rest – Wel noodzakelijk om te weten welke koppelingen er zijn • Interfaces – Definiëren waarop andere objecten/module zich mogen baseren – Leggen dus mogelijke afhankelijkheden vast Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 78

39

Encapsulatie interface interface

Black box

• Als de “black box” wijzigt zonder dat de interface wijzigt dan heeft dit geen effect op zijn gebruikers (andere modules, andere objecten, ...) – Vb. Implementatie van een methode kan wijzigen zonder dat de signatuur van de methode wijzigt


Abstractie • Abstractie De “gebruiker” moet afgeschermd worden van onnodige details – De concepten “encapsulatie” en “interface” laten dit toe • “Gebruiker” moet niet meer weten dan de interface om de module/interface te kunnen gebruiken • “Gebruiker” mag niet meer weten dan de interface om de module/interface te kunnen gebruiken – Ook wel “information hiding” genoemd


40

High cohesion • Een module/object zelf moet een hoge graad van samenhang hebben: “high cohesion” – Geen samenraapsel van losse dingen – Er moet een logisch verband zijn tussen de verschillende onderdelen • Bijv via associaties, inheritance, …

– Loskoppelen zou de regel van “low coupling” schenden! Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 81

Hergebruik • Hergebruik – Het opnieuw gebruiken van een module/object in een andere context – Daarom • object/module niet afhankelijk maken van een welbepaalde context/situatie


41

Vervangbaarheid • Vervangbaarheid – Het moet gemakkelijk zijn om een object/module te vervangen door een andere zonder dat dit een effect heeft op de gebruikers • Voorbeeld: sorteer-methode via buble sort te vervangen door quick sort

– Encapsulatie en interfaces ondersteunen dit


Open-closed principe Open-closed principe Betrand Meyer - 1998 (boek: ObjectOriented Software Construction) • Vaak maakt een klasse/deelsysteem gebruik van de diensten aangeboden door een andere klasse/deelsysteem – Supplier module: verleent de diensten – Client module : maakt gebruik van de diensten Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 84

42

Open-closed principe • Een module is gesloten indien het niet meer onderhevig is aan wijzigingen die een invloed kunnen hebben op clients – De module is stabiel – Clients kunnen de module gebruiken zonder dat men bevreesd moet zijn voor wijzigingen

• Een module is open indien het nog kan worden uitgebreid – Belangrijk voor onderhoud en algemene uitbreidbaarheid van het systeem

Open-closed principe – Probeer modules te maken die zowel open als gesloten zijn Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 85

Open-closed principe • Open-closed principe – Lijkt een contradictie – Daarom zijn mechanismen nodig die toelaten om een module uit te breiden zonder het te wijzigen – Interfaces en encapsulatie laten dit toe • clients mogen enkel afhankelijk zijn van de interface • Implementatie kan gewijzigd worden zonder de clients te beïnvloeden


43

Mechanismen - 1 • Encapsulatie principe voor klassen: – Alle attributen ‘private’ – Enkel de definitie van een publieke methode is zichtbaar, niet zijn implementatie – ‘Private’ methoden voor hulpmethoden

Alles wat onzichtbaar is kan gewijzigd worden zonder problemen voor de clients • Nadelen: – Sommige programmeertalen ondersteunen dit niet volledig – Niet elke client maakt gebruik van alles wat de supplier te bieden heeft • Niet expliciet aan te geven


Mechanismen - 2 • Abstracte Interface klassen – Introductie van een extra (abstracte) klasse • Definieert enkel de interface • Heeft geen attributen

Enkel de interface

Attributen en de implementatie Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 88

44

Mechanismen - 2 • De abstracte supplier klasse is – open • Functionaliteit kan worden toegevoegd door extra subklassen

– Gesloten • De concrete klasse kan worden gewijzigd zonder dat dit effect heeft op de clients

• Nadeel: – Wijzigingen aan de interface (abstracte interface klasse) hebben nog steeds een invloed op de clients


Mechanismen - 3 • Abstracte superklassen – alle superklassen in een systeem zouden abstract moeten zijn Motivatie in the context of open-closed principe: Voorbeeld:

• Initieel enkel één soort van rekening • Nu uitbreiding naar spaarrekeningen Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | pag. 90

45

Mechanismen - 3 • SavingsAccount is nu afhankelijk van CurrentAccount! – Wijzigingen aan CurrentAccount hebben invloed op SavingsAccount • De wijzigingen zijn niet noodzakelijk van toepassing op SavingsAccount – Overwriting wordt noodzakelijk – Of code in CurrentAccount nodig om uit te zoeken over welk soort rekening het gaat » Superklasse wordt afhankelijk van zijn subklasse » Toevoegen van subklasse niet meer zonder meer mogelijk


Mechanismen - 3 • Oplossing

Abstracte klasse


46

Mechanismen - 4 • Nadeel van abstracte interface klassen: – Wijziging aan de interface klasse impliceert wijzigingen bij de clients + in de concrete klasse(n) • Bijv. Toevoegen van een operatie


Mechanismen - 4 Oplossing:

• Abstracte Interface klassen loskoppelen – Concrete klasse niet meer als subklasse van de abstracte interface klasse


47

Mechanismen - 4 – Uitbreidingen nu via specialisaties van de abstracte interface klasse


48

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Recommend Documents