Naar een valide objectmodel Frank Peeters september 2011

Naar  een  valide  objectmodel   Frank  Peeters  –  september  2011    

  Aanleiding   Er  is  wetenschappelijk  aangetoond  dat  gedurende  het  ontwikkelen  van  software   het  in  een  vroeg  stadium  opsporen  van  fouten  de  kwaliteit  van  de  software  zeer   ten  goede  komt  en  sterk  kostenbesparend  werkt.  Onderzoek  naar  methoden,   technieken  en  tools  op  dit  terrein  heeft  al  decennialang  de  aandacht.  Het   langdurig  onderzoeksprogramma  van  EQuA1  (Early  Quality  Assurance  in   Software  Production)  sluit  hierop  aan  en  richt  zich  op  uitwisseling  van   wetenschappelijk  toegepaste  kennis  op  het  vlak  van  vroegtijdige  foutdetectie  en   –herstel.  Eén  van  de  vijf  EQuA-­‐deelprojecten  begeeft  zich  op  het  terrein  van   validatie  van  requirements  en  modellen.  Vrij  spoedig  na  de  start  van  dit   deelproject  werd  duidelijk  dat  één  van  de  meest  centrale  modellen,  die  van  het   objectmodel  is.  Hierbij  rijzen  allereerst  twee  vragen:     • Wat  is  een  objectmodel?   • Hoe  kunt  u  ervoor  zorgen  dat  ook  een  objectmodel  valide  blijft?     Objectmodel   Een  model  is  een  vereenvoudigde  voorstelling,  beschrijving  of  nabootsing  van   een  deel  van  de  werkelijkheid.  Bij  een  objectmodel  richten  we  ons  op  het   vastleggen  van  de  objecten  uit  de  relevante  werkelijkheid  voor  de  betreffende   software.  Het  relevante  deel  van  de  werkelijkheid  noemen  we  het  domein.   Gedurende  het  ontwerp  van  een  objectmodel  zullen  een  aantal  vragen  moeten   worden  beantwoord.  Zoals:     • welke  objecten  zijn  er  binnen  het  domein  relevant,     • wat  zijn  hun  eigenschappen,     • welke  relaties  met  andere  objecten  onderhouden  ze,     • aan  welke  constraints  moeten  ze  voldoen,     • welke  opdrachten  kunt  u  ze  geven  en     • hoe  wordt  een  object  tot  ‘leven’  gebracht?         Het  objectmodel,  dat  wij  voor  ogen  hebben,  bevat  daarom  in  ieder  geval  de   volgende  informatie:   • een  verzameling  met  objecttypen,   • alle  onderlinge  relaties  tussen  objecttypen  of  relaties  met  primitieve   gegevens  (getallen,  tekst,  karakters  en  boolean  waarden),   • de  beperkingen  die  er  voor  deze  relaties  gelden,   • overerfrelaties  tussen  objecttypen  en   • constructoren  en  operaties  per  objecttype.   De  in  het  objectmodel  opgenomen  objecttypen  refereren  allemaal  op  de  een  of   andere  manier  naar  objecten  uit  de  relevante  werkelijkheid.  Het  zijn  concepten                                                                                                                   1  Early  Quality  Assurance  in  Software  production  –  een  programmavoorstel  in  het  kader  van     RAAK-­‐PRO  –  Hogeschool  van  Amsterdam,  december  2009.  

 

pag  1  

uit  deze  werkelijkheid.  Het  objectmodel  mag  daarom  ook  een  conceptueel   objectmodel  mogen  worden  genoemd.     Een  objectmodel  kunt  u  in  de  vorm  van  een  UML  klassendiagram  visualiseren.   Deze  visualisatie  wordt  in  sommige  kringen  met  een  conceptueel  klassendiagram   aangeduid.  Men  bestempelt  zo’n  conceptueel  klassendiagram  soms  kortweg  met   het  conceptuele  ontwerp  of  het  domeinmodel.       Het  conceptuele  ontwerp,   het  domeinmodel  en  het  (conceptuele)  objectmodel   zijn  binnen  deze  tekst  elkaars  synoniemen.  In  het  vervolg  zullen  we  ons  vooral   van  de  laatste  term  bedienen.     Validiteit   Bij  validatie  van  een  model  denkt  men  aan  de  vraag:  of  het  model  voldoet  aan   ‘wat  de  klant  wil’.  Een  klant  kan  evenwel  doorgaans  niet  beoordelen  of  een   objectmodel  valide  is.  Daarvoor  is  dat  model  te  technisch.  Een  klant  is  immers   normaliter  geen  software  engineer.  Bij  user  requirements  ligt  dat  anders.  Die   zijn,  zeker  in  het  allereerste  stadium  van  requirements  engineering,  in   natuurlijke  taal  omschreven.  Dat  biedt  de  mogelijkheid  om  requirements  aan  de   diverse  soorten  van  stakeholders  voor  te  leggen  en  te  laten  valideren.  Na  een   grondige  validatieslag  heeft  men  echter  nog  geen  absolute  zekerheid  of  de   requirements  compleet,  eenduidig  en  haalbaar  zijn.  Daarom  noemen  we  de   verzamelde  requirements  tesamen  een  requirementsmodel.  Het  is  een  model   van  de  werkelijke  behoefte.  In  deze  tijd  van  iteratieve  en  agile  software-­‐ ontwikkeling  hoeft  deze  onvolkomenheid  geen  al  te  groot  probleem  te  zijn.  De   kortcyclische  werkwijze  zorgt  voor  een  snelle  feedback  en  biedt  dus  de  kans  om   de  requirements  bijtijds  bij  te  stellen,  waardoor  deze  waarschijnlijk  dichter  in  de   buurt  van  werkelijke  behoefte  komen  te  liggen,  of  anders  gezegd:  meer  valide   worden.     Ook  al  weet  men  niet  met  100%  zekerheid  dat  het  requirementsmodel   (voldoende)  valide  is,  toch  willen  we  de  validiteit  van  het  objectmodel   optimaliseren.  Deze  ambitie  wordt  gerealiseerd  doordat  elk  afzonderlijk   onderdeel  uit  het  objectmodel  direct  of  indirect  in  een  of  meer  onderdelen  uit   het  requirementsmodel  is  verankerd.  Veranderingen  (lees:  verbeteringen)  in  het   requirementsmodel  moeten  dan  wel  tot  veranderingen  in  het  objectmodel   leiden.  Hoe  dat  precies  in  zijn  werk  gaat,  wordt  verderop  duidelijk  gemaakt.     De  validiteit  van  het  objectmodel  wordt  dan  bepaald  door  de  validiteit  van  het   requirementsmodel.  Als  de  validiteit  van  het  requirementsmodel  goed  is,  zal  die   van  het  objectmodel  ook  goed  zijn.  De  validiteit  van  een  objectmodel  is  dan  een   maat  voor  de  afstemming  op  de  requirements.  Hoe  beter  het  objectmodel  de   kansen  biedt  om  de  requirements  te  realiseren  hoe  hoger  de  validiteit.       Hiermee  hebben  overigens  nog  niet  alle  kwaliteitsaspecten  van  een  objectmodel   voldoende  aandacht  gekregen.  U  kunt  hierbij  denken  aan  de  beloften  die  er  in  de   jaren  ’80  bij  de  opkomst  van  het  objectgeoriënteerde  paradigma  zijn  gedaan   zoals:  a)  klassen  bieden  de  mogelijkheid  tot  herbruikbaarheid,  b)   objectgeoriënteerde  software  is  gemakkelijker  uit  te  breiden  en  c)  de   objectgeoriënteerde  software  is  eenvoudiger  te  onderhouden.  Deze  beloften  

 

pag  2  

worden  in  de  praktijk  vaak  niet  waargemaakt  omdat  er  in  de  ontwerpfase  wordt   gezondigd  tegen  algemeen  geaccepteerde  ontwerppatronen2.     Requirements   De  koninklijke  weg  voor  een  kwalitatief  hoogwaardige  software-­‐ontwikkeling   begint  eigenlijk  bij  een  businessstudie,  waarin  onder  meer  tekortkomingen,   kansen,  uitdagingen,  risico’s  en  doelen  in  kaart  zijn  gebracht.  Uiteindelijk  zal  dit   tot  een  inventarisatie  van  bedrijfsrequirements  leiden.  Deze  inventarisatie  is   vanuit  het  bedrijfsperspectief  beschreven.  Hierna  volgt  het  opstellen  van  een   user  requirements  specification  (URS).  De  bedrijfsrequirements  worden  dan   geconcretiseerd  richting  toekomstig  gebruik  van  de  te  (her)ontwikkelen   software.  In  een  URS  komt  men  normaliter  de  volgende  bestanddelen  tegen:     1. contextbeschrijving  (domein,  belanghebbenden,  infrastructuur  etc.);   2. terminologie;   3. opsomming  van  handelingen  die  met  behulp  van  de  nieuwe  software   uitvoerbaar  moeten  gaan  worden;     4. opsomming  van  relevante  informatie,  die  ten  grondslag  ligt  aan  de  uit  te   voeren  handelingen  (zie  3);     5. opsomming  van  constraints  en  andere  bedrijfsregels  waaraan  de  nieuwe   software  gebonden  is;   6. opsomming  van  kwaliteitsattributen  met  betrekking  tot  bovenstaande   geboden  functionaliteit  (hoe  snel,  hoe  veilig,  hoe  betrouwbaar,  hoe   gebruiksvriendelijk  e.d.).       De  onder  punt  3  vermelde  handelingen  zijn  pas  in  redelijk  globale  termen   beschreven.  Deze  handelingen  zullen  met  meer  detail  moeten  worden   uitgewerkt.  Use  cases  zijn  tegenwoordig  algemeen  geaccepteerd  als  het  gaat  om   het,  met  voldoende  detail  en  in  natuurlijke  taal,  vastleggen  van  de  interactie   tussen    de  toekomstige  gebruikers  met  het  te  bouwen  systeem.    Zo  ontstaat  er   een  bundel  use  cases  die  in  een  valideerbaar  use-­‐casemodel  wordt   ondergebracht.       Het  URS  (=Requirementsmodel)  in  combinatie  met  het  use-­‐casemodel  vormt  een   prima  basis  om  de  brug  naar  een  gedegen  objectmodel  te  slaan.       De  status  quo  van  het  onderzoek   In  het  eerste  acht  maanden  van  het  onderhavige  EquA-­‐deelonderzoek  zijn  er   doelen,  ambities  en  ook  toekomstmuziek  geformuleerd:     1. Constructie  van  een  objectmodel  vanuit  requirements  (automatisering   van  de  constructie  waar  mogelijk);   2. Het  verfijnen  van  het  objectmodel  door  middel  van  het  aanbrengen  van   constraints,  zodat  visualisatie  in  de  vorm  van  een  klassendiagram   mogelijk  wordt;   3. Visualisatie  van  het  objectmodel  in  de  vorm  van  een  objectroldiagram   (ORD)  en  een  klassendiagram;                                                                                                                  

2  Zie:  Robert  C.  Martin.  Agile  Software  Development,  Principles,  Patterns,  and  Practices.  2002  

 

pag  3  

4. Modelelementen  zijn  zodanig  gedocumenteerd  dat  alle  bronnen   traceerbaar  zijn;     5. Transformatie  van  een  objectmodel  gestuurd  door  meta-­‐regels  en   expertise  op  het  vlak  van  software-­‐design;   6. Synchronisatie  van  direct  afhankelijke  modelelementen  zodra  een  bron   wijzigt;   7. Verfijning  van  het  objectmodel  op  basis  van  scenario-­‐analyse;   8. Automatische  generatie  van  testscripts  op  basis  van  scenario’s  en   verzamelde  representatieve  en  kritieke  feiten;   9. Genereren  van  programmacode  behorende  bij  alle  klassen  uit  het   conceptuele  klassendiagram.       In  deze  eerste  fase  van  het  onderzoek  zijn  de  eerste  en  tweede  stap  inmiddels  tot   in  een  redelijk  volwassen  stadium  gevorderd.  De  komende  maanden  wordt  er  de   nodige  progressie  op  het  terrein  van  visualiseren  van  het  objectmodel   verwacht3.     De  vierde,  vijfde  en  zesde  stap  rondom  traceability  worden  langzamerhand   voorbereid  en  in  gang  gezet.  De  zevende  stap  wordt  in  het  kader  van  het   afronden  van  een  masterstudie  aan  de  TU/e  onderzocht.  De  achtste  en  negende     stap  staat  vooralsnog  alleen  op  de  rol,  zonder  dat  er  op  dit  moment  een  duidelijk   tijdspad  en,  laat  staan,  milestones  zijn  voorzien.      

                                                                                                               

3  De  GUI  wordt  dit  najaar,  m.b.v.  een  usability-­‐analyse  door  een  team  van  Fontys-­‐studenten  nader  onder  de  

loep  genomen.  

 

pag  4  

        De  grote  lijn   In  fig  1  staat  schematisch  de  gepropageerde  werkwijze  beschreven.  Niet  alles  uit   dit  schema  zal  misschien  meteen  duidelijk  zijn.  De  getoonde  tussenresultaten  (in   de  vorm  van  rechthoeken)  en  de  stappen  er  naartoe  (in  de  vorm  van  pijlen)   worden  aan  de  hand  van  een  voorbeeldcasus  besproken.           changing     requirements   adjustment     constraints  etc     Object  role        fact  decomposition   diagram     Req.   Object    show     model   model    glossary   Class     diagram        adjustment  

 refinement  

Use  Case   model    

 behavioral   refinement  

 scenario’s  

adjustment   behavior  

               

 facts  

Testmodel  

external  input   manually   comp.  controlled   controlews   generated  

restricted  to  the  domainobjects   Figuur  1:  de  grote  lijn  

 

   

De  casus  speelt  zich  bij  de  Nederlandse  voetbalbond,  de  K.N.V.B.,  af.  Deze  bond   moet  allerlei  competities  organiseren.  Te  denken  valt  aan  de  eredivisie,  de  eerste   divisie,  regionale  competities  en  de  beker.  De  competities  met  wedstrijden   ondergaan  wijzigingen  die  door  diverse  betrokkenen  worden  gevolgd  of  gevoed.     De  grote  lijn  schrijft  voor  dat  je  met  het  verzamelen  van  alle  requirements  begint   (zie  linksboven  in  fig  1).  Voor  het  K.N.V.B.-­‐domein  wordt  eerst  een  klein  deel  van   het  URS  getoond.  Daarna  wordt  gedemonstreerd  hoe  uit  deze  requirements  een   objectmodel  wordt  geconstrueerd.  De  andere  onderdelen  uit  fig  1  krijgen   verderop  hun  aandacht.    

 

 

pag  5  

Het  voorbeelddomein   In  tabel  1  kunt  u  de  vier  soorten  van  requirements  terugvinden.  Te  beginnen  met   een  opsomming  van  de  beoogde  functies    voor  het  K.N.V.B.-­‐systeem,  weliswaar   in  globale  termen.       User  Requirements  Specification   Terminologie     …   Context     …  Beschrijving  KNVB  …   Stakeholders   Competitieleiders,  teamsecretarissen,  journalisten,  voetballiefhebbers   A.  Functies     Funct1:  competieleiders  kunnen  een  competitierooster  inrichten     Funct2:  wedstrijden  moeten  kunnen  worden  verplaatst   Funct3:  voetballiefhebbers  kunnen  de    eigenschappen  van  een  wedstrijd  via  het  internet   inzien.   …   B.  Feiten   Fact1:  VVV  –  Ajax  uit  ronde  6  van  de  eredivisie  van  seizoen  2011  is  in  2-­‐2  geëindigd.   Fact2:  Bij  de  wedstrijd  van  Heracles  tegen  Feyenoord  uit  ronde  6  van  de  eredivisie  van   seizoen  2011  waren  13450  toeschouwers  aanwezig.   Fact3:  Heracles  –  Feyenoord  uit  ronde  4  van  de  eredivisie  van  seizoen  2011  is  op  7   september  om  14.30  uur  gepland.   Fact4:  Ronde  1  van  de  KNVB-­‐beker  van  seizoen  2010  staat  standaard  voor  1  september   gepland.   Fact5:  In  de  14e  minuut  van  de  wedstrijd  PSV-­‐Roda  JC  uit  ronde  7  van  de  erdivisie  van   seizoen  2011  is  er  voor  de  thuisspelende  ploeg  een  doelpunt  gevallen.   Fact6:  Het  doelpunt  in  de  14e  minuut  van  de  wedstrijd  PSV-­‐Roda  JC  uit  ronde  7  van  de   eredivisie  van  seizoen  2011  is  door  Olav  Toivonen  gemaakt.     …   C.  Beperkingen   Constr1  :  tussen  twee  opeenvolgende  wedstrijden  van  een  team  zitten  ten  minste  twee   wedstrijdloze  dagen.   Constr2  :  de  (tussen)uitslag  van  een  wedstrijd  kan  pas  bekend  zijn  als  de  wedstrijd  is   begonnen.   …   D.  Kwaliteitsattributen   QA1  :    [performance]  gemelde  wijzigingen  in  de  uitslagen  van  de  wedstrijden  worden   binnen  één  minuut  verwerkt.   QA2  :    [schaalbaarheid]  wedstrijdhistorie  over  alle  knvb-­‐competities  ligt  over  30  seizoenen   terug  publiekelijk  ter  inzage.   …   Tabel  1:  een  URS  voor  het  voorbeelddomein

 

Na  de  opsomming  van  de  functies  volgt  de  relevante  informatie.  Er  wordt  aldaar   gepoogd  om  uit  het  gestelde  domein  voor  elk  soort  van  informatie  een  of  meer   representatieve  feiten  op  te  sommen.  Er  is  onder  meer  voor  dit  concrete  niveau   gekozen  omdat  er  dan  nóg  gemakkelijker  kan  worden  gecontroleerd  of  de   vereiste  informatie  correct  is  geformuleerd.  Elk  fact-­‐requirement  staat  op  zich;   het  is  uitdrukkelijk  de  bedoeling  dat  zo’n  requirement  onafhankelijk  van  de   andere  fact-­‐requirements  kan  worden  geïnterpreteerd.  Ook  een  punt  van   aandacht  is  dat  aanduidingen  van  objecten  uit  het  domein  eenduidig  zijn4.  Deze                                                                                                                  

4  Zie  ook:  Elton  Manoku,  Jan  Pieter  Zwart,  Guido  Bakema.  A  fact  approach  to  automatic  application  

development.  2006  

 

pag  6  

strikte  eisen  komen  zo  meteen  van  pas  zodra  het  objectmodel  wordt   geconstrueerd.  Deze  constructie  start  dan  met  een  analyse  van  de  voornoemde   feiten.   De  constraint-­‐requirements  vormen  de  derde  categorie  aan  requirements.  Dat   kunnen  statische  of  dynamische  constraints.    Constr1  is  een  voorbeeld  van  een   statische  constraint.  Een  statische  constraint  beperkt  de  toestandsruimte  van   alle  objecten  op  enig  moment.  De  dynamische  constraints  beperken  de   toestandsovergang.  Constr2  is  daar  een  voorbeeld  van.       De  kwaliteitsattributen  sluiten  de  rij  der  requirements  af.  Zij  stellen   kwaliteitseisen  aan  de  andere  requirements.  Kwesties  als  veiligheid,   gebruiksgemak,  betrouwbaarheid  en  dergelijke  worden  aldaar  vastgelegd.  Deze   attributen  worden  vaak  ook  als  de  niet-­‐functionele  requirements  aangeduid.     Decompositie  van  een  feit   Met  de  hulp  van  factrequirements  worden  de  bestanddelen  in  het  objectmodel   aangewezen.  Elk  feit  representeert  een  verwoording  van  een  realistische  relatie   uit  het  gestelde  domein.  We  nemen  de  analyse  van  fact1  als  startpunt:     “VVV  –  Ajax  uit    ronde  6  van  de  eredivisie  van  seizoen  2011  is  in  2-­‐2   geëindigd.”     Dit  feit  beschrijft  een  uitslag  van  een  wedstrijd,  ofwel  het  beschrijft  de  relatie   tussen  een  wedstrijd  en  een  uitslag.  Voor  de  identificatie  van  een  wedstrijd  zijn   er  drie  gegevens  nodig:  het  thuisspelende  team,  het  uitspelende  team  en  de   ronde  waar  deze  wedstrijd  bij  hoort.  Er  vindt  een  stapsgewijze  decompositie  in   de  structuur  van  dit  feit  plaats.  In  fig  2  krijgt  u  enigszins  een  beeld  hoe  deze   decompositie  met  behulp  van  de  EQuA-­‐objectmodeler  in  zijn  werk  gaat.    De   variabele  onderdelen  van  het  feit  worden  getypeerd  (bijv.  Team)  en  krijgen  zo   mogelijk  een  rolnaam  (bijv.  uitteam)  toegewezen.  De  constante  onderdelen   reigen  de  variabele  onderdelen  als  het  ware  aan  elkaar.  Na  afloop  van  deze   stapsgewijze  verfijning  kan  het  oorspronkelijke  feit  weer  worden   teruggenereerd5.      

                                                                                                               

5  De  werkwijze  bij  feitdecompositie  is  in  detail  beschreven  in:  Frank  Peeters,  Frens  Vonken.  

Objectgeoriënteerde  domeinanalyse.  Academic  Service,  2001.  

 

pag  7  

 

Figuur  2:  decompositie  van  een  feit  

Nadat  de  decompositie  van  fact1  is  voltooid,  zijn  er  inmiddels  zeven  nieuwe   typen  aan  het  objectmodel  toegevoegd.  Deze  ziet  u  bovenaan  in  weergegeven.     Merk  op  dat  al  deze  typen  met  elkaar  zijn  gerelateerd;  er  bestaan  geen  solitaire   typen.  De  werkwijze  van  het  analyseren  van  feitelijke  relaties  komt  de   samenhang  in  het  resulterende  objectmodel  vanaf  het  het  allereerste  begin  tot   aan  het  einde  van  de  constructie  ten  goede.          

Figuur  3:  de  inmiddels  gedecteerde  typen  

 

  Een  object  van  een  objecttype  kan  een  rol  bij  een  ander  feit  of  object  spelen.  Een   feit,  dat  geen  object  is,  beschikt  niet  over  die  capaciteit.  Daarom  noemen  we  

 

pag  8  

UitslagWedstrijd  een  (puur)  feittype.  De  andere  zes  typen  uit  figuur  3  zijn   allemaal  objecttypen6.     In  fig  4  zijn  de  drie  rollen  met  de  bijbehorende  restricties  voor  het  geselecteerd   objecttype  Wedstrijd  getoond.  Restricties  kunnen  hier,  weliswaar  op  een   nogal  een  primitieve  wijze,  worden  aangepast7.    Voor  de  vermelde  feit-­‐  en   objecttypen  zijn  de  volgende  restricties  toegevoegd:     • Bij  Wedstrijd  zijn  er  twee  uniciteitsconstraints  over  de  eerste  en  derde   rol  (u7)  en  over  de  tweede  en  derde  rol  (u8)  aangebracht,  immers  per   ronde  zal  een  team  slechts  één  wedstrijd  spelen;   • bij  UitslagWedstrijd  is  aan  de  eerste  rol  een  uniciteitsconstraint   toegevoegd  (een  wedstrijd  kent  maar  één  uitslag)  en  is  de  navigatie   vanuit  de  tweede  rol  vanuit  Uitslag  verbroken  (een  uitslag-­‐object  hoeft   niet  te  weten  bij  welke  wedstrijduitslag  hij  betrokken  is);   • bij  Wedstrijd  is  de  Ronde-­‐rol  als  parent-­‐rol  aangemerkt;  bij  Ronde   worden  de  Wedstrijd-­‐objecten  beheerd.     Dit  zijn  de  enige  aanpassingen  die  er  voor  de  zeven  typen  hebben   plaatsgevonden.  Nu  kan  er  standaardgedrag  voor  elk  objecttype  (=class)  worden   gegenereerd.  Bij  standaardgedrag  denken  we  aan  een  constructor,  getters  en   setters,  zoekmethoden,  methoden  om  objectlinks  toe  te  voegen  en  te   verwijderen  en  meer  van  zulks.  Als  voorbeeld  is  er  aan  de  rechterzijde  in  de   figuren  4  en  5  het  automatisch  gegenereerde  standaardgedrag  van   achtereenvolgens  de  klassen  Wedstrijd  en  Ronde  af  te  lezen.  De  zes  operaties   (1  constructor,  4  properties  met  getters  en/of  setters  en  1  methode)  van   Wedstrijd    zullen  waarschijnlijk  nauwelijks  een  verrassing  zijn.  Voor  Ronde   zijn  de  tien  gegenereerde  operaties  toch  al  een  stuk  minder  triviaal  (zie   rechterzijde  in  fig  5).    Dankzij  deze  automatiseringsslag  wordt  er  de  nodige   ontwerptijd  bespaard  en  wellicht  belangrijker:  de  kwaliteit  van  het  objectmodel     verhoogd.  

                                                                                                               

6  Harm  van  der  Lek,  Guido  Bakema,  Jan  Piet  Zwart.  De  Unificatie  van  Objecttypen  en  Feittypen.  1992   7  Ter  zijde:  de  GUI  wordt  dit  najaar,  m.b.v.  een  usability-­‐analyse  door  een  team  van  Fontys-­‐studenten  nader  

onder  de  loep  genomen  en,  naar  het  zich  laat  aanzien,  ingrijpend  verbeterd.  

 

pag  9  

 

Figuur  4:  automatisch  gegenereerd  standaardgedrag  voor  het  objecttype  Wedstrijd  

 

Figuur  5:  automatisch  gegenereerd  standaardgedrag  voor  het  objecttype  Ronde  

 

 

 

 

pag  10  

Het  objectmodel  visualiseren   Het  objectmodel  bevat  een  collectie  object-­‐  en  feittypen  met  bijbehorende   constraints.  Ook  zijn  in  het  objectmodel  alle  ingevoerde  feiten  en  objecten  terug   te  vinden.    Zojuist  is  gedemonsteerd  hoe  u  standaardgedrag  van  een  klasse  kunt   genereren.  Het  standaardgedrag  is  voor  de  volle  100%  berekenbaar  uit  het   objectmodel8.     Ter  wille  van  het  overzicht  is  het  gewenst  om  delen  van  een  objectmodel  in  de   vorm  van  een  diagram  te  visualiseren.  Er  zijn  twee  manieren  om  een   objectmodel  te  visualiseren:     Class  Diagram  (CD)   Object  Role  Diagram  (ORD)     Het  klassendiagram  voldoet  aan  de  UML-­‐specificaties.  Aspecten  als  attributen,   associaties,  multipliciteit,  rolnamen,  overerving  en  operaties  kunnen  zichtbaar   worden  gemaakt.    Bij  het  aanmaken  van  een  klassendiagram  moet  de   toolgebruiker  aangeven  welke  objecttypen  er  in  het  nieuwe  klassendiagram   moeten  worden  opgenomen.    Daarna  kan  er  worden  aangegeven  waar  elke   klasse  wordt  gepositioneerd.  De  zojuist  opgesomde  aspecten  worden  vervolgens   in  het  klassendiagram  getoond.  Dat  gebeurt  allemaal  zoals  men  dat  in  een  UML-­‐ tool  is  gewend,  zie  figuur  6  9.     In  dit  figuur  zijn  de  operaties  even  buiten  beeld  gebleven.  Uiteraard  kan  men  ook   het  gegenereerde  gedrag  in  het  klassendiagram  zichtbaar  maken.  Dit  gedrag   komt  exact  overeen  met  datgene  er  in  de  voorgaande  figuren  is  getoond.  Dus  wat   dat  betreft,  is  er  niets  nieuws  onder  de  zon.     Traceability   Met  klem  wijzen  we  op  het  feit  dat  niet  het  klassendiagram  het  ontwerp  bevat,   maar  dat  het  klassendiagram  volledig  aan  het  onderliggende  objectmodel  is   ontleend.  Het  klassendiagram  is  niet  meer  dan  een  grafische  view  gebaseerd  op   informatie  ontleend  aan  het  objectmodel.    Het  beschreven  objectmodel  met  zes   objecttypen  is  op  zijn  beurt  uit  één  enkel  feit  geconstrueerd.  We  brengen  dit  feit   nogmaals  onder  uw  aandacht:     “VVV  –  Ajax  uit  ronde  6  van  de  eredivisie  van  seizoen  2011  is  in  2-­‐2   geeindigd.”     Op  grond  van  dit  enkele  feit  en  het  toevoegen  van  welgeteld  vier  extra   constraints,  is  er  een  klassendiagram  met  zes  klassen  met  eigenschappen  en   zesënveertig  standaardoperaties  ontstaan.  Het  vermelde  feit  is  een  bestanddeel   uit  het  URS.    In  het  objectmodel  is  deze  relatie  met  dit  requirement  terug  te   vinden.  Mocht  er  in  de  toekomst  iets  aan  dit  requirement  fact1  worden   gewijzigd  dan  zal  er  dankzij  het  metamodel  nauwkeurig  worden  aangegeven                                                                                                                   8  Ook  het  automatisch  genereren  van  de  bijbehorende  programmacode  (headers  met  complete  bodies)  lijkt  

geen  al  te  groot  probleem  te  zijn.   9  Dit  klassendiagram  is  met  behulp  van  Visual  Paradigm  Professional  Edition  opgesteld.  Binnenkort  biedt  de   Equa-­‐objectmodeler  een  vergelijkbare  functionaliteit,  waarbij  klassen  aan  het  onderliggende  objectmodel   worden  ontleend.  

 

pag  11  

welke  onderdelen  uit  het  objectmodel  speciale  aandacht  vergen.  Deze   traceability  wordt  consequent  voor  elk  modelelement  doorgevoerd.      

 

Figuur  6:  het  klassendiagram  gebaseerd  op  de  decompositie  van  fact1    

  Er  bestaan  binnen  het  metamodel  geen  modelelementen  die  niet  aan  ten  minste   één  bron  hun  bestaansgrond  ontlenen.  Bij  modelelementen  is  men  vrij  om   verder  te  kijken  dan  onderdelen  uit  het  objectmodel  (objecttypen,  feittypen,   overerfrelaties,  operaties).  Ook  use  cases,  scenario’s  en  test  cases  vallen   hieronder.       Het  objectroldiagram   Name   Naast  het  klassendiagram  kunnen  er  ook  zogenaamde   objectroldiagrammen  worden  gegenereerd.    Het  ORD  biedt   role   de  mogelijkheid  om  het  objectmodel  verder  te   role   configureren.  Naast  het  verwerken  van  de  constraints  uit   het  URS  krijgt  de  ontwerper  de  kans  om  andere  aspecten   role   te  verfijnen  en  ingewikkelde  relaties  verder  te  modelleren.   TypeExpression   We  verwijzen  u  naar  bijlage  1  om  een  betere  indruk  te   krijgen  hoe  een  objectroldiagram  eruit  zal  gaan  zien.     Het  tool  biedt  de  mogelijkheid  om  meta-­‐regels  te  laten  checken  en  te  zijner  tijd     aanbevolen  modeltransformaties  te  laten  uitvoeren.  Overigens  alleen  als  het   objectmodel  door  deze  metacheck  heen  is  gekomen,  kunnen  er  

 

pag  12  

klassendiagrammen  worden  gegenereerd.    Als  het  objectmodel  niet  in  voldoende   mate  is  uitgewerkt  of  het  bevat  zekere  tegenstrijdigheden  kan  er  geen   klassendiagram  worden  getoond.  Wel  is  het  mogelijk  om  klassendiagrammen  te   genereren  op  basis  van  een  onvolledige  verzameling  van  verwerkte  fact-­‐ requirements.     Aan  het  tonen  van  ORD’s  is  daarentegen  geen  beperking  verbonden.  Zij  kunnen   ook  worden  getoond  als  het  objectmodel  nog  niet  in  een,  voor  het  metamodel,   acceptabele  toestand  is  terechtgekomen.  Het  ORD  is  daarom  een  uitgelezen   medium  om  het  onderliggende  objectmodel  verder  te  configureren.     Use  cases   Aan  het  begin  van  deze  notitie  is  in  fig  1  op  schematische  wijze  de  grote  lijn  van   de  gepropageerde  werkwijze  weergegeven.  In  dit  schema  is  ook  het   usecasemodel  (UCM)  opgenomen.  Er  volgt  nu  een  korte  toelichting  op  de  rol  van   dit  model.   Use  cases  behoren  een  gedetailleerder  beeld  op  de  beschreven  functionaliteit  in   URS  te  geven10.  Aldaar  zijn  function-­‐requirements  beschreven.  Deze  globale   beschrijvingen  verdienen  een  detailuitwerking  zodat  de  mogelijke  mismatch   tussen  behoefte  vanuit  de  klant  en  realisatie  door  de  softwareontwikkelaars   verder  kan  worden  verkleind.                      

Use  Case  1   Verfijning  van  :  func2   Status  :     goedgekeurd   Naam  :       wedstrijd  verplaatsen   Actor:     competitieleider   Pre:     er  is  een  niet-­‐gespeelde  wedstrijd  gepland   Normal  flow:     1. Actor  kiest  te  verplaatsen  wedstrijd   2. Actor  vraagt  aan  systeem  om  agenda  met  geplande       wedstrijddatums  van  betrokken  teams   3. Actor  stelt  nieuwe  toekomstige  datum  voor  wedstrijd  vast   4. Systeem  voert  wijziging  van  datum  voor  wedstrijd  uit.   5. Systeem  alerteert  betrokken  teams.   Post:     datum  van  wedstrijd  is  verplaatst   Alternate  flow:   3.      Er  is  geen  ruimte  in  de  twee  agenda’s  van  de  twee  betrokken  teams   1. Actor  gaat  eerst  een  of  meer  andere  wedstrijden  verplaatsen   2. Stap  1  van  normal  flow    

  Figuur  7:  de  use  case  uitwerking  behorende  bij  funct2  uit  het  URS  

In  fig  7  is  het  functie-­‐requirement  funct2  van  het  URS  in  de  vorm  van  een  use   case  uitgewerkt.    De  use  case  is  een  prima  intermediair  tussen  klant  en   requirement  engineer.  Voor  de  requirement  engineer  ontstaat  hier  bovendien   een  extra  kans  om  de  requirements  uit  het  URS  aan  te  scherpen  of  uit  te  breiden.     De  use  case  vormt  een  interface  tussen  klant  en  systeemontwerper.  De  ene  zijde   van  de  interface  tussen  klant  en  use  case  is  zojuist  aangestipt.  Nu  de  andere  kant:                                                                                                                   10  In  SysUML  (zie  www.sysml.org)  wordt  uitgebreid  aandacht  gegeven  aan  de  traceability  van  modellen.  

Daarin  wordt  aangegeven  hoe  de  koppeling  tussen  onder  meer  requirements,  use  cases  en  test  cases  etc  kan   worden  gerealiseerd.  

 

pag  13  

welke  kansen  biedt  een  use  case  met  het  oog  op  het  conceptuele  ontwerp?    De   systeemontwerper  zal  zich  een  beeld  willen  vormen  van  de  scenario’s  die  bij  een   use  case  horen.  In  een  standaard  use  case  wordt  het  systeem  als  een  black  box   beschouwd.  De  systeemontwerper  zal  echter  bij  zijn  analyse  naar  een  white  box   voorstelling  van  het  systeem  overstappen.  In  deze  ontwerpfase  wordt  het   systeem  door  de  bril  van  een  conceptueel  klassendiagram,  of  zo  u  wilt   objectmodel,  bezien.  Zodra  de  systeemontwerper  aan  zijn  scenario-­‐analyse   begint  is  dat  klassendiagram  reeds  voor  het  overgrote  deel  ingevuld  met  klassen,   associaties,  attributen,  overerfrelaties  en  operaties.  De  systeemontwerper  zal  de   stappen  uit  een  scenario  met  behulp  van  de  instrumenten  in  het  klassendiagram   in  kaart  proberen  te  brengen.  Tegenstrijdigheden  en  onvolkomenheden  in  het   klassendiagram  kunnen  op  deze  wijze  worden  rechtgezet.  Deze  aanpassingen   resulteren  in  wijzigingen  van  het  onderliggende  objectmodel.  Normaliter   beperken  deze  wijzigingen  zich  tot  verfijning  van  het  gedrag  van  een  of  meer   objecttypen.  Wijzigingen  in  eigenschappen  van  een  objecttype  zouden   daarentegen  eigenlijk  via  het  pad  van  wijzigen  van  (fact-­‐)requirements  behoren   te  verlopen.  In  geval  van  gewijzigde  fact-­‐requirements,  zal  er  een  hernieuwde   decompositie  van  de  gewijzigde  feiten  plaatsvinden,  waardoor  het  objectmodel   vanuit  de  URS  een  wijziging  ondergaat.     Testen   Interessant  is  te  vermelden  dat  het  automatisch  genereren  van  testcases  geen   probleem  hoeft  te  zijn  zodra  ook  de  normal  en  alternate  flow  scenario’s  zijn   vastgelegd.  De  combinatie  van  de  geanalyseerde  feiten  en  de  scenario’s  biedt   immers  een  uitgelezen  kans  om  een  complete  set  met  testscripts  te  genereren.  De   feiten  uit  het  URS  moeten  dan  wel  met  het  oog  van  een  test  engineer  zijn   samengesteld.  Behalve  dat  ze  representatief  zijn,  horen  de  requirements  ook  de   grensgevallen  mee  te  nemen.     Nawoord   In  deze  uiteenzetting  is  een  pleidooi  gehouden  voor  een  werkwijze  waarin  er   vanuit  requirements  stapsgewijs  een  conceptueel  klassendiagram  wordt   geconstrueerd.  De  werkwijze  is  voorbereid  op  de  zich  onherroepelijk  wijzigende   requirements.    Hoe  blijft  met  zo’n  dynamische  input  het  ontwerp  consistent.  Er  is   aangegeven  dat  een  groot  deel  van  het  klassendiagram  geautomatiseerd  is   ingevuld.  Deze  automatiseringsslag  biedt  naast  tijdwinst  een  verhoging  van  de   kwaliteit  van  het  conceptuele  klassendiagram.    Dankzij  de  beschreven   automatisering  van  het  creëren  van  standaardgedrag  lijkt  het  genereren  van   bijbehorende  programmacode  en  testscripts  geen  onoplosbare  problemen  op  te   leveren.       Dat  klinkt  allemaal  veelbelovend.  Eigenlijk  te  mooi  om  waar  te  zijn.  We  moeten   echter  met  een  relativering  eindigen.  De  kwaliteit  van  een  objectmodel  wordt   voor  een  substantieel  deel  bepaald  door  de  kwaliteit  van  de  systeemontwerper   die  onder  meer  de  decompositie  van  de  feiten  uitvoert  .  Een  goede  scholing  en   voldoende  ervaring  vormen  een  noodzakelijke  voorwaarde.  Men  moet  in   voldoende  mate  zicht  hebben  op  ‘bad  smells’  in  de  decompositie  en  de  rest  van   het  ontwerp.  Met  zo’n  scholing  ontstaat  er  wel  een  ambacht  dat  op   gestructureerde  wijze  kan  worden  aangeleerd  en  onderwezen.  Een  

 

pag  14  

systeemontwerper  hoeft  dan  gelukkig  minder  terug  te  vallen  op  ‘de  gezond   verstand’  werkwijze.       Leerboeken  over  objectgeoriënteerd  ontwerpen  hoeven  zich  dan  niet  meer  te   bedienen  van  heuristieken  die  hun  domeinanalyse  starten  met  het   inventariseren  van  zelfstandige  naamwoorden,  waarna  er  meestal  een  nogal   moeizaam  proces  ontstaat  naar  een  conceptueel  klassendiagram,  waarbij  het   lang  duurt  voordat  men  er  een  goed  gevoel  bij  heeft.  In  hun  boek  over   objectgeoriënteerde  technologie11  vermelden  de  schrijvers:  “Helaas  bestaat  er   geen  eenvoudige  of  eenduidige  manier  om  een  verzameling  klassen  voor  een   probleemdomein  te  identificeren.  De  kwaliteit  van  de  domeinanalyse  is  sterk   afhankelijk  van  de  kennis,  intuïtie,  ervaring  en  vaardigheden  van  de  ontwerper  van   het  probleemdomein.”    Hopelijk  gaat  de  in  deze  notitie  gepropageerde  werkwijze   in  deze  leemte  voorzien.    

                                                                                                               

11  Zie  paragraaf  2.6.4  in:    Curtis  H.K.  Tsang,  Clarence  S.W.  Lau,  Ying  K.Leung  .  Objectgeoriënteerde  

Technologie,  Van  diagram  naar  code  met  Visual  Paradigm  for  UML.  Academic  Service,  2006.  

 

pag  15  

Bijlage  1:  prototype  of  an  object  role  diagram     FactType   Name       role     role     role       TypeExpression           ObjectType   Name       role     role       role     TypeExpression       constraints   rolename  

type  

constraints   rolename  

 

constraints   rolename  

• • • • • •    

 

Subtype   role   role   role   TypeExpression  

    Role  contains  2  or  3  departments   ObjectTypey

pe  

   

Supertype  

   

Role  connector  always  ending  at  outside  boundary  of  rounded  box  of   objecttype.   If  rolename  unknown,  rolenumber  should  be  shown.   If  type  of  role  is  a  basetype,  role  connector  is  never  shown.   Width  of  role  departments  depends  on  length  of  containing  text  ?   Roles  and  type  expression  may  be  hided.   TypeExpression  is  filled  with  the  object  type  expression,  unless  unknown,   in  that  case  the  fact  type  expression  should  be  shown.  

pag  16