1 OGO 2.2 2006 coordinatoren: K.M. van Hee & J.P. Veltkamp Ontwerp van een generiek...
-
Upload
elias-timmermans -
Category
Documents
-
view
218 -
download
0
Transcript of 1 OGO 2.2 2006 coordinatoren: K.M. van Hee & J.P. Veltkamp Ontwerp van een generiek...
1
OGO 2.2 2006
coordinatoren: K.M. van Hee & J.P. Veltkamp
Ontwerp van een generiek
bedrijfsinformatiesysteem
2
Agenda
• Leerdoelen
• Voorkennis
• Projectopdracht
• Projectaanpak
• Tijdlijnen
• Begeleiding
• Beoordeling
3
Leerdoelen (1)• Ontwerpen van een complex software
product met wetenschappelijk verantwoorde methoden en technieken
• I.h.b. een functioneel ontwerp met verificatie en validatie:– verificatie: bewijzen van structuur en
gedragseigenschappen– validatie: door middel van experimenten met
een prototype
4
Leerdoelen (2)• Leren toepassen van methoden en
technieken• Inzicht krijgen in product-software
(een generiek systeem)• Leren prototypen • Leren efficient en effectief samen te
werken • Leren presenteren van een complex
ontwerp
5
Voorkennis
• Databases 1
• Systeemmodelleren 1
6
Technieken: datamodelleren (1) • Gebruik ERD techniek
• Beperk je tot functionele relaties; noteer deze als gerichte arcs. Geef ze een unieke en korte naam
• Dus n-m relaties worden geobjectiveerd tot een entiteit met functionele relaties
• Schrijf constraints op in predicaten logica
7
Project
PK id
naam deleted
PW
PK,FK1 projectPK,FK2 werknemer
actief
a
Werknemer
PK id
naam pw type
b
Activiteit
PK,FK2 werknemerPK,FK1 taak
uitvoerendTaak
PK id
naam omschrijvingFK1 project
Werk
PK id
FK1 taakFK2 werknemer start eind omschrijving
cd
e
f
g
Technieken: datamodelleren (2)
8
• Constraints:
• Een werknemer kan alleen activiteiten hebben in een project waar hij in mag werken:
• Een werknemer kan alleen werk invullen voor een taak van een activiteit die hij mag uitvoeren:
Technieken: datamodelleren (3)
c(a) b(p)a(p) e(f(a)):PWp:Activiteita
d(a)c(w) f(a)g(w) :Activiteita :Werk w
9
Technieken: procesmodelleren (1)
• Maak per use case een (klassiek) Petri net• Beperk je tot workflow netten (Wfnet)• Wfnet heeft 1 begin plaats i (initial) en 1
eind plaats f (final) en elke andere plaats of transitie ligt op een pad van i naar f.
• Wfnetten modelleren procedures (flowcharts met parallelliteit)
• Als we I en f weglaten hebben we een zgn t-workflow
10
Technieken: procesmodelleren (2)
pay_damage
start registerc5
c3
c4
c2
c1
check_damage
send_letterNOK
OK
OK
check_policyNOK
NOK
11
pay_damage
start registerc5
c3
c4
c2
c1
check_damage
send_letterNOK
OK
NOK
OK
check_policy
2 x !
NOK
Technieken: procesmodelleren (3)
12
Technieken: procesmodelleren (4)
pay_damage
start registerc5
c3
c4
c2
c1
check_damage
send_letterNOK
OK
OK
check_policy NOK
NOK
13
Technieken: procesmodelleren (5)
• Soundness: workflows moeten altijd netjes kunnen eindigen
• Formeel: voor elke bereikbare toestand vanuit marking [i] moet de marking [f] bereikbaar zijn.
• Er zijn technieken om soundness te verifieren (Woflan)
• Er zijn constructietechnieken om soundness te garanderen
14
Technieken: procesmodelleren (6)
Er zijn constructietechnieken
om soundness te garanderen:
“soundness by construction”
Hier zijn 5 refinement regels:
Door een model met een
enkele plaats te beginnen en
deze regels toe te passen krijg
je een sound Wfnet
15
Technieken: CRUD matrix
• C=create, R=retrieve, U=update, D=delete
• Voor elke transitie is de worklows en elke entiteit in het data model leggen we vast of de transitie de entiteit gebruikt en hoe (CRUD)
• Zo kunnen we onderzoeken of entiteiten wel netjes beheerd worden en of transtities wel iets “nuttigs” doen
16
Technieken: componentenmodel (1)• Component is een subnet met data stores• Een component heeft 1 t-workflow en 0 of meer
data stores• Data store is een speciale plaats met altijd
bidirectionele verbindingen met transities en altijd 1 token.
• Componenten zijn onderling verbonden door uitwisselen van tokens via interface plaatsen.
• In een componenten model specificeren we datatypes en de transitielogica
17
Technieken: componentenmodel (2)
18
Foute koppelingen (1)
19
Foute koppelingen (2)Kan dit gerepareerd worden?
Is er een betere oplossing?
20
Foute koppeling (3)Betere oplossing!
21
Foute koppelingen (4)
22
Projectopdracht (1)
• Een ontwerp voor een generieke bedrijfsapplicatie
• Een informatiesysteem voor een bedrijfstype dat configureerbare producten maakt op bestelling (Make-To-Order) op basis van een productencatalogus
• Voorbeelden: computers, racefietsen, auto’s, adventure reizen
23
Projectopdracht (2)• Enige fysieke activiteit: ontvangen van
componenten, assembleren van deze componenten tot een product en het klaar zetten voor vervoer naar de klant
• Alle overige activiteiten worden uitbesteed of geautomatiseerd
• De componenten worden gemaakt / geleverd door toeleveranciers
• Transport door verzorgd door transportbedrijven
24
Projectopdracht (3)
• Actors (stakeholders):– klanten– componenten-leveranciers– transporteurs– banken (voor betaling)– system engineers XXX (configuratie)– management XXX (beheer van systeem)
25
Projectopdracht (4)
com ponentenlbouw ers
system XXX
klanten
transporteurs
banken
managementXXXsystem s
engineer
a c
d e
f g
b
Context diagram
26
Projectopdracht (5)
onvolledig voorbeeld van use cases als Message Sequence Chart (MSC)
bank klant system componentleverancier
transport
rfirfp
proposalproposal
paymentadd to account
confirm
delivertransport order
delivery
27
Projectopdracht (6)UR: user requirements Informeel, in tekst of plaatjes:
a. business: wat is het bedrijfsdoel?
b. actors: welke personen en andere systemen hebben interactie met het systeem?
c. use cases: een “stuk functionaliteit” of een service van het systeem. Te beschrijven als scenario’s (actie-rijen) of als MSC
d. entities: object typen die een rol spelen
28
Projectopdracht (7)
BA: business architecture
1. Data model beschrijft the business objects, hun relaties en de constraints
2. Process modellen voor elke use case en voor elke object life cycle (met een workflow net)
3. Verificatie (soundness, CRUD)
29
Projectopdracht (8)SA: software architectuur
1. Componenten model (componenten en onderlinge interactie-relaties)
2. Model per component (transitielogica en data types)
3. Verificatie (soundness, database integrity)
30
Projectopdracht (9)
DD: Detailed design in de vorm van een prototype
Validatie door ontwikkeling van een prototype met behulp van YasperWE, Infopath (MS), met name het user interface
31
Projectopdracht (10)
Parameters voor flexibiliteit:
1. # klanten
2. # toeveranciers
3. # banken
4. # transporteurs
5. # producten
32
Projectopdracht (11)Parameters voor genericiteit:1. Productencatalogus (vorm)2. Business rules:
• betaling door klanten (vooraf, achteraf, mengvorm)
• wel of geen ruggespraak met toeleveranciers voordat een proposal wordt gedaan
• betaling van toeleveranciers• regels voor selectie van toeveranciers
33
Projectopdracht (12)Tips voor prototype:
1. maak stubs voor banken, toeveranciers
2. maak een incrementeel model: test steeds stukken die klaar zijn
3. doe het eerst voor ongekleurde netten en als dat goed gaat, met kleur
Gebruik YasperWE en Infopath
34
Projectaanpak (1)• Werk gefaseerd, registreer tijdsbesteding
• Mijlpalen in contract met opdrachtgever1. UR: user requirements en werkplan
2. BA: business architectuur: datamodel en workflows, CRUD
3. SA: functionele architectuur: componenten en hun interacties; specificaties van plaatstypen en processorlogica; verificatie
4. DD: Prototype YasperWE+ Infopath
5. PD: Presentatie/demonstratie
35
Projectaanpak (2)• Maak werkplan:
– definieer taken door 1 persoon of koppel te doen zonder tussenkomst van anderen
– bepaal de precedentierelaties tussen de taken– schat de tijd die een taak kost– wijs taken toe aan personen– bepaal de doorlooptijd en het kritieke pad
• Onderscheid product- en procesdocumenten:– productdoc: beschrijving van views op het systeem– procesdoc: planningen, logboek, vergaderstukken,
vragen en antwoorden.
36
Projectaanpak (3)
• Houd in elk geval rekening met de volgende taken:
– projectmanagement: vertegenwoordiging naar de opdrachtgevers, bewaking van de planning en de afstemming tussen de taken en hun uitvoerders
– kwaliteitsmanagement: zorg dat de producten gecontroleerd worden voordat ze vrijgegeven worden
– projectadministratie: bijhouden van product-en procesdocumentatie
37
TijdlijnenMijlpalen die fasen afsluiten:
1. 12 dec UR (user requirements)
2. 12 jan BA (software requirements)
3. 13 feb College pres./dem.
4. 16 feb FA (software architecture)
5. 9 mrt DD (prototype)
6. 14 mrt PD (presentatie en dem.)
38
Begeleiding (1)• Elke groep heeft een tutor:
– Jeroen Keiren– Jan Martijn van der Werf
• Wekelijks overleg
• Tutor heeft 3 rollen:– opdrachtgever (als vertegenwoordiger van
coordinatoren)– technisch adviseur– beoordelaar
39
Begeleiding (2)• Tutoren hebben wekelijks overleg met de
coordinatoren• In deze vergaderingen worden de problemen
besproken en oplossingen geboden• In het begin zullen de teams vragen hebben over
de user requirements: de tutoren beslissen, soms na ruggespraak met de coordinatoren
• Reinier Post is op de achtergrond beschikbaar voor YasperWE/Infopath vragen
• StudyWeb: voor uitwisseling van kennis• Vragen zoveel mogelijk per e-mail stellen• College: presenteren/demonstreren
40
Beoordeling• Criteria:
– producten (ca 70%)– procesverslag (ca 10%)– presentatie/demonstratie (ca 20%)
• Differentiatie:– op basis van onderlinge beoordeling
• Tutoren doen voorstel, coordinatoren, (Van Hee, Veltkamp) beslissen