0
Nu de architectuur uitgelegd (zien mijn vorige blogitem) is komen we bij de uitvoering. Allereerst wordt er een functioneel ontwerp gemaakt. Hierin wordt de functionaliteit beschreven die nodig is voor het orderverwerkend systeem. Voor het functioneel ontwerp kan het erg handig zijn om use cases (UML) te gebruiken. De use cases beschrijven precies wat de verwachtingen en omstandigheden zijn voor bepaalde functionaliteit. Het gaat te ver om dat nu te doen. Ik wil het voor de duidelijkheid heel simpel houden, het gaat om het principe.Functionaliteit:
- Order toevoegen
- Order bestellen (bij leverancier van goederen)
- Order binnenmelden (als bestelling binnen is)
- Order uitleveren (aan klant)
- Order wijzigen
- Order verwijderen
- Overzicht van orders
Ik ga hierbij vanuit dat de klantgegevens in de order worden opgeslagen en dat de producten op de order handmatig ingevoerd moeten worden. De gegevens die bewaart moeten worden zijn de order en de details op de order.
Na het functioneel ontwerp moet er natuurlijk ook een technisch ontwerp komen. In het technisch ontwerp wordt meer ingezoomd op de techniek. Welke programmeertaal ga je gebruiken, welk opslagmedium, wordt het een windows- of webapplicatie (kan ook een eis in het functioneel ontwerp zijn). Ook wordt in het technisch ontwerp verder gebouwd op het functioneel ontwerp. Met behulp van UML worden nog meer UML modellen gemaakt. Het class diagrams is daarvan wel het meest bekend.
Class Diagram > Domain Model
In ons geval bestaat het domain model uit een order class en een orderdetail class. De order heeft een 1 op N relatie met OrderDetail. Omdat de klant en producten als attributen in respectievelijk order en orderdetail worden opgeslagen hebben wij daarvoor geen objecten nodig.
Class Diagram > Application Model
In het application model wordt het domain model uitgebreid met applicatie logica. Het gaat dan bijvoorbeeld om manager classes. In ons voorbeeld krijgen we er een OrderManager class bij. Deze class is verantwoordelijk voor de acties die plaatsvinden op orders, bijvoorbeeld: order toevoegen, order wijzigen, order verwijderen, enz. Voor de orderdetail class hebben we geen manager class nodig, omdat de orderdetail class valt onder de verantwoordelijkheid van de order class. Een orderdetail class kan namelijk nooit op zichzelf staan. Het staat altijd in de context van een order.
Class Diagram > Implementation Model
In het implementation model wordt het application model uitgebreid met implementatie details. Zo worden de user interfaces opgenomen, eventuele controller classes voor de user interface etc. In ons geval krijgen we een tweetal classes erbij, namelijk een OrderView en een OrderEdit class. De eerste class representeert een scherm waarin een lijst met orders worden getoond.. De OrderEdit class is een scherm waarin een order kan worden toegevoegd of gewijzigd.
Tijdens de bovenstaande drie fasen worden ook nog andere modellen ontwikkeld, zoals activity diagrams, state machines, etc.
In het technisch ontwerp wordt ook beschreven of de data waar mee gewerkt wordt, opgeslagen moet worden of niet. De opslag kan op verschillende manieren plaatsvinden. Het meest gebruikelijk is een database. Ook wordt nogal eens gebruik gemaakt van bestanden, bijvoorbeeld: xml. We zullen er in het voorbeeld-programma rekening mee houden dat de opslagmechanisme gewisseld kan worden. Omdat het hier om een simpel programmaatje gaat, hebben wij alleen maar te maken met 2 tabellen, namelijk Order en OrderDetail. De relatie is net als in het domein model 1 (Order) op N (OrderDetail). Als database wordt SqlServer 2005 gebruikt.
Tabellen
Order
- ID, int (unique key)
- KlantNaam, varchar(50)
- OrderDatum, DateTime
- Status, varchar(20)
OrderDetail
- ID, int (unique key)
- OrderID, int (foreign key)
- Aantal, int
- Eenheid, varchar(5)
- Omschrijving, varchar(100)
- StukPrijs, decimal(10,2)
- Bedrag, decimal(10,2)
De volgende keer gaan we het framework in code opzetten, zodat we daarna daadwerkelijk functionaliteit kunnen bouwen.
:
Naar boven
