Architecture and Modeling of Management

Information Systems
Dom Samuel Individual Assignment August 2010: Collishop Case

Existence Dependency Graph

• Object Type Cataloog is een overbodig object, het heeft geen relevante
meerwaarde binnen de opgegeven scope van het project.

• Reservation en Reservation_Line lijken op het eerste zicht handig omdat een een
order pas kan bestaan wanneer er een customer aan gelinkt is en op deze manier
toch de shopping cart kan gemodelleerd worden voordat de gebruiker inlogt. Het
is echter irrelevant om dit op te nemen in de enterprise modelling phase en is
eerder een gegeven dat moet worden opgenomen in de beschrijving van de
functionaliteit voor de website van Collivery. De relevante business flow begint
pas wanneer een geregistreerde klant een order doorstuurt.

• Volgens dit EDG is een Delivery_line dependent tov zijn Master Invoice_Line Dit
is niet handig wanneer iemand enkel kleine producten besteld. In dat geval wordt
er immers geen invoice gemaakt en kunnen er ook geen invoice_lines bestaan.
Om een delivery te kunnen maken moet men dus een groot product bestellen.
Zeker omdat de men bij de assignment levering aan huis en bij het lokale
afhaalpunt beiden als een soort delivery worden bekeken en men verder ook
aanhaalt dat dat een invoice enkel wordt gemaakt wanneer met een levering thuis
verwacht.

• Een Invoice_Line kan meerdere Delivery_Lines hebben. Hoewel er voor elk

product in de order een Order_line wordt gemaakt en elke orderlijn maximaal
linkt aan 1 invoicelijn, dus een invoicelijn maar over 1 product gaat, kan een
product toch meerdere leveringslijnen hebben. Dit lijkt een beetje vreemd. Een
invoice op zich kan dit wel.

• Een Delivery of Invoice kunnen bestaan zonder een Order. Een invoice en een
delivery hebben normaal altijd betrekking op een bepaald order volgens hoe de
modellering hier verder is opgebouwd en ook uit de requirements blijkt dit.
(Tenzij men de ‘shipment tours’ waarvan sprake opvat als een soort overall
planning instrument voor leveringen bij meerdere klanten en/of voor meerdere
orders)
 • Het is goed dat voor elk afzonderlijk besteld product een appart object wordt
bijgehouden. Dit zorgt er voor dat producten afzonderlijk kunnen geleverd
worden bij thuislevering. Voor afhaalleveringen is het echter niet noodzakelijk
om apparte lijnen bij te houden, gezien het niet nodig is om de order te wijzigen
na reservatie, er geen invoice voor gemaakt wordt en er geen delivery op product
basis nodig is.

• Wanneer delivery_line ook rechtstreeks dependent zou zijn van order_line, kan er
een delivery gemaak worden ook wanneer er enkel kleine items gekocht worden.
Dan zou ook de FSM van Order niet moeten passeren via status invoice.(zie hier
onder)

Finite State Machines

• In de FSM voor Customer is mooi ingebouwd dat een klant blijft bestaan over
sessies heen en dat hij enkel een order kan plaatsen wanneer deze is ingelogd. Dit
is echter eerder een overbodig gegeven voor de enterprise modellering en de
default FSM is ruim voldoende voor Customer. Inloggen hoort thuis op het niveua
van de functionele modellering. Temeer volgens deze FSM, het systeem
bijvoorbeeld enkel leveringen kan doen wanneer de klant is ingelogd. Deze events
moeten ook aanvaard worden wanneer de customer offline is.

• Gezien Reservatie een overbodig Object Type is, kunnen we ook de FSM
weglaten.

• Bij Order zien we dat er een transitie gaat van de state exists naar
Order_Finalised. Dit is echter niet mogelijk want cr_delivery_line kan niet
worden uitgevoerd in de FSM van Invoice_line,gezien er pas een invoicelijn
wordt aangemaakt wanneer order naar status invoice gaat. Dit was te vewachten
vanuit de EDG. Er kan dus geen Order worden gefinaliseer zonder een
invoicelijn. Wat niet de bedoeling is wanneer enkel kleine producten worden
gekocht.

• We zien ook bij Order dat er nergens een Cr_invoice envent plaats heeft, dit is
logisch vanuit de EDG. Maar zonder cr_invoice event, kan er geen dependent
invoicelijn worden gemaakt. Ook moet met multiple propagation constraints
worden afgedwonden dat de invoicelijn die men creeërt in Order gelinkt wordt
aan de juiste Order. Het is vreemd dat er geen dependency bestaat tussen Order
en Invoice maar dat invoice wel een status is van een order.

• Een order kan niet gecanceld worden. Cancel is pas mogelijk wanneer er reeds
een delivery is aangemaakt. Cancel is van toepassing op een order en niet op een
delivery. Dus dit event is foutief gemodelleerd in de FSM.
 • Event pay_small_item is te vinden in Delivery, terwijl pay_large_item in Invoice
te vinden is. Het gedrag van de verschillende soorten producten in een order
hoort thuis bij orders, orderlijnen en voor grote items ook bij invoices maar niet
bij leveringen. Een levering heeft default FSM. Voor large items kan er enkel een
delivery worden gemaakt wanneer de respectievelijke invoice betaald is.

• Algemeen is het verschil tussen kleine en grote items en de bijhorende flow niet
ideaal gemodelleerd, er wordt niet genoeg onderscheid gemaakt tussen deze twee.
Het zou beter zijn om Order 2 types van orderlijnen te geven als dependent object
types.
Een Small_orderline type dat 1 deliverylijn maakt en dat ten allen tijde gecanceld
kan worden. Plus een Large_Orderline met een object per large item van de
order, waar er 1 invoicelijn wordt gemaakt alsook een deliverylijn per orderlijn.
(Zie annex voor mijn EDG)

Constraints

Gebaseerd op het EDG en de FSM’s uit de opgave :

• Delivery_Date mag gelijk zijn aan Order.Order Date

• Constraint dat na 3 weken het order in lokale shop vervalt :

o Current Date> local_shop_arrival_date + 21 days
• Constraints die kosten voor delivery op basis van de weekdag bepalen zijn
rekenregels, geen constraints.
• Unieke nummers voor Delivery_line, Reservation_Line,Order_line en
Invoice_line zijn geen noodzaak.

• Sequence constraints ivm de verschillen tussen grote en kleine items zijn zoals al
aangehaald niet gevrijwaard daar de FSM’s en het EDG.

o Indien een deliverylijn rechtstreeks dependent zou zijn een orderlijn, dan
zou de sequence constraint voor kleine items zoals bepaald in de FSM van
Order al correct zijn.

Wanneer we kijken naar mijn EDG zijn volgende contraints ook aangewezen :

• Multiple propagation constraint voor invoiceline :

o Self.invoice.order= self.large_orderline.order
• Delivery_Tours kan voor een groot order enkel worden aangemaakt als
invoice_line betaald is, dit kan ook worden afgedwongen met een correcte FSM.
• Een invoice mag enkel worden gecreëerd als er een Large_orderline object
bestaat voor het order, dit is een preconditie voor creatie van een invoice.
o Count( ref_large_orderline)>0
Annex
Mijn EDG :

Customer Category

Product

Order Order-Line

Invoice

Delivery
Invoice_Line Large_Order-Line Small_Order-Line

Delivery_Tours