[Alg] Design Patterns & OO (technische) analyse

[whoami]

In navolging van Alarmnummers topic over design patterns en wie ze gebruikt, is het misschien tijd om die discussie eens opnieuw op te rakelen en een stap verder te gaan; nl. hoe je design patterns gebruikt, hoe je ze identificeert, etc....

Ik heb me de laatste dagen opnieuw even verder verdiept in design patterns; ik heb net dit boek uit.

In dat bovenvernoemde boek, en ook in het GoF boek, wordt er nogal eens verwezen naar Christopher Alexander's boek 'The Timeless Way of Building'.
Alexander is een architect, en z'n boek gaat over patronen in de bouwkunst; bepaalde ontwikkelaars hadden dit boek gelezen, en zijn zo op het idee gekomen om na te gaan of design patterns ook toepasbaar zijn op het gebied van software development. Zo is gekomen tot de 'design patterns' zoals wij -software ontwikkelaars- die kennen.

Nu vroeg ik me af of er hier mensen zijn die het boek van Alexander gelezen hebben, en of ze er ook zelf nieuwe inzichten mbt software development mee verworven hebben.

Ik vroeg me ook af hoe jullie te werk gingen bij de analyse en het ontwerp van een OO systeem en het identificeren van patterns in de probleemstelling.
Maken jullie bv gebruik van commonality/variabilty analyse, waarbij je dus abstracte classes/interfaces gaat gaan maken op basis van algemene 'verantwoordelijkheden' die je herkent in objecten in je probleemdomein en concrete classes gaat gaan afleiden daarvan die dan hun eigen specifieke implementatie hebben, etc....

* whoami is benieuwd.

[-FoX-]

Design Patterns.. Ik hoor er wel veel goeds over. Maar ik weet eigenlijk niet echt wat het allemaal met zich meebrengt. En bestaan er eigenlijk veel dergelijke patternen?
(De enige die ik ken is MVC, en de afgeleide voor swing (ui-delegate)).

Heeft er iemand misschien de zin om het even in simpele woorden uit te leggen. Wat je eraan hebt, en waarom het nuttig is dat mensen er zich op toeleggen.

[Verwijderd]

Dat is niet echt mogelijk Fox. Je zal echt zelf die patronen eens moeten bestuderen en uitproberen om ze te begrijpen. Soms gebeurt het zelfs dat je zo'n patroon onbewust gebruikt maar dan wist je de naam er gewoon nog niet van.
In een cursus COBOL van me stond eens dat het nadeel van OO was dat code onoverzichtelijker werd. Ik denk dat deze stelling eigenlijk wel waar is en dat programmeer patronen samen met een voorstelling ervan in UML er voor zorgen dat het ontwerp aan duidelijke regels verbonden wordt zodat je een beter zicht hebt op het geheel.

[Verwijderd]

Ik vergat nog op whoami te antwoorden.
Ik probeer wel OO patronen te gebruiken als ik aan het programmeren ben maar ik kan niet zeggen dat ik het echt goed kan. Nouja ik begrijp het idee achter de patronen wel en ik kan ze wel toepassen maar uiteindelijk moet je die samenvoegen tot een zinnig geheel. Iets waar ik duidelijk nog oefening voor nodig heb.
Vorig jaar had ik een vak systeemanalyse waarin we UML-analyse hebben gehad maar de leerkracht was vrij waardeloos met als resultaat dat alles wat ik ervan weet komt uit mijn eigen interpretatie van de materie zonder vaak een correct voorbeeld gezien te hebben. Het is een todo maarja :\

[whoami]

-FoX- schreef op 20 december 2003 @ 11:59:
Design Patterns.. Ik hoor er wel veel goeds over. Maar ik weet eigenlijk niet echt wat het allemaal met zich meebrengt. En bestaan er eigenlijk veel dergelijke patternen?
(De enige die ik ken is MVC, en de afgeleide voor swing (ui-delegate)).

Heeft er iemand misschien de zin om het even in simpele woorden uit te leggen. Wat je eraan hebt, en waarom het nuttig is dat mensen er zich op toeleggen.

Als je niet weet wat design patterns zijn, kan je misschien eerst even dit topic doornemen, (Ik had de link er nl. niet voor niets bijgezet. ) zodat we dit topic on topic kunnen houden.
Dit topic gaat nl. niet over 'wat' design patterns zijn, maar hoe je ze identificeert tijdens je OO analyse, en hoe je daarvoor te werk gaat.

[EfBe]

Functionele analyse -> FO -> Technische analyse -> TO.

OO komt pas ter tafel in TO. Een OO ontwerp kan het beste top down, net als een ORM/NIAM model (en nog altijd met de aloude Yourdon elementen zoals DFD's en DSD's. Mensen, software wordt al zolang gemaakt en die dingen zijn echt niet bedacht voor en door domme mensen). Het is belangrijk de 2-way mapping FO <-> TO goed in de gaten te houden, raakt deze mapping ondergesneeuwd dan kun je maintainability wel vaarwel zeggen.

Het gebruik van Design patterns zijn detailontwerpbeslissingen verwoordt in detailbeschrijvingen in het TO. Het is schrijnend soms hoe mensen met de details op het gebied van software design BEGINNEN ipv EINDIGEN. Iedereen die HBO/WO scholing op het gebied van informatica heeft genoten weet dat ontwerpen niet worden gemaakt met design patterns als basis. Ik vind het gebruik van 'architect' dan ook niet op zn plaats in deze discussie. Je ontwerpt een multi-tier transactionsysteem niet met behulp van designpatterns. Je gebruikt ze wellicht, maar dan alleen in een later stadium: wanneer details moeten worden ingevuld mbt hoe dit detail te realiseren of dat detail.

Stappen: "Ik wil functionaliteits-subonderdeeltje ABC implementeren." *kijk in lijst designpatterns* *beslis of een van de patterns voldoet voor dit onderdeeltje* *Beschrijf in het TO de details voor ABC zodanig dat een designpattern gebruikt kan worden / moet worden*.

Verder zijn er zoveel patterns bedacht, maar er zijn er maar een handjevol (3 of 4) die echt nuttig zijn, de rest is hetzelfde pattern in een nieuw jasje (of beter: ergens anders toegepast). Als je goed kijkt is het strategy pattern (implementeren van abstract/virtual methods in derived classes zodat functionaliteit kan worden 'ingeplugged' in generic code in de base class) eigenlijk het enige echte pattern.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 23:57 ]

[koli-man]

Design Patterns heb ik gewoon als een verplicht vak gekregen heb. Echter wel pas laat in de opleiding. Maar het vak duurt maar 7 weken en dat is eigenlijk te kort om er echt fatsoenlijk in te duiken.
Maar het vergt redelijk veel tijd om het écht te begijpen. Wij hebben ons beperkt tot het uitwerken en toepassen van een abstract factory pattern.
Bij een ander keuzevak wat ik heb gehad(OO JAVA) moest ik gewoon een vrij te kiezen pattern uitwerken. Heb ik toen gekozen voor het Memento Pattern.

Dit was een redelijk makkelijk te begrijpen en uit te werken pattern.
Als boek gebruikt wij dat boek van Duffy als ik het goed heb.

Voor veelvoorkomende problemen op een mooie en goede manier op te lossen(te omzeilen) is het zéker goed om design patterns te gebruiken. Dit doordat er steeds meer ervaring verkregen wordt door verschillende programmeurs en langzamerhand de (door ervaring) beste oplossing gekozen kan worden.

[MSalters]

Het idee dat je OO niet in je FO kan gebruiken is onzin. Je hebt gelijk als je zegt dat je OO in je TO kan gebruiken, maar eerder kan ook. Zoals je terecht zegt wil je de relatie FO-TO houden. Dat gaat het beste als je al vanaf requirements in OO-termen denkt.

Requirements zelf hebben natuurlijk niets met design patterns te maken; requirements zijn wensen van een klant en worden dus niet beinvloed door het daarna te gebruiken ontwikkelproces. Vanaf dat moment ga je echter nadenken over een oplossing. De analyse hoe je de requirements=functionaliteit realiseert is je Functionele Analyse. Op dat moment kun je al design patterns toepassen. Als je ziet dat de requirements vorschrijven dat er drie datastromen zijn, met vergelijkbare data in verschillende formaten, dan kun je in je FO al drie blokjes Adaptor tekenen. Dat is een design pattern, maar het beschrijft hoe je de functionaliteit realiseert.

Een belangrijke reden dat Design patterns nog niet dorgedrongen zijn tot een heleboel FOs is omdat een FO typisch aan een meer ervaren, oudere developer wordt overgelaten, die uit het pre-OO tijdperk komt. Als je 10 jaar lang TOs hebt gmaakt voor COBOL, en je moet dan FOs gaan schrijven voor Java of C++, dan is de verleiding groot om de OO methodologie links te laten liggen.

[whoami]

EfBe schreef op 20 december 2003 @ 13:20:
Het gebruik van Design patterns zijn detailontwerpbeslissingen verwoordt in detailbeschrijvingen in het TO.

Daar ben ik het niet mee eens.

Design patterns kan je in je systeem ontdekken door op hoog niveau naar je probleem kijkt, kan je al patronen ontwaren.
Je kan zien welke gelijkenissen in verantwoordelijkheden bepaalde objecten hebben, waardoor je gemeenschappelijke interfaces kunt zien.

Stel bv. dat je een tekenprogramma moet maken, dat cirkels, vierkanten, driehoeken, etc.... moet kunnen tekenen.
Als je je probleem bekijkt, dan kan je zien dat je programma figuren moet kunnen tekenen, en dat al die figuren (of het nu cirkels, vierkanten, .... ) zijn, bepaalde verantwoordelijkheden gemeen hebben. Ze moeten zichzelf bv kunnen tekenen, ze moeten hun coördinaten kunnen teruggeven, etc.... Daardoor kan je dus zien dat je een abstracte class/interface 'Figuur' hebt, waarvan 'Cirkels', 'Vierkanten', etc... concrete implementaties hebben.

Als je nu nog die figuren op verschillende manieren wilt tonen, bv. op een printer afdrukken, of op het scherm tonen, en je weet dat je op een scherm lijnen kunt trekken, en dat een printer dat ook doet, dan heb je opnieuw een 'gelijkenis', waarmee je een abstracte class / interface kunt maken.
Dan heb je nog een relatie nodig tussen de Figuren, en de Printer/Scherm classes.
Werk dat verder uit en je komt tot een Bridge pattern.

Het is schrijnend soms hoe mensen met de details op het gebied van software design BEGINNEN ipv EINDIGEN. Iedereen die HBO/WO scholing op het gebied van informatica heeft genoten weet dat ontwerpen niet worden gemaakt met design patterns als basis. Ik vind het gebruik van 'architect' dan ook niet op zn plaats in deze discussie. Je ontwerpt een multi-tier transactionsysteem niet met behulp van designpatterns. Je gebruikt ze wellicht, maar dan alleen in een later stadium: wanneer details moeten worden ingevuld mbt hoe dit detail te realiseren of dat detail.

Ik zeg niet dat je direct met patterns etc... moet beginnen. Patterns zijn ook niet een doel op zich, maar als je OO analyse doet, is het handig als je van het bestaan van die patronen afweet.
Je moet natuurlijk eerst functionele analyse etc gaan doen, maar eens je komt aan het ontwerpen van je classes, zijn patterns zeker interessant.
Echter, wanneer je slechts op het einde kijkt of je in jouw systeem bepaalde patterns kunt ontdekken/gebruiken, dan ben je IMHO verkeerd bezig. Als je patterns slechts als details ziet, dan denk ik niet dat je er goed gebruik van maakt.

_{Trouwens, ik heb maar 1x het woord 'architect' in de mond genomen bij m'n topicstart, en toen ging het ook over een 'echte' architect. Christopher Alexander is er nl. zoeentje die huizen bouwt.}

Verder zijn er zoveel patterns bedacht, maar er zijn er maar een handjevol (3 of 4) die echt nuttig zijn, de rest is hetzelfde pattern in een nieuw jasje (of beter: ergens anders toegepast). Als je goed kijkt is het strategy pattern (implementeren van abstract/virtual methods in derived classes zodat functionaliteit kan worden 'ingeplugged' in generic code in de base class) eigenlijk het enige echte pattern.

Ook hier ben ik het niet eens.
Patterns zijn wel meer dan enkel inheritance en polymorphy.
Als je naar de meeste patterns kijkt, dan zie je dat ze meestal nog een ding gemeen hebben: nl. encapsulation van een interface/abstract class.
In het strategy pattern bv, zie je dat een class een reference heeft naar een abstractStrategy, bij Observer bv zie je ook dat een subject een referentie heeft naar een abstractObserver, etc....

Daarnaast is een adapter pattern bv. ook heel nuttig als je reeds een bestaande class hebt die je kan hergebruiken, maar die niet aan een bepaalde interface voldoet.

Door gebruik te maken van interface encapsulation / inheritance en overriden van methods (wat in de meeste patterns wel gebeurt), kan je inderdaad nieuwe functionaliteit inpluggen in bestaande code. Zo kan je bij een abstract factory bv. ook een nieuwe factory inpluggen zonder dat je client systeem daar hoeft vanaf te weten. Bij een bridge kan je ook een nieuwe implementatie pluggen zonder dat het client programma er van hoeft af te weten, etc....

* whoami denkt dat hij hier ook afgedwaald heeft van de oorspronkelijke discussie.

[EfBe]

MSalters schreef op 20 december 2003 @ 14:00:
Het idee dat je OO niet in je FO kan gebruiken is onzin.

Elke letter implementatie-gerelateerde text in een FO is daar niet op zn plaats. Daarom haalde ik ook de 2 aan. Of iets in OO wordt geimplementeerd of niet, is ten tijde van het FO niet aan de orde, dat zijn implementatiebeslissingen.

Ik vind het verder voor bv applicaties die business processen gaan automatiseren sowieso raadzaam om niet te denken in OO omdat een business process procedureel is (veelal) en niet OO. In OO alles opschrijven vereist dus een vertaalslag, wat de duidelijkheid niet ten goede komt en ook niet nodig is.

[EfBe]

Eelis schreef op 20 december 2003 @ 13:58:
Ik ben het hier niet mee eens, en vermoed dat je een verkeerd idee van het doel van patterns hebt.

Nee hoor, in het geheel niet.

Je wijst patterns af omdat ze teveel zouden lijken op andere patterns, echter het bestaansrecht van patterns wordt nauwelijks bepaald door hun opzienbarend vernuft; het zijn juist vaak heel simpele structuren die zoals je al aangeeft vaak qua implementatie ook veel op elkaar lijken.

Ik wijs patterns helemaal niet af , integendeel. Echter ik relativeer de hype rond patterns en ook de grote hoeveelheid patterns die er zijn. Als je goed naar een veelvoud van patterns kijkt heb je in wezen 2 dingen:
1) de truuk
2) de toepassing van de truuk.

De truuk is in feite het strategy pattern. De toepassing van die truuk is het bestaansrecht van een pattern, echter het komt altijd weer op hetzelfde neer. En daar schuilt ook het gevaar: als je NIET snapt dat het telkens dezelfde truuk is, loop je het gevaar patterns toe te passen in situaties waar ze dus niet practisch zijn of zelfs schadelijk (anti-pattern).

Eén van de grote voordelen (en een voordeel dat jij lijkt te vergeten) van het documenteren van patterns is dat software-ontwikkelaars door het benamen van veelgebruikte structuren veel efficienter over (OO) softwaredesign kunnen communiceren. Of een structuur veel gebruikt wordt is daarom een veel belangrijkere factor bij het bepalen van pattern-waardigheid.
Voorbeeld: Als een collega jouw verteld dat hij een bepaald probleem met pattern X heeft opgelost, is het eigenlijk niet relevant of je het een nuttig of pattern-waardig pattern vindt; het belangrijkste is dat je meteen weet waar hij het over heeft en globaal weet hoe hij het probleem heeft opgelost.

Nou, als die collega niet documenteert HOE zonder in pattern-termen te vervallen is die collega wel fout bezig. Het benoemen van patterns is aardig, echter veel patterns hebben verschillende namen gekregen door mensen als Fowler, de Sun j2ee site met patterns, Microsoft die dingen benoemt, het oude GoF boek etc. Voor je het weet moet je EISEN dat iemand kennis heeft van een bepaald boek om uberhaupt te kunnen begrijpen waar het over gaat, terwijl dat in feite onzinnig is omdat softwarebeslissingen veelal zonder in pattern namen te vervallen kunnen worden beschreven. Overigens heetten patterns vroeger gewoon algoritmen, maar dat daargelaten.

Ik wil verder toevoegen dat patterns nuttig kunnen zijn, maar alleen als je ze bekijkt als: "ik heb situatie X, truuk T kan ik daarop toepassen door pattern P dat T gebruikt". Andersom is dus fout. Dat was dacht ik het topic toch, Whoami?

[EfBe]

whoami schreef op 20 december 2003 @ 18:45:
Daar ben ik het niet mee eens.
Design patterns kan je in je systeem ontdekken door op hoog niveau naar je probleem kijkt, kan je al patronen ontwaren.
Je kan zien welke gelijkenissen in verantwoordelijkheden bepaalde objecten hebben, waardoor je gemeenschappelijke interfaces kunt zien.

Stel bv. dat je een tekenprogramma moet maken, dat cirkels, vierkanten, driehoeken, etc.... moet kunnen tekenen.
Als je je probleem bekijkt, dan kan je zien dat je programma figuren moet kunnen tekenen, en dat al die figuren (of het nu cirkels, vierkanten, .... ) zijn, bepaalde verantwoordelijkheden gemeen hebben. Ze moeten zichzelf bv kunnen tekenen, ze moeten hun coördinaten kunnen teruggeven, etc.... Daardoor kan je dus zien dat je een abstracte class/interface 'Figuur' hebt, waarvan 'Cirkels', 'Vierkanten', etc... concrete implementaties hebben.

Dat zijn toch allemaal implementatie-gerichte aspecten? Dat soort dingen research je in het TO, nadat je weet welke functionaliteit (FO) je moet implementeren. In je FO hier al over nadenken is dodelijk, want je verliest dan meteen de slagvaardigheid die je krijgt wanneer je precies weet welke subset van de totale functionaliteit die mogelijk is hoeft te bouwen. Je vertroebelt je blik enorm wanneer het FO een TO wordt.

Als je nu nog die figuren op verschillende manieren wilt tonen, bv. op een printer afdrukken, of op het scherm tonen, en je weet dat je op een scherm lijnen kunt trekken, en dat een printer dat ook doet, dan heb je opnieuw een 'gelijkenis', waarmee je een abstracte class / interface kunt maken.
Dan heb je nog een relatie nodig tussen de Figuren, en de Printer/Scherm classes.
Werk dat verder uit en je komt tot een Bridge pattern.

TO materiaal. Sorry als ik banaal overkom, maar dit is echt basiskennis Informatica, je gaat dit soort dingen niet zitten ontwerpen in een FO.

Ik zeg niet dat je direct met patterns etc... moet beginnen. Patterns zijn ook niet een doel op zich, maar als je OO analyse doet, is het handig als je van het bestaan van die patronen afweet.

Valkuil-alert!
Het is ALLEEN handig te weten dat ze er zijn, wanneer je wat je MOET ontwerpen exact weet en dus naar een pattern op zoek kunt om je werk te besparen. In patterns denken is de geplaveide weg naar de wereld van de anti-patterns.

[whoami]

EfBe schreef op 20 december 2003 @ 19:17:
[...]

Dat zijn toch allemaal implementatie-gerichte aspecten? Dat soort dingen research je in het TO, nadat je weet welke functionaliteit (FO) je moet implementeren. In je FO hier al over nadenken is dodelijk, want je verliest dan meteen de slagvaardigheid die je krijgt wanneer je precies weet welke subset van de totale functionaliteit die mogelijk is hoeft te bouwen. Je vertroebelt je blik enorm wanneer het FO een TO wordt.


[...]

TO materiaal. Sorry als ik banaal overkom, maar dit is echt basiskennis Informatica, je gaat dit soort dingen niet zitten ontwerpen in een FO.

Ik heb ook nergens gezegd dat je patterns enzo al in je FO gaan bekijken.
Sterker zelfs; ik heb gezegd:

Je moet natuurlijk eerst functionele analyse etc gaan doen, maar eens je komt aan het ontwerpen van je classes, zijn patterns zeker interessant.

Valkuil-alert!
Het is ALLEEN handig te weten dat ze er zijn, wanneer je wat je MOET ontwerpen exact weet en dus naar een pattern op zoek kunt om je werk te besparen. In patterns denken is de geplaveide weg naar de wereld van de anti-patterns.

Ik zeg ook niet dat je moet ontwerpen in functie van patterns. Echter, als je bezig bent met TO, je je classes aan het ontwerpen bent, etc... dan kan je dmv bepaalde stappen te volgen, op 'patterns' uitkomen. Dan is het handig te weten welke bestaande patterns er zijn.

[alienfruit]

Volgens mij zijn hier mensen die geen verantwoording hoeven af te leggen aan niet informatica opgeleidde personen. Want als ik een Functioneel Concept krijg voor een nieuwe versie van een programma dan wil ik weten want de nieuwe versie te bieden heeft en wat gewijzigd wordt en niet wat voor voor me design pattern nou weer heeft gebruikt of wat voor schitterend OO model hij heeft bedacht voor functie X. Gewoon: Wie? Wat? Waar? Wanneer? Waarom?

Als ik namelijk een functioneel concept krijg, wil ik niet lastig worden gevallen met allemaal vaktermen en andere lollige informatica termen. Zo'n concept gaat bij mij linea recta de prullenbak in, en kan de product manager vrolijk opnieuw beginnen

[ Voor 23% gewijzigd door alienfruit op 20-12-2003 19:46 ]

[drm]

alienfruit:
Als ik namelijk een functioneel concept krijg, wil ik niet lastig worden gevallen met allemaal vaktermen en andere lollige informatica termen. Zo'n concept gaat bij mij linea recta de prullenbak in, en kan de product manager vrolijk opnieuw beginnen

Ik wil niet lullig doen, maar communicatie tussen vakmensen (in programmeerwereld) enerzijds en communicatie met andere mensen anderzijds is natuurlijk wel iets anders.

Als je die discussie voort wil zetten zie ik graag een mailtje van je @ drm[at]tweakers.net, anders hoop ik (stiekumpjus) dat je je afzondert van dit topic _{dat bedoel ik als uitdaging, ja}

[DiGuru]

Ik denk dat er twee verschillende dingen spelen over dit onderwerp.

Ten eerste, sommige programmeertalen geven je als programmeur de vrije hand: alles mag, het is aan jou om te zorgen dat het ook goed in elkaar zit. C++ is hier beroemd om. Andere programmeertalen stellen hele strikte regels waaraan je hebt te voldoen, de taal zelf bepaald hier wat er wel en niet mag. Dan voldoet je programma automatisch ook aan een heleboel regels zoals geschetst in die design patterns. Een mooi voorbeeld hiervan is Delphi.

Ik ben op heel wat "Best practices" seminairs geweest en heb heel wat van die methodieken onder ogen gehad. En ze beschrijven ruwweg wat je in C++ moet doen en vooral niet moet doen om goede programma's te creëren. Als ik (met mijn Delphi achtergrond) in C++ programmeer, doe ik het bijna automatisch zoals al die methodieken zeggen dat het moet. De taal stuurt je dus een bepaalde richting in.

Hiermee wil ik absoluut niet beweren dat Delphi beter is dan C++, wel dat je op het gebied van methodieken in de ene taal bijna verplicht bent om die te gebruiken, terwijl je daar in een andere taal zelf op moet letten.

Het tweede punt is, dat je eigenlijk bij het ontwerp van je programma en de datastructuren eigenlijk eerst moet beschrijven wat de minimale dingen zijn die er moeten gebeuren en die implementeren. Als je bijvoorbeeld iets doet met een ini-file, zou je dus het beste eerst een class kunnen maken die een file kan inlezen, het presenteert als een string array, je de optie geeft om een regel te lezen of schrijven en de file weer weg kan schrijven.

Daar kun je dan weer een class van afleiden die ook kommentaar wegfiltert en een regel kan splitsen in sleutels en waardes. En daar kun je dan weer een class van afleiden die ook om kan gaan met secties en zo.

Dat geld ook voor het functionele ontwerp: je moet eigenlijk de wensen en mogelijkheden van de toekomstige gebruikers op dezelfde manier onder handen nemen. Bekijk wat er minimaal moet gebeuren om de achterliggende functionaliteit mogelijk te maken en ga pas als dat werkt kijken naar de details en overige wensen.

Die twee dingen proberen de meeste methodieken je te vertellen, denk ik.

[alienfruit]

Ik zal deze discussie maar omzeilen, blijkbaar bestaan er twee soorten Functioneel Ontwerpen in de programmeerwereld. Zoja, dan zie ik graag een informatie bronnen. Sta altijd open om wat te leren. Moet eerlijk bekennen dat ik tijdens programmeersessie's het conceptmatig werken toepas wat ik heb geleerd tijdens mijn grafische opleiding. Oftewel doelgroep bepalen, bepalen wat deze primaire en secundaire doelgroep wilt en waarom etc. Vervolgens bepaal ik de functies die het project moeten hebben en wat hoge en lage prioriteit heeft en vervolgens ga ik aan de slag met de OO model en database model. Maar dat zal vast niet goed zijn volgens de programmeerwereld

offtopic:
Jaja, moest effe drm

Als je die discussie voort wil zetten zie ik graag een mailtje van je @ drm[at]tweakers.net, anders hoop ik (stiekumpjus) dat je je afzondert van dit topic [sub]dat bedoel ik als uitdaging, ja

Aah, dus je krijgt nog niet genoeg mailtjes? :-)

[ Voor 61% gewijzigd door alienfruit op 20-12-2003 22:52 ]

[MSalters]

EfBe schreef op 20 december 2003 @ 18:57:
[...]

Elke letter implementatie-gerelateerde text in een FO is daar niet op zn plaats. Daarom haalde ik ook de 2 aan. Of iets in OO wordt geimplementeerd of niet, is ten tijde van het FO niet aan de orde, dat zijn implementatiebeslissingen.

Als je OO puur als implementatie techniek ziet , dan heb je gelijk. Maar dat is een ongefundeerde aanname. Je neemt als uitgangspunt dat OO een implementatietechniek is, stelt vervolgens dat in je FO geen implementatietechniek hoort, en concludeert dat OO geen plaats heeft in je FO. Als je echter als uitgangspunt neemt dat OO ook functionele verhoudingen kan beschrijven, dan is het daarmee triviaal dat OO een plaats kan hebben in een FO.

Ik vind het verder voor bv applicaties die business processen gaan automatiseren sowieso raadzaam om niet te denken in OO omdat een business process procedureel is (veelal) en niet OO. In OO alles opschrijven vereist dus een vertaalslag, wat de duidelijkheid niet ten goede komt en ook niet nodig is.

Welnee, je ziet dat ook veel te somber in. Kenmerkend voor een business process is juist de aanwezigheid van een aantal actoren, die samenwerken om een doel te realiseren. Natuurlijk zijn er procedures in een business process (hee, da's een pattern ) maar dat kan uitstekend als een method van de principiele actor uitgevoerd worden. ( Een actor in een OO design is meestal een class in een OO implementatie )

[whoami]

EfBe schreef op 20 december 2003 @ 18:57:
[...]
Ik vind het verder voor bv applicaties die business processen gaan automatiseren sowieso raadzaam om niet te denken in OO omdat een business process procedureel is (veelal) en niet OO. In OO alles opschrijven vereist dus een vertaalslag, wat de duidelijkheid niet ten goede komt en ook niet nodig is.

Mwah, in een business systeem heb je toch ook bv. orders, klanten , etc...... Dit kan je beschouwen als objecten die bepaalde verantwoordelijkheden hebben; ze hebben maw bepaalde functionaliteit die ze kunnen uitvoeren zonder dat ze daarvoor andere objecten nodig hebben.
In een business systeem kan je imho ook wel patterns gebruiken. Stel bv. dat je een systeem hebt, waarbij er verschillende manieren zijn om kortingen te berekenen. Goeie klanten krijgen meer korting dan gewone klanten, etc..... Hiervoor zou je bv. een strategy pattern kunnen gebruiken.

EfBe schreef op 20 december 2003 @ 19:07:
De truuk is in feite het strategy pattern. De toepassing van die truuk is het bestaansrecht van een pattern, echter het komt altijd weer op hetzelfde neer. En daar schuilt ook het gevaar: als je NIET snapt dat het telkens dezelfde truuk is, loop je het gevaar patterns toe te passen in situaties waar ze dus niet practisch zijn of zelfs schadelijk (anti-pattern).

Patterns zijn natuurlijk geen doel op zich, maar een middel. Een middel om onderhoudbare, aanpasbare en goede software te maken.
Als je in je technische analyse situaties herkent waar je patterns kunt gebruiken, doe het dan. Je moet natuurlijk niet zoeken naar dingen die er niet zijn, gewoon omdat je een pattern zou kunnen gebruiken.

Nou, als die collega niet documenteert HOE zonder in pattern-termen te vervallen is die collega wel fout bezig. Het benoemen van patterns is aardig, echter veel patterns hebben verschillende namen gekregen door mensen als Fowler, de Sun j2ee site met patterns, Microsoft die dingen benoemt, het oude GoF boek etc.

Dat valt nogal redelijk mee. Het is gewoon handig als je tegen iemand kunt zeggen:
Voor de creatie van m'n objecten gebruik ik een abstract factory, of voor dit heb ik een strategy pattern gebruikt.
Als het goed is weet de andere al direct wat je bedoeld, hoe je het geimplementeerd hebt, zonder dat je in technische beschrijvingen en details moet gaan praten waardoor je het overzicht snel verliest.

Overigens heetten patterns vroeger gewoon algoritmen, maar dat daargelaten.

Mwah..... Patterns zijn wel wat meer dan een algoritme. Ze beschrijven de structuur van je data, en de relatie tussen je objecten.
Echt beschrijven hoe een bepaalde functie geimplementeerd is doen ze niet.

Ik wil verder toevoegen dat patterns nuttig kunnen zijn, maar alleen als je ze bekijkt als: "ik heb situatie X, truuk T kan ik daarop toepassen door pattern P dat T gebruikt". Andersom is dus fout. Dat was dacht ik het topic toch, Whoami?

Dat is het inderdaad, en dat is ook de bedoeling van m'n topic:
Hoe ga je tewerk bij TO om te bepalen welke classes je nodig hebt, hoe die classes met elkaar in relatie staan, en hoe ga je te werk om eventuele patterns in jouw probleemstelling te herkennen.

[ Voor 18% gewijzigd door whoami op 21-12-2003 19:03 ]

[MSalters]

whoami schreef op 21 december 2003 @ 19:00:

In een business systeem kan je imho ook wel patterns gebruiken. Stel bv. dat je een systeem hebt, waarbij er verschillende manieren zijn om kortingen te berekenen. Goeie klanten krijgen meer korting dan gewone klanten, etc..... Hiervoor zou je bv. een strategy pattern kunnen gebruiken.

Helemaal waar, maar geen onderdeel van je analyse cq FO. Het FO vertelt je dat er klanten zijn, die op basis van criteria X,Y en Z in categorieen worden verdeeld, en dat er prijzen zijn die per categorie verschillen volgens regels A,B en C.

Er speelt wel een business pattern, nl. "Vaste klantenkorting". Dat is het bekende pattern waarbij je je beste klanten korting geeft, omdat je de winst daar uit volume haalt. Business patterns zijn natuurlijk offtopic in /14, maar het is wel leuk om je te realiseren dat patterns ook buiten (software) architectuur te vinden zijn.

[bille]

Wat opzich wel een aardig boek is met als onderwerp Design Patterns:
Agile Software Development; Robert C. Martin

Opzich een erg interessant onderwerp. OO software ontwerpen kán erg complex zijn. Naarmate je je meer moet gaan conformeren aan standaarden wordt OO analyse en design steeds moeilijker. Echter het mooie aan software engineering is dat de schoonheid em vaak zit in de eenvoud van de oplossing.

Ik ben van mening dat mbt OO analyse en design en het toepassen van patterns er lang niet altijd sprake is van goed of fout. Vaak zijn doel en eenvoud een goed argument om niet volgens bepaalde regels te werken.

[Alarmnummer]

EfBe schreef op 20 december 2003 @ 13:20:
Functionele analyse -> FO -> Technische analyse -> TO.

OO komt pas ter tafel in TO. Een OO ontwerp kan het beste top down, net als een ORM/NIAM model (en nog altijd met de aloude Yourdon elementen zoals DFD's en DSD's. Mensen, software wordt al zolang gemaakt en die dingen zijn echt niet bedacht voor en door domme mensen). Het is belangrijk de 2-way mapping FO <-> TO goed in de gaten te houden, raakt deze mapping ondergesneeuwd dan kun je maintainability wel vaarwel zeggen.


Het gebruik van Design patterns zijn detailontwerpbeslissingen verwoordt in detailbeschrijvingen in het TO. Het is schrijnend soms hoe mensen met de details op het gebied van software design BEGINNEN ipv EINDIGEN. Iedereen die HBO/WO scholing op het gebied van informatica heeft genoten weet dat ontwerpen niet worden gemaakt met design patterns als basis. Ik vind het gebruik van 'architect' dan ook niet op zn plaats in deze discussie. Je ontwerpt een multi-tier transactionsysteem niet met behulp van designpatterns. Je gebruikt ze wellicht, maar dan alleen in een later stadium: wanneer details moeten worden ingevuld mbt hoe dit detail te realiseren of dat detail.

Design patterns worden meestal op laag nivo gebruikt, maar je hebt ook architectural patterns, en dan zijn dus dingen die imho erg hoog gebeuren. Een layered architecture zoals jij dat gewoonlijk gebruikt is ook een design pattern. En jij kan mij niet wijs maken dat dat iets is dat je pas aan het einde van het proces gebruikt. Verder ben ik het ook niet helemaal met je eens dat je een volledige analyse kan doen, en pas daarna kan gaan ontwerpen. De problemen die ik iedere keer voor de kiezen heb gehad waren dermate complex dat ik pas na verloop van tijd (als al een deel van het systeem is opgezet) nieuwe inzichten heb opgedaan en daarop eventueel ook het design heb aangepast. Software schrijven is vaak een iteratief proces en niet iets dat je van te voren helemaal kan uit-ontwerpen en dan pas schrijven.

Verder zijn er zoveel patterns bedacht, maar er zijn er maar een handjevol (3 of 4) die echt nuttig zijn, de rest is hetzelfde pattern in een nieuw jasje (of beter: ergens anders toegepast). Als je goed kijkt is het strategy pattern (implementeren van abstract/virtual methods in derived classes zodat functionaliteit kan worden 'ingeplugged' in generic code in de base class) eigenlijk het enige echte pattern.

Dit ben ik ook niet met je eens. De meeste patterns in het gof boek zijn wel aan elkaar gerelateerd (zie dat overzicht in het boek), maar ze hebben allemaal hun eigen toepassings gebied. En er bestaat meer dan alleen het gof boek aan patterns, er zijn de wereld uit waarmee je je leven een stuk plezieriger kunt maken. Waarbij je patterns kan vinden die idd op erg laag nivo toegepast kunnen worden, maar ook patterns waarmee je de structuur van je systeem definieerd.

Een van de auteurs van design patterns explained gaat zelf zo ver dat je je volledig systeem mbv patterns gaat opzetten. Eerst analyseren waar je de patterns kan inzetten die de grootste inpakt heeft. Deze pattern creeert de context waar je weer nieuwe kleinere patterns kan inzetten. Hij concludeert uiteindelijk dat deze manier van werken te stijf is, en die meening deel ik ook met hem. Maar het laat wel zien dat je design patterns al voordat de 1e regel op het papier staat in kan zetten.

[edit]
check anders deze maar eens:
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

[ Voor 10% gewijzigd door Alarmnummer op 22-12-2003 09:13 ]

[Alarmnummer]

EfBe schreef op 20 december 2003 @ 19:07:
[...]
De truuk is in feite het strategy pattern. De toepassing van die truuk is het bestaansrecht van een pattern, echter het komt altijd weer op hetzelfde neer. En daar schuilt ook het gevaar: als je NIET snapt dat het telkens dezelfde truuk is, loop je het gevaar patterns toe te passen in situaties waar ze dus niet practisch zijn of zelfs schadelijk (anti-pattern).

Een anti-pattern is niet zozeer een verkeerd toegepaste pattern, maar het herkennen van code waarin een probleem op een verkeerde manier is opgelost.

[ Voor 4% gewijzigd door Alarmnummer op 22-12-2003 09:03 ]

[Alarmnummer]

whoami schreef op 21 december 2003 @ 19:00:
[...]
Mwah, in een business systeem heb je toch ook bv. orders, klanten , etc...... Dit kan je beschouwen als objecten die bepaalde verantwoordelijkheden hebben; ze hebben maw bepaalde functionaliteit die ze kunnen uitvoeren zonder dat ze daarvoor andere objecten nodig hebben.
In een business systeem kan je imho ook wel patterns gebruiken. Stel bv. dat je een systeem hebt, waarbij er verschillende manieren zijn om kortingen te berekenen. Goeie klanten krijgen meer korting dan gewone klanten, etc..... Hiervoor zou je bv. een strategy pattern kunnen gebruiken.

Ik denk dat jij onderstaand boek dan erg interessant gaat vinden:
Domain-Driven Design: Tackling Complexity in the Heart of Software

[whoami]

Alarmnummer schreef op 22 december 2003 @ 09:31:
[...]

Ik denk dat jij onderstaand boek dan erg interessant gaat vinden:
Domain-Driven Design: Tackling Complexity in the Heart of Software

't Ziet er idd interessant uit.

Maar, om ff wat meer ontopic te komen; hoe ga jij te werk bij het identificeren van classes en de relaties daartussen?

[Alarmnummer]

whoami schreef op 22 december 2003 @ 11:02:
[...]
't Ziet er idd interessant uit.

Maar, om ff wat meer ontopic te komen; hoe ga jij te werk bij het identificeren van classes en de relaties daartussen?

Bij welk onderdeel bedoel je? Bij het opzetten van domein objecten of andere systemen?

[edit]
Ik heb weinig praktijk ervaring met enterprise applicaties moet ik erbij zeggen, alhoewel ik wel zeer geinteresseerd ben in het ontwerpen ervan. In al die wazige bedrijfslogica een goed ontwerp op te zetten is een kunst op zich. Vandaar ook mijn interesse voor rule-engines.

[ Voor 36% gewijzigd door Alarmnummer op 22-12-2003 11:33 ]

[whoami]

Alarmnummer schreef op 22 december 2003 @ 11:30:
[...]

Bij welk onderdeel bedoel je? Bij het opzetten van domein objecten of andere systemen?

Maakt dat dan een verschil uit?

[bille]

Als je goed kijkt is het strategy pattern (implementeren van abstract/virtual methods in derived classes zodat functionaliteit kan worden 'ingeplugged' in generic code in de base class) eigenlijk het enige echte pattern.

hehe.. als dat zo zijn zijn , ik noem even een paar praktische voorbeelden:
-Template pattern
-Command pattern
-Façade pattern
-Singleton pattern
-NULL Object pattern
-Factory pattern
-Adapter pattern
Allemaal patterns die zich toch zeker onderscheiden wat functionaliteit en bruikbaarheid betreft. Maar misschien snap ik je opmerking niet helemaal...

tja hoe ga je te werk?
bijv:
• 1) eerst ga je interviews houden met de gebruikers/domeindeskundigen. Daarbij gaat het natuurlijk om de functionele specificaties van het te onwikkelen systeem vast te leggen. Wat moet het doen? Wat zijn betrokken partijen. Hoe werken bepaalde processen die geautomatiseerd moeten worden?
• 2) De interviews ga je analyseren, domein objecten worden geidentificeerd, Usecase diagrammen maken, vast leggen welke informatie persistent gemaakt dient te worden e.d. (dit is ook een mooi moment om te beginnen met het prototypen van de GUI). In deze fase ga je ook kijken wat de relaties zijn tussen de functionele objecten, UML is hiervoor een goed middel om te beschrijven. UML dwingt ook af dat je op een bepaalde manier tegen objecten aan kijkt, namelijk zoals objecten werkelijk zijn. bijv: "Een fiets heeft een stuur", de "heeft een" relatie wordt in UML gedefinieerd als een associatie tussen de objecten "Fiets" en "Stuur". In een classdiagram zal je dus een object "Fiets" krijgen met daarin een referentie naar een object stuur (de implementatie is taal specifiek, in JAVA een classvariabele van het type "Stuur"). In handboeken UML zul je voldoende info vinden over de verschillende typen relaties en hoe zij zich manifesteren in taal ("has a"->reference, "is a"->super-/subclass, "consists out of"->aggregation, etc)
• 3) Aan de hand van het overzicht van domeinobjecten kán je vaak al een Class diagram maken van de functionele objecten die je hebt gedefinieerd. Hierbij gebruik ik zelf voornamelijk "Boerenverstand". Het lijkt mij enigszins logisch dat wanneer je de functionele objecten "Fiets" en "Auto" kent dat je dan bijv. een superclass maakt "Voertuig" en dan subclasses daarbij maakt "Fiets" en "Auto". Echter in sommige gevallen wil je dat juist niet, omdat er oneindig aantal verschillende implementaties zijn van het abstracte model "Voertuig", namelijk: een step is ook een voertuig, maar is geen fiets en ook geen auto. Wil je dus voertuigen gaan opslaan in je systeem, dan zul je een dynamisch ipv een statisch objectmodel moeten maken.
• 4) indien je van een eventdriven mechanisme gebruik maakt in je applicatie dan zul je objecten moeten gaan definieren (ook aan de hand van activity/flowchart diagrammen) die bepaalde handelingen in de GUI mogelijk maken. Daarnaast moet je interfaces ontwikkelen naar bepaalde systemen (DB's, etc). Die systemen hang je meteen achter een façade pattern. Het instantieren van domeinobjecten adhv data uit de db doe je dmv een Factorypattern. De domeinobjecten die je uit de db haalt implementeer je met een NULL object pattern, etc, ect.

Zo zouden de eerste stappen naar systeemontwerp er globaal uit kunnen zien. Ik probeer iig altijd in mijn achterhoofd te houden dat schoonheid em in eenvoud zit en niet in complexiteit. In de meeste gevallen moet je een afweging maken tussen "theoretisch correct" en "praktisch haalbaar" waarbij ik zou kiezen voor praktisch haalbaar (denk maar aan een ID kolom in een databasetabel; theoretisch niet correct, maar wel erg praktisch). Niemand zit te wachten op objectmodellen die zo extreem complex zijn dat je een prof. moet zijn om er wat van te begrijpen.

Hierop aansluitend, patterns zijn er ook voor om in bepaalde situaties helderheid en eenduidigheid te scheppen. Je past patterns toe zodat voor iedereen duidelijk is wat de functionaliteit is van je programmatuur.

Wat ik zelf lastig vind (en wat de ts begrijp ik ook vind) is het bepalen wanneer je een pattern kan toepassen. Het zijn vaak structuren die je ontdekt in het ontwerp waarin je een bepaalde situatie herkent. Het herkennen van- is vaak een kwestie van ervaring en kennis. Welke patterns zijn er allemaal? Welk probleem beoogt een pattern te tackelen etc. Het is vooral een kwestie van veeeeel lezen en de functie inzien van een pattern.

[ Voor 77% gewijzigd door bille op 22-12-2003 16:54 ]

[alienfruit]

Dispose Pattern

[whoami]

bille schreef op 22 december 2003 @ 16:05:
[...]

• 2) De interviews ga je analyseren, domein objecten worden geidentificeerd, Usecase diagrammen maken, vast leggen welke informatie persistent gemaakt dient te worden e.d. (dit is ook een mooi moment om te beginnen met het prototypen van de GUI). In deze fase ga je ook kijken wat de relaties zijn tussen de functionele objecten, UML is hiervoor een goed middel om te beschrijven. UML dwingt ook af dat je op een bepaalde manier tegen objecten aan kijkt, namelijk zoals objecten werkelijk zijn. bijv: "Een fiets heeft een stuur", de "heeft een" relatie wordt in UML gedefinieerd als een associatie tussen de objecten "Fiets" en "Stuur". In een classdiagram zal je dus een object "Fiets" krijgen met daarin een referentie naar een object stuur (de implementatie is taal specifiek, in JAVA een classvariabele van het type "Stuur"). In handboeken UML zul je voldoende info vinden over de verschillende typen relaties en hoe zij zich manifesteren in taal ("has a"->reference, "is a"->super-/subclass, "consists out of"->aggregation, etc)
• 3) Aan de hand van het overzicht van domeinobjecten kán je vaak al een Class diagram maken van de functionele objecten die je hebt gedefinieerd. Hierbij gebruik ik zelf voornamelijk "Boerenverstand". Het lijkt mij enigszins logisch dat wanneer je de functionele objecten "Fiets" en "Auto" kent dat je dan bijv. een superclass maakt "Voertuig" en dan subclasses daarbij maakt "Fiets" en "Auto". Echter in sommige gevallen wil je dat juist niet, omdat er oneindig aantal verschillende implementaties zijn van het abstracte model "Voertuig", namelijk: een step is ook een voertuig, maar is geen fiets en ook geen auto. Wil je dus voertuigen gaan opslaan in je systeem, dan zul je een dynamisch ipv een statisch objectmodel moeten maken.

Het is vooral deze stap die me interesseert.
Ik vroeg me af of er bepaalde mensen zijn die een bepaalde werkwijze hanteren om die classes te gaan maken, zoals bv. Commonality/Variabelity analyse, waarbij je gaat gaan kijken of er objecten zijn die gemeenschappelijke eigenschappen/verantwoordelijkheden hebben, en waar je dus een interface/abstract class kunt van maken; de specifieke implementatie ervan doe je dan in derived classes.

Wat ik zelf lastig vind (en wat de ts begrijp ik ook vind) is het bepalen wanneer je een pattern kan toepassen. Het zijn vaak structuren die je ontdekt in het ontwerp waarin je een bepaalde situatie herkent. Het herkennen van- is vaak een kwestie van ervaring en kennis. Welke patterns zijn er allemaal? Welk probleem beoogt een pattern te tackelen etc. Het is vooral een kwestie van veeeeel lezen en de functie inzien van een pattern.

Dat is niet zozeer mijn probleem.

Als je begrijpt hoe bepaalde patterns tot stand kunnen komen, en weet wanneer je een pattern kunt toepassen (als je het probleemgebied van het pattern kent), dan is het wel redelijk makkelijk om te bepalen welke patterns geschikt zijn.
Echter, wat ik me dan weer wel afvroeg: heb je een bepaalde methodiek om tot een bepaald pattern te komen, of is het -bij wijze van spreken- gewoon natte vinger werk.

alienfruit schreef op 22 december 2003 @ 18:19:
Dispose Pattern

Het dispose pattern kan je misschien wel als 'design pattern' beschouwen, maar het is toch iets anders dan bv. een strategy/bridge/.... pattern.
Met het 'dispose pattern' zorg je er gewoon voor dat je geen code hoeft gaan dupliceren; je zorgt er gewoon voor dat de Dispose() en Finalizer (in .NET) van dezefde method gebruik gaan maken:
bv:

code:

public void Dispose()
{
    Dispose(true);
    GC.SupressFinalize();
}

~MyClass()
{
   Dispose(false);
}

protected override void Dispose( bool disposing )
{
    if( disposing )
    {
          // Managed resources vrijgeven
    }
     // unmanaged resources vrijgeven.
}

[ Voor 11% gewijzigd door whoami op 22-12-2003 19:31 ]

[bille]

heb je een bepaalde methodiek om tot een bepaald pattern te komen

ehm, leg dat is uit? Voor zover ik weet pas je een pattern toe in je ontwerp, dus ik begrijp bovenstaande vraag niet helemaal.

Als je bedoelt: Hoe kom je er achter waar je een bepaald pattern kan gebruiken in je design?
Ik gebruik zelf een aantal regeltjes, bijv: Maak je gebruik van een "extern" systeem? Ontwikkel de interface naar dat systeem via een façade pattern. Een ander voorbeeld: Zijn er objecten die vanwege logische redenen slechts 1 maal mogen voorkomen in je systeem (objectbrokers e.d.)? Gebruik een Singleton pattern. etc etc.

Als je bedoelt: Hoe implementeer je een pattern in je systeemontwerp?
Dat hangt af van veel factoren en met name welk pattern je precies wilt implementeren.

Over de werkwijze:
Ik denk dat je hierbij even een duidelijk onderscheidt moet maken tussen:
• System Analysis & Design
• Software engineering

Systeem analyse richt zich op het zowel functioneel als technisch beschrijven van een softwarepakket, dwz: diagrammen maken, specs uitwerken e.d.
Software engineering richt zich op bouwen van de software, het coderen en bijv. het managen van packages.

Het onderscheid is imho nodig omdat beide wel érg dicht tegen elkaar aanliggen op een bepaald punt. Dat is het punt waar diagrammen vrijwel 1 op 1 kunnen worden vertaald in code. Men heeft snel de neiging om een UML Class diagram direct om te zetten naar code en that's it.

Whoami, waar jij het over hebt zijn verschillende dingen uit beide vakgebieden. Het bepalen van domeinobjecten en de onderlinge relaties zijn System analysis & design vraagstukken. De patterns zijn een beetje verdeeld. Er zijn system design patterns, maar ook software engineering patterns en een aantal zweeft tussen beiden. Het façade pattern is een goed voorbeeld van een pattern dat juist vanuit analyse & design naar voren komt. Je bent tijdens analyse en design namelijk bezig te bedenken dat jouw database server wel eens een aparte server zou kunnen worden, dus moet je ervoor zorgen dat de aanpassingen in je code minimaal zijn. Dat bewerkstellig je door een eenduidige interface naar je dbserver, met een "centraal aanspreekpunt".

Software engineering daarentegen vindt zijn grondslag in het programmeren en gaat van daaruit beschrijven en ontwerpen. Patterns die je gebruikt als software engineer zullen veelal patterns zijn die bepaalde programmeertechnische problemen tackelen (zoals bijv. een singleton, hoe anders kan je garanderen dat er slechts 1 instantie is van het object?). Bij het maken van een technisch ontwerp kan je door je software engineeringsbrilletje kijken en bijv. een aantal princiepes toepassen zoals: The Single-Responsibility principle of The Dependency Inversion principle. Door deze princiepes te gebruiken zal je zien dat je ook bepaalde niveaus van abstractie gaat aanbrengen in je code door gebruik te maken van abstract classes en interfaces en noem maar op. Deze hebben echter geen r33t temaken met de domein specifieke objecten zoals "Fiets" e.d.

Mijn vraag aan jou is: over wat voor soort analyse en design heb je het? vanuit een Systeem ontwerp oogpunt of vanuit een software engineering oogpunt?

[ Voor 64% gewijzigd door bille op 22-12-2003 21:15 ]

[whoami]

Ik kick dit topic nog maar even.

Het ging niet alleen over design patterns, maar ook over 'algemene OO analyse'; het gaat dus niet zozeer over het 'implementatie-niveau', maar eerder over het conceptuele.

Ik vroeg me dus oa ook af, of jullie bv. deze richtlijnen toepassen:
- programmeren volgens een interface;
- gebruik maken van 'composition' ipv inheritance als dat mogelijk is;
- hetgeen 'varieert' encapsulaten (dmv commonality/variabilty analyse*).

*Met commonality/variability analyse bedoel ik dus, dat je gaat gaan kijken welke verschillende 'objecten', 'abstracties', .... er zijn in je model die dezelfde 'verantwoordelijkheden' hebben, en waar je dus een abstracte class of een interface voor gaat gaan maken, en voor iedere specifieke implementatie een specifieke implementatie gaat gaan maken (concrete class).

Dus, welke technieken gebruiken jullie? Maken jullie oa gebruik van bovenstaande technieken, of gaan jullie eerder voor ieder zelfstandig naamwoord in je analyse een class gaan definieren, en methods gaan definieren voor de 'werkwoorden' die je in die analyse hebt ?

_{BTW, heeft er iemand dat boek van Christopher Alexander gelezen?}

[whoami]

Ik heb hier ondertussen een link gevonden (pdf document) over -ondermeer- commonality/variability analyse. (Het is de thesis van James 'Jim' Coplien, en wordt vermeld in de bibliografie van het boek 'Design Patterns Explained. Blijkt dat die gast aan de Vrije Universiteit Brussel gestudeerd heeft. )

Thesis van Coplien

[Verwijderd]

Zoals hier al meerdere malen naar voren is gekomen zijn er patterns op heel veel verschillende niveaus:
-proces niveau: Progress-oriented Patterns (bijv. Building a low fidelity prototype [Seffah03])
-implementatie-niveau: Technical Design Patterns (GoF), User-interface Design Patterns (http://www.welie.com), ...
-analyse niveau: analysis patterns

Ik ben zelf net begonnen aan mijn afstudeerproject over zogenaamde Functional Design Patterns (ik weet het, een beetje verwarrende naam maar het bedrijf waarbij ik dit doe heeft dit nou eenmaal bedacht).
Dit zijn patronen binnen het FO van een applicatie (analyse niveau) en met name dingen als 'enititeitenbeheer' (met weer sub-patterns als 'entiteitenoverzicht', 'entiteitdetail' etc.) en 'meerjarige berekeningen'. Oftewel patronen die in veel applicaties binnen een domein terugkomen en waarvoor het zeer nuttig is om vast te leggen wat deze 'functionaliteit' moet bieden, de rationale erachter en op welke manier.
FDP's zijn een beetje te vergelijken met Analysis Patterns (Martin Fowler); APs mappen (concrete) bedrijfsconcepten echter gelijk naar een object-model terwijl FDP's veel algemener zijn.
Deze patronen zouden als uitgangspunt kunnen dienen voor Generative Programming. Er zal hiervoor toch een mapping moeten zijn tussen deze patronen en uiteindelijke implementatie (maar dit hoeft niet perse object-georienteerd te zijn). Bijvoorbeeld door FDP's te combineren met Feature-Oriented Programming (FODA [Kang90] ). Features beschrijven de overeenkomsten/verschillen tussen verschillende producten binnen een productlijn (hebben het hier over maatwerk-systemen). Features beschrijven in zekere zin op lager niveau FDP's.

In hoeverre denken jullie dat het vastleggen van dit soort patterns (FDP's) zinnig is?

btw. whoami -> een mooie site over het boek van Christopher Alexander: http://www.jacana.org.uk/pattern/

[Alarmnummer]

Verwijderd schreef op 06 januari 2004 @ 20:13:
Zoals hier al meerdere malen naar voren is gekomen zijn er patterns op heel veel verschillende niveaus:
-proces niveau: Progress-oriented Patterns (bijv. Building a low fidelity prototype [Seffah03])
-implementatie-niveau: Technical Design Patterns (GoF), User-interface Design Patterns (http://www.welie.com), ...
-analyse niveau: analysis patterns

Gelukkig iemand dit dit ook inziet. Patterns zijn niet alleen iets dat je op het allerlaagste nivo toepast.

Dit zijn patronen binnen het FO van een applicatie (analyse niveau) en met name dingen als 'enititeitenbeheer' (met weer sub-patterns als 'entiteitenoverzicht', 'entiteitdetail' etc.) en 'meerjarige berekeningen'. Oftewel patronen die in veel applicaties binnen een domein terugkomen en waarvoor het zeer nuttig is om vast te leggen wat deze 'functionaliteit' moet bieden, de rationale erachter en op welke manier.

Ken je Domain-Driven Design: Tackling Complexity in the Heart of Software? Hierin staan oa design patterns te bouwen om domein modellen te vertalen naar object modellen.

FDP's zijn een beetje te vergelijken met Analysis Patterns (Martin Fowler); APs mappen (concrete) bedrijfsconcepten echter gelijk naar een object-model terwijl FDP's veel algemener zijn.
Deze patronen zouden als uitgangspunt kunnen dienen voor Generative Programming. Er zal hiervoor toch een mapping moeten zijn tussen deze patronen en uiteindelijke implementatie (maar dit hoeft niet perse object-georienteerd te zijn).

Ken je MDA? Model Driven Architecture. Dmv een opeenvolging van model transformaties kom je uit bij een uiteindelijke implementatie. Op amazon staan hier wel een aantal boeken over, bv: MDA Explained: The Model Driven Architecture--Practice and Promise. Ik vond het zelf heel interessant om te lezen maar ik ben eigelijk nog veel te bang om vast te zitten in de beperkingen van de transformatoren. Maar ben het er wel mee eens dat er een ontwerp een veel belangrijker onderdeel moet zijn in het ontwerp proces. Daarmee bedoel ik niet dat er niet genoeg tijd aan design wordt besteed, maar dat het model een actief onderdeel wordt van het ontwikkeltraject ipv een papieren passief onderdeel.

Bijvoorbeeld door FDP's te combineren met Feature-Oriented Programming (FODA [Kang90] ). Features beschrijven de overeenkomsten/verschillen tussen verschillende producten binnen een productlijn (hebben het hier over maatwerk-systemen). Features beschrijven in zekere zin op lager niveau FDP's.

Het klinkt in ieder geval zeer interessant, alhoewel ik me er nog weinig concreets bij kan voorstellen.

[edit]
Als de boeken je iets lijken, dan moet je me ff mailen.

[ Voor 7% gewijzigd door Alarmnummer op 06-01-2004 20:44 ]

[EfBe]

Gelukkig iemand dit dit ook inziet. Patterns zijn niet alleen iets dat je op het allerlaagste nivo toepast.

Je laat het klinken alsof dat de enige mogelijkheid is om software te maken.

Patterns zijn oplossingen voor problemen. Constateer je de problemen, dan kun je patterns gebruiken om ze op te lossen.

Wat me een beetje een wrange smaak in de mond geeft in deze thread is het feit dat als je niet op het Domain model treintje zit je kennelijk op een minder niveau software aan het designen bent. Niets is minder waar! Wat er toe doet is een zo sterk mogelijke verbinding te creeeren tussen functioneel ontwerp (op een abstract niveau) en de gerealiseerde code. Als je ontwerp more procedureel gericht is omdat je business processes aan het modelleren bent geweest, is het van het GROOTSTE belang dat je je code daar dichtbij houdt.

Ik moet elke keer weer lachen als ik artikelen lees over hoe toch de vertaalslag te maken van ontwerp naar een domain model. Dat is oplossingen zoeken voor problemen die er helemaal niet zijn! OO, Domain model etc. zijn middelen, geen doelen. Patterns zijn oplossingen voor problemen along the way, middelen, niet doelen.

In alle gevallen geven patterns antwoord op de vraag HOE, niet op de vraag WAAROM. 'Waarom' vraag je je af om je ontwerp te maken en te vervolmaken, beslissingen te nemen. HOE is voor de fase(s) erna.

Maar goed, dat is welhaast praten tegen een stoel. Ik heb niets tegen nieuwe technologieen die verzonnen worden, ik ben dan ook een groot voorstander van serviced based architecture (SOA) eventueel op basis van OO, maar in deze thread worden MIDDELEN tot DOELEN verheven, en ik kan niets anders zeggen dan: DOE DAT NIET. Je hoeft het niet van me aan te nemen, maar goed, ik ben niet van gisteren noch ongeletterd, it's up to you.

[ Voor 14% gewijzigd door EfBe op 06-01-2004 21:52 ]

[whoami]

Ik ben het met je eens EfBe, over het feit dat patterns geen doel, maar een middel zijn. (Iets wat ik enkele maanden (misschien wel meer dan een jaar geleden hier ook al eens gezegd heb).

Patterns zijn een middel om robuste, flexibele, onderhoudbare OO software te schrijven. Het zijn nl. concepten die 'proven' zijn.

Als je OO gebruikt om je software te maken, dan kan je patterns gebruiken. Als je patterns kunt herkennen in je probleemmodel, dan gebruik je ze best. Ik bedoel maar: Als je in je context een situatie ziet waarvan je zegt: dit kan opgelost worden door pattern X, waarom zou je het dan niet doen?

De bedoeling van dit topic was dan ook:
- Hoe ga je te werk bij OO analyse: hoe ga je de classes uit je context gaan herkennen/definieren?
- Slaag je met de door jou gebruikte methode er dan ook in om patterns te herkennen/af te leiden?

[Alarmnummer]

EfBe schreef op 06 januari 2004 @ 21:47:
[...]

Je laat het klinken alsof dat de enige mogelijkheid is om software te maken.

Nee zeker niet, maar je heb zelf een tijd geleden aangegeven dat patterns alleen op het allerlaagste nivo gebruikt konden worden en daarmee ben ik het dus niet eens. Patterns moet je wat ruimer in zien. Als jij software ontwikkeld dan doe jij dit ook volgens een vast strammien, hierbij heb jij ook technieken naar verloop van tijd ontwikkeld die jou goed zijn bevallen. Patterns zijn in dat opzicht niets anders, het is kennis die mensen hebben opgedaan geformuleerd in een wat strakker jasje. Het zorg ervoor dat je als leek zijnde makkelijker proffesionele kennis onder de knie krijgt dan dat je het door de jaren heen dmv vallen en opstaan hebt moeten ontdekken. Een ander voordeel aan patterns dan minder formeel beschreven kennis is dat je meestal ook beter de voors en tegens voor een bepaalde oplossing kent (omdat tig andere mensen al op hun gat zijn gegaan bv), en het maakt het communiceren een stuk makkelijk doordat iedereen dezelfde woordenschat heeft. Als ik tegen jou zeg layer, dan verwacht ik dat jij weet wat dat is ipv dat ik je helemaal moet uitleggen wat een layer is.

Maar tegenwoordig is het wel pattern voor en pattern na. Daar 'stoor' ik me ook wel eens aan omdat bijna alles wel als pattern te omschrijven valt. Maarja.. beter te veel patterns.. dan te weinig. Patterns zorgen ervoor dat je kwalitatief betere software kan afleveren.

Wat me een beetje een wrange smaak in de mond geeft in deze thread is het feit dat als je niet op het Domain model treintje zit je kennelijk op een minder niveau software aan het designen bent. Niets is minder waar! Wat er toe doet is een zo sterk mogelijke verbinding te creeeren tussen functioneel ontwerp (op een abstract niveau) en de gerealiseerde code. Als je ontwerp more procedureel gericht is omdat je business processes aan het modelleren bent geweest, is het van het GROOTSTE belang dat je je code daar dichtbij houdt.

Ik snap niet helemaal wat je bedoelt. Domein model is niet gekoppeld aan een bepaald paradigma maar is gewoon een abstractie van een bepaald domein. Dit lijkt me onmisbaar.

Ik moet elke keer weer lachen als ik artikelen lees over hoe toch de vertaalslag te maken van ontwerp naar een domain model. Dat is oplossingen zoeken voor problemen die er helemaal niet zijn! OO, Domain model etc. zijn middelen, geen doelen. Patterns zijn oplossingen voor problemen along the way, middelen, niet doelen.

Is het niet andersom? Je maakt eerst een domein model en aan de hand daarvan je ontwerp (daarvoor). Verder ben ik meer voor een hand in hand modelering en ontwerp doordat je niet altijd een domein model van te voren tot in de puntjes kan bepalen (je ontdekt altijd wel weer iets nieuws).

In alle gevallen geven patterns antwoord op de vraag HOE, niet op de vraag WAAROM. 'Waarom' vraag je je af om je ontwerp te maken en te vervolmaken, beslissingen te nemen. HOE is voor de fase(s) erna.

Design patterns geven jouw hogere bouwstenen om in te denken. Dit hoeven niet zozeer patterns te zijn waaruit code gaat voorvloeien, maar ook patterns om bv een domein model op te stellen. Hierbij is het wel de bedoeling om daar ook volgens patterns te werken, omdat zij je helpen om een goed domein model op te zetten. Check anders het domain boek maar eens die ik hierboven heb genoemt.

[EfBe]

In de newsgroup microsoft.public.objectspaces zijn een aantal threads geweest omtrent domain model, OO design, SOA, hoe het aan te pakken e.d. (dus newsserver (bv msnews.microsoft.com, en dan de newsgroup microsoft.public.objectspaces en dan kom je er wel (of google groups ). Fowler deed ook nog mee af en toe. Raakt deze discussie wel degelijk denk ik, wellicht leuk om die threads erbij te nemen.

[ Voor 23% gewijzigd door EfBe op 06-01-2004 22:07 ]

[bille]

read my lips: ervaring

Die hele commonality/veriability analyse gebeurt bij 9 van de 10 software architecten in hun hoofd. Daar is geen methode voor nodig.

Ik gebruik zelf mijn eigen methode voor het common../variabl.. dinges en die luidt: "Reallife Object Hierachy analysis". Vergelijk het met de JAVA Class hierarchie.

Je begint bij je gedefinieerd object, bijv. Fiets. nu ga je stap voor stap omhoog in de hierarchie totdat je een abstract concept tegenkomt: bijv: Voertuig. Vervolgens kijk je welke eigenschappen specifiek gelden voor een abstract concept Voertuig (bijv: Locatie, Snelheid, Aandrijving etc) en whoopsie, daar heb je een baseclass voor alles wat valt onder de het concept Voertuig, dus ook Auto, Vliegtuig etc.

Verder kan ik je toch echt aanraden om het boek van Robert C. Martin "Agile Software Development" te lezen. Het toepassen van Design Principles IS een conceptuele aanpak van het ontwerpen van software. Maar vóór je die principes kent kan je ze niet gebruiken of herkennen wanneer je ze kan toepassen. Het boek gaat ook in op het metrisch berekenen van Package dependencies e.d. Het uitleggen gaat me iets teveel tijd kosten ben ik bang.

[edit] overgens, las net even de FiPo weer ff en las dit:

het identificeren van patterns in de probleemstelling

Nu weet ik niet precies wat voor software jij bouwt, maar als ik bij een klant kom dan weet ik bij voorbaat dat de probleemstelling van de klant (zij/hij wil iets hebben dat het bedrijfsproces verbeterd / versnelt / vereenvoudigd o.i.d.) geen fuck te maken heeft met designpatterns. Wie een andere mening bedeelt is: Enlighten me

je kan hooguit afleiden dat je bijv. een façade pattern (tja ik geil nou eenmaal op pattern ) kan gaan gebruiken om de db (die al dan niet lokaal / remote / flatfile / relationeel etc is) aan te spreken.

[ Voor 29% gewijzigd door bille op 08-01-2004 17:24 ]

[EfBe]

Je begint bij je gedefinieerd object, bijv. Fiets. nu ga je stap voor stap omhoog in de hierarchie totdat je een abstract concept tegenkomt: bijv: Voertuig.

Leuk voorbeeld, maar het is verder niet interessant, want wat interessant is is HOE kom jij aan 'Fiets' en niet aan 'Tafel' ? DAT lijkt me een veel ingewikkelder probleem om te beantwoorden want mijn ervaring is dat bottom up designs alleen kunnen wanneer je compleet je probleem al hebt uitgewerkt, wat in feite neerkomt op nog eens het design doen maar dan van de andere kant af, want hoe kun je beginnen met het uiteindelijke resultaat van een traject wanneer je het begin niet weet...

(ik stel dus: jij doet ook top-down design, alleen zeg je dat je bottom up design gebruikt, want je weet al het eindresultaat (wat dus inhoudt dat je top down bezig bent).

[bille]

Leuk voorbeeld, maar het is verder niet interessant

^.-- vind je?

Zoiets heet domein analyse. Waarom zou ik tafel als object kennen als ik voor een fietsenhandelaar een systeem aan het bouwen ben? Ik vraag aan de klant: wat wil je? Zegt ie: ik wil een systeem waarin ik de voorraad fietsen kan bijhouden. Dan moet je toch wel aardig "dom" zijn om niet door te hebben dat je een object Fiets moet hebben en niet Tafel. Als je hier graag een methode voor wilt hebben dan geef ik je Fully Communication Oriented Information Modelling (FCO-IM) als basis.

Je hebt gelijk in het feit dat iedereen top-down bezig moet zijn. EERST een interview, dan de analyse daarvan met "er is een....." e.d. syntactische analyse dus. Maar dat is zó basis en voornamelijk gebasseerd op boerenverstand. Er is geen methode die je verplicht Fiets te kiezen als object omdat je anders nooit bij een goed beschrijvend domein objectmodel komt. Dat is imho ook niet écht interessant. Waarom zou je zo nodig een abstracte methode gebruiken waarmee je een jaar doet over het opstellen van een fatsoenlijk objectmodel? Heb je geen vertrouwen in je eigen analytisch vermogen?

Waarom denk je dat software architecten vaak jaren ervaring moeten hebben? Naar mijn idee komt dat doordat er geen verplichte regels zijn in het ontwerpen van een systeem. Ik analyseer zoals meerdere op basis van FCO-IM, maar dat geeft geen garanties dat mijn model er hetzelfde uit komt te zien als dat van iemand anders die dezelfde methode hanteert. Dat is voor mij voldoende bewijs dat een methode geen één juiste oplossing geeft. Daarbij laat het "boeren verstand" zich imho moeilijk of niet beschrijven.

De TS geeft ook duidelijk Commonality/Variability als methode om binnen het bestaande objectmodel bepaalde abstracties aan te brengen. Daar liggen mijn interessen in dit topic. Als ik daarmee verkeerd zit

overgens: Stel er zou wél een vaste methode zijn, dan zou mijn loopbaan wel eens een kort leven beschoren zijn. In dat geval zou je namelijk vrij eenvoudig "slimme" software kunnen bouwen die op basis van de antwoorden op een aantal vaste vragen een volledig model kan bouwen. Wellicht dat dit een leuk onderwerp is voor een software project maar dat gaat imho een beetje boven de pet van de gemiddelde tweakert. Krijg je weer het geneuzel met neurale netwerken e.d.

dusss om een lang verhaal kort te maken: afgezien van een aantal methoden die globaal beschrijven hoe je te werk kan gaan bij het onderzoeken van het domein probleem, ben ik nog NOOIT een methode tegen gekomen die mij kon vertellen hoe ik een domeinprobleem moet begrijpen. En daar ligt de hele eierete. Hoe begrijp je uberhaupt iets? Beschrijf het proces van bewustwording effe.. Ik kan je vertellen dat zelfs de allerslimste op deze rots daar geen antwoord op hebben.

[Verwijderd]

Ik heb niet de gehele post gelezen (eerst 10, laatste 5), dus misschien val ik in herhaling .

Ik ben van mening dat je design patterns zowel op laag als hoog nivo ontwerp kunt toepassen. Patterns als MVC of Layers, zijn voorbeelden van patronen die je kunt gebruiken als bezig bent met het FO of je System Design. Patterns als Strategy ga je meestal pas toepassen als je bezig bent met het uitwerken van de ontwerp / object design ("He, we hebben meerdere implementaties van een bepaalde algoritme nodig, zullen we er een strategy ingooien?").
Dit verschild dus per patroon, per ontwerp, per project etc. Maar het kan dus wel.

Verder om nog even in te gaan op de laatste post van bille. Natuurlijk is er geen methode om het domeinprobleem automatisch te herkennen en te kunnen afbakenen. Deze zal er ook niet komen. Dit omdat elk domeinprobleem anders is, elke project anders, de mensen die er aan meewerken anders. Het enige wat hierbij er kan helpen is domeinkennis (bijvoorbeeld uit het verzekeringswezen komen en dan bij een softwareontwikkelaar gaan werken die alleen pakketten schrijft voor het verzekeringswezen).
Dit is ook iets wat de komende jaren aan het veranderen is, en blijft veranderen: de oudere generatie software ontwikkelaars waren mensen uit de natuurkunde, wiskunde, scheikunde richting of uit het bedrijfsleven. Bij de eerste groep (de wetenschappers) is/was er vaak een te abstracte wiskunde benadering en te weinig "domeingevoel" en bij de laatste was juiste het gebrek aan abstractievermogen een probleem (ze kende het domein waarin ze werkte goed, maar hadden niet het wetenschappelijk, wiskunde vermogen om een probleem formeel te beschrijven). (ik weet dat ik hier een hele erge generalisatie toepas )

De jongste lichting van software ontwikkelaars (die ook een echte informaticaopleiding hebben gevolgd op een HBO / WO), behoren ook vaak nog tot de eerste groep (wetenschappelijke benadering van het probleem "informatica"), maar er wordt vanuit de opleidingen wel veel aandacht besteeds aan domeinkennisvergaring en analyse.