HOME PROJECTEN VISIE LINKS CONTACT
 
 

Hergebruik is iets dat bij het ontwikkelen van maatwerk oplossingen na verloop van tijd vanzelf ontstaat. Als een organisatie een tijd lang een aantal soortgelijke oplossingen realiseert is de kans groot dat de aanpak en het ontwerp van de oplossing zich na verloop van tijd zullen standaardiseren. Vooral bij gebruik van object georiënteerde methodes en technieken zullen zich herbruikbare stukken code gaan vormen die keer op keer kunnen worden ingezet.

Hergebruik is mogelijk in technische zin, in een te realiseren systeem, maar ook in de organisatie rondom een project. In technische zin zijn onderstaande niveaus van hergebruik mogelijk, oplopend in complexiteit en abstractie:

  • Hergebruik van code; met knip- en plakwerk kunnen statements uit een programma worden overgenomen.
  • Hergebruik van classes; eenmaal gebouwde functionele eenheden kunnen ook in andere systemen voldoen.
  • Hergebruik van concepten; architecturen en design patterns geven een standaard oplossing voor een bekende situatie en kunnen daardoor de ontwerptijd van een nieuwe applicatie verkorten.
  • Hergebruik van frameworks; door een oplossing op basis van een architectuur en/of patterns te abstraheren en vast te leggen in code, is de basis voor soortgelijke oplossingen reeds gelegd.
  • Hergebruik van (sub)systemen; (onderdelen van) applicaties kunnen in sommige gevallen zonder verandering opnieuw worden gebruikt.


Het moge duidelijk zijn dat spontaan hergebruik afneemt naarmate de complexiteit en de abstractie van het te herbruiken onderdeel toeneemt. Een klant die een maatwerk systeem heeft besteld is in het algemeen niet geïnteresseerd in een generieke, herbruikbare oplossing, zodat ontwikkelaars zich in de praktijk eerder zullen richten op het produceren van direct bruikbare code.

Herbruikbare Elementen
Class
Basiseenheid binnen een object georiënteerd programma. Een class groepeert gegevens en bijbehorende functionaliteit. Dit principe van ordening levert in het algemeen beter leesbare structuren op dan een opsplitsing van functies en gegevens.
Class library
Verzameling classes gegroepeerd naar functionaliteit. De classes in een class library hebben vaak functionele overeenkomsten, maar ze hoeven niet noodzakelijkerwijs met elkaar te maken te hebben. Class libraries worden opgeslagen als package.
Design
Nauwkeurige beschrijving van hoe een stuk programma gecodeerd moet worden.
Design Pattern
Een design pattern levert een oplossing voor bekende ontwerpproblemen bij het bouwen van een applicatie. Daarmee manifesteert een design pattern zich als een stukje architectuur of een klein framework. De oplossing wordt meestal kort beschreven en voorzien van enkele (UML-)diagrammen.
Architectuur
Een architectuur beschrijft in hoofdlijnen de structuur die nodig is om een systeem te realiseren. Een architectuur omvat meestal uitgebreide beschrijvingen van de probleemstellingen en de gehanteerde concepten om het op te lossen. De oplossing wordt met diagrammen verduidelijkt. Dit kan o.a. met UML, maar bedacht moet worden dat deze diagrammen niet naar code kunnen worden omgezet, omdat ze daarvoor meestal te algemeen zijn. Een architectuur kan worden aangevuld met kleine testprogramma�s om de werking van sleutelelementen aan te tonen.
Framework
Een framework is een vastgelegde onderlinge samenhang van componenten. Het is bedoeld om de programmalogica van een systeem vast te houden. Een framework kan ook worden gezien als een architectuur die is vastgelegd in een verzameling generieke classes. Door een architectuur via de tussenstap van een framework te implementeren, wordt een oplossing een stuk flexibeler. Een framework bestaat uit een architectuur, een ontwerp en een verzameling classes. Een framework is in het algemeen gebaat bij goede documentatie en voorbeelden. Alle frameworkspecifieke classes worden opgeslagen in dezelfde package.
Service
Proces dat geheel zelfstandig een rol in een systeem vervuld en aanspreekbaar is voor andere processen.
Applicatie
Voert zelfstandig een volledige taak uit voor gebruikers. Het begrip applicatie speelt een rol bij de deployment van een systeem. Een applicatie is een eenheid die kan worden opgestart en vanaf dat moment zijn taak uitvoert.
(Sub-)systeem
Het begrip �systeem� is nogal breed. Volgens Yourdons definitie is alles wat op gestructureerde wijze samenhangt een systeem. Hij onderscheidt natuurlijke en ontworpen systemen. Bij ontworpen systemnen is de structuur, in tegenstelling tot natuurlijke systemen, niet ontstaan, maar bedacht en opgelegd. ��n van dat soort systemen is de structurering van bedrijfsprocessen in een bedrijf. Een automatiseringsproject is erop gericht een deel van de bedrijfsprocessen te automatiseren en is daarmee strict genomen altijd de realisatie van een subsysteem binnen een bedrijf. Het begrip systeem in de automatisering beslaat een afgebakend, geformaliseerd en (deels) geautomatiseerd deel van de bedrijfsprocessen(, inclusief procedures voor onderhoud en beheer). Of men het begrip systeem of subsysteem gebruikt hangt af van de afbakenig of scope waarin een probleem wordt benaderd. (Een verkeerde afbakening van een automatiseringsproject levert dikwijls problemen op. Neemt men de scope te ruim dan kost het te veel tijd om een specifiek probleem voor een klant op te lossen, neemt men de scope te eng dan moet een gerealiseerd systeem bij elke gevraagde wijziging op de schop.)
Component
Een component is een duidelijk afgebakend onderdeel van een systeem, dat een duidelijk afgebakende rol vervult. Een component kan gevormd worden door een aantal van de in dit hoofdstuk genoemde begrippen.
  • Een class (of bean); indien de class voldoet aan bovenstaande definitie van een component.
  • Een stelsel van classes; met behulp van bijvoorbeeld een framework kan een stelsel van classes worden geformeerd dat voldoet aan bovenstaande definitie van een component.
  • Een service; een service is per definitie een component.
  • Een applictie; een applicatie is per definitie een component.
  • Een (sub-)systeem; wordt meestal gerealiseerd als een stelsel van classes of zelfs een applicatie en kan in die zin een component zijn.
Hieronder volgen nog enkele opmerkingen over het begrip �component�.

  • Een component vormt een afgerond inzetbaar geheel.
  • Een component is geen framework, omdat een framework geen duidelijk afgebakende taak vervuld. Een component kan wel een specifieke implementatie van een framework zijn.
  • Een component in een systeem moet vervangbaar (kunnen) zijn door een opvolger.
  • Een component kan bestaan uit onderdelen, zoals classes, frameworks en andere componenten. In die zin kunnen we spreken van de begrippen �enkelvoudig component en �samengesteld component�.
Doelgericht Hergebruik Wil hergebruik optimaal worden toegepast, dan moet het een doelstelling zijn van de organisatie die maatwerk levert. In dit verband kunnen we gaan spreken van doelgericht hergebruik. Doelgericht hergebruik van (deel-)oplossingen wordt op dit moment zowel gehanteerd door bedrijven die zich richten op de consumentenmarkt met concrete producten als door bedrijven die maatwerk leveren. Verkoop van concrete producten kan onder andere de volgende vormen aannemen: Verkoop van software pakketten. Verkoop van componenten als engines, GUI-onderdelen en nuttige classes. Verkoop class libraries. Hergebruik binnen maatwerk oplossingen wordt onder andere toegepast in implementaties van ERP-pakketten e.d. De implementatie wordt in het algemeen gedaan volgens een stricte methodiek die samenhangt met een visie op het domein waarvoor de oplossing wordt gerealiseerd. Voordelen Een doelstelling van een bedrijf moet uiteindelijk gericht zijn op winstgevendheid. Laten we de voordelen van doelgericht hergebruik eens op een rijtje zetten. Er zijn maarliefst drie categoriën van voordelen:
  1. Verbetering van de kwaliteit van de geboden oplossingen.
  2. Verbetering van de kwaliteit van het organisatie.
  3. Directe winstgevendheid.
De voordelen die betreking hebben op de kwaliteit van de oplossing zijn de volgende:
  • De stabiliteit is beter; de stabiliteit van herbruikte onderdelen zal na verloop van tijd zijn toegenomen doordat ze op grond van praktijkresultaten kunnen worden verbeterd.
  • De oplossing is bruikbaarder voor de klant; de focus hoeft in het project immers niet te liggen bij de realisatie van een complexe ruggegraat van het systeem. De focus ligt bij wat specifiek is voor de klant en dat zal voor het merendeel eindgebruikersfunctionaliteit zijn.
Dan zijn er zijn voordelen die betrekking hebben op de kwaliteit van de organisatie:
  • Doelgericht hergebruik gaat saaiheid tegen; als ontwikkelaars telkens tergend langzaam min of meer dezelfde oplossingen moeten bouwen dan gaat dit ze op de lange duur de keel uithangen. Het is beter om overeenkomsten tussen oplossingen snel neer te zetten en tijd te nemen voor functionaliteit die specifiek voor klant is.
  • Doelgericht hergebruik houdt een organistie technisch op niveau doordat het dwingt te abstraheren; herbruikbare onderdelen kunnen in veel gevallen alleen worden ontdekt door op hoog niveau een oplossing te analyseren. Dit is technisch uitdagend werk en stelt ontwikkelaars in staat meer tot de essentie van systeemontwikkeling door te dringen.
  • Doelgericht hergebruik stelt je in staat te expanderen; naarmate het reservoir van herbruikbare onderdelen toeneemt, wordt het mogelijk om met minder mankracht grotere en complexere systemen te bouwen. Dit betekent dat het terrein dat de organisatie met een productportfolio bestrijkt steeds breder kan worden.
  • Doelgericht hergebruik maakt de organisatie minder afhankelijk van de individuele medewerkers; de structuur van oplossingen ligt immers grotendeels vast volgens meervoudig toegepaste principes i.p.v. een door een individu uitgedachte (slecht gedocumenteerde) afwijkende concepten.
En er zijn voordelen die direct winstgevend zijn:
  • Betere concurrentiepositie van het bedrijf; doordat de kosten van een oplossing gedrukt kunnen worden en doordat de kwaliteit van eerder gerealiseerde de oplossing hoger is, springt het bedrijf er bijvoorbeeld bij een offerteaanvraag gunstig uit.
  • Minder nazorg bij klanten nodig; nazorg bij een (ontevreden) klant is vervelend en vaak ook duur. Doordat gerealiseerde oplossingen stabieler zijn is er minder kans op vervelende storingen.
  • Er kan direct geld verdient worden door aan gebruik van herbruikbare onderdelen kosten te verbinden of door herbruikbare onderdelen als product te vermarkten.
Valkuilen Waarom doen we dit dan niet? In de praktijk werkt het niet. Het levert niet genoeg op Code van anderen laat zich vaak lastig integreren omdat stijl en context afwijken. Er kan ook niet vertrouwd worden op een correcte werking van de code als de contxt verschilt. Business logic laat zich slecht vangen in generieke oplossingen, oplossingen worden daardoor veel te abstract, dit kan weer leiden tot hardnekkige bugs. Men kan het een klant niet aandoen om ontwikkelaars bij een concrete case rekening te laten houden met eisen voor een generieke oplossing. Het achteraf destilleren van generieke oplossingen uit specifieke code is een klus die niet wil vlotten. Geen deadline, analysis paralysis, saai. Overhead van onderhouden bibliotheek. Documentatie, compatibiliteit. Zoeken, begrijpen, uitproberen en configureren van andere code kost ook tijd. Haalt de pret uit het vak en daarmee zijdelings productiviteit. Zelf dingen maken is leuk. Door zelf dingen te maken vergroot men zijn inzicht. Juniors moeten soms zelf dingen maken. Is goed voor de organisatie. Discipline nodig <-> creatieve mensen -> werkt niet OO-pizzapunt Inzet aanpak De uitdaging zit �m in ten eerste het financieren van de initi�le overhead, omdat je aanvankelijk met lege handen staat. Na verloop van tijd wordt hergebruik winstgevend, maar desondanks moet bij elk project weer de discipline worden opgebracht om problemen generiek op te lossen. Ten tweede moet alle informatie over de beschikbare herbruikbare code gemakkelijk toegankelijk zijn. Dit vereist een slim systeem en flink wat discipline van zowel ontwikkelaars als verkopers, om alle informatie up-to-date te houden. Ten derde moeten de componenten zelf beschikbaar zijn via een versiecontrole systeem. Versiecontrole gaat hierbij verder dan wat de meeste standaard tools te bieden hebben, omdat specificatiewijzigingen en compatibiliteit nauwkeurig bijgehouden moeten worden. Configuratie Bij hergebruik speelt de configureerbaarheid van de te herbruiken elementen een grote rol. Bij het geschikt maken voor hergebruik wordt code namelijk zodanig gegeneraliseerd, dat deze voor meerdere soortgelijke oplossingen kan worden gebruikt. Bij het bouwen van een oplossing echter moeten klantspeciefieke eigenschappen kunnen worden toegevoegd. Configuratie kan in drie verschillende stadia van een systeem worden gedaan: Bij het maken of aanpassen van code (compile-time) Bij het opstarten van een applicatie (startup-time) Tijdens het draaien van een applicatie (run-time) Het grote verschil tussen classes en frameworks aan de ene kant en componenten aan de ander kant is dat classes en frameworks worden aangepast door te coderen en dat componenten hun specifieke werking startup-time of run-time verkrijgen. Logging & Monitoring Aangezien een component min of meer zelfstandig werkt en zeer stabiel moet zijn, moet het er zelf voor zorgen dat de interne werking gevolgd kan worden. Dit betekend in alle gevallen dat geconstateerde fouten moeten worden gemeld. In sommige gevallen moet een beheerder een statusrapport bij een component kunnen opvragen. Commercie Functionaliteit is het begrip waarmee de wensen van een klant uitgedrukt kunnen worden. Het bepaalt de architectuur en daarmee de in te zetten standaard herbruikbare onderdelen en de hoeveelheid maatwerk. Verhandelbare herbruikbare elementen zijn:
  • Class libraries.
  • Componenten.
  • Frameworks.
Indien een totaaloplossing wordt geleverd, wordt maatwerk in rekening gebracht door het aantal benodigde manuren te bepalen. De hoeveelheid maatwerk wordt bepaald door:
  • Overhead in de vorm van consultancy, training en projectmanagement.
  • De geschatte configuratie-inspanning, waarbij de aard van de configuratie meespeelt.
  • Ontwikkeling van nieuwe componenten (zoals legacy connectoren).
  • Inkoop- en installatiewerkzaamheden.
Het maakt een groot verschil of men een totaaloplossing bouwt of als technology provider optreedt. In het eerste geval moet de beschrijving van de componenten gericht zijn op eindgebruikersfunctionaliteit. In het tweede geval moet een technische specificatie van (de externe eigenschappen van) de componenten worden geleverd.

Technische (infrastructurele) code is herbruikbaar Concepten zijn herbruikbaar (treedt al op bij spontaan hergebruik) Context moet er zijn -> logging, configuratie Configuratie is alles. 1 standaard mechanisme voor configuratie is vereist. Ontsluiting via interface -> framework Framework moet zeer laagdrempelig zijn! Ontwikkelaars zijn wel degelijk geinteresseerd in efficientie en productiviteit.
- copyright � 2003 ijsberg automatisering -
website by addink.net