H5_System Sequence Diagram & Operation Contracts PDF

**[1.0 SSD: Doel]** - Systeem sequentiediagram (SSD) = sequentiediagram dat alle interacties tussen actor n systeem v/1 use case scenario weergeeft - Is eenvoudiger UML-diagram dan sequentiediagram, omdat wij interne werking v/systeem als black-box zullen beschouwen n dit...

**[1.0 SSD: Doel]** - Systeem sequentiediagram (SSD) = sequentiediagram dat alle interacties tussen actor n systeem v/1 use case scenario weergeeft - Is eenvoudiger UML-diagram dan sequentiediagram, omdat wij interne werking v/systeem als black-box zullen beschouwen n dit dus x gaan modeleren - Uit SSD kunnen we interactie afleiden v/actor met systeem - We zien dus i/chronologische/sequentiële volgorde welke functionaliteit op systeem wordt uitgevoerd n hoe systeem al dan x data teruggeeft - Aangezien dit schema alle systeemoperaties bevat voor 1 bepaald scenario v/use case, vormt dit schema startpunt voor ontwerp later **[2.0 SSD: Onderdelen]** - SSD bevat steeds volgende onderdelen: - Deelnemer - Levenslijn per deelnemer - Systeemoperatie(s) - Daarnaast kan SSD ook volgende onderdelen hebben: - Antwoord op systeemoperatie - Herhaling - Verwijzing nr andere/externe use case (via ref.) ***2.1 Deelnemer*** - I/SSD komen steeds exact 2 deelnemers voor: actor systeem - Rol v/actor wordt steeds benoemd n is gelijk aan die v/primary actor v/use case - Aangezien actor is, terug te vinden op use case diagram, wordt deze aangeduid met mannetje n z'n rol - Deze deelnemer staat steeds i/linkse zijde v/schema - 2^e^ deelnemer, systeem, wordt, net als bij use case diagram, weergegeven door kader n wordt rechts geplaatst i/schema ***2.2 Levenslijn per deelnemer*** - Voor elke deelnemer wordt er levenslijn aan schema toegevoegd - Aangezien actor doorheen volledige schema als "actief" wordt beschouwd, is z'n levenslijn volledig doorlopende volle balk - Systeem daarentegen wordt als "x-actief" beschouwd als x systeemoperatie uitvoert - Levenslijn v/systeem zal dus afwisselend actief, volle balk of inactief, stippellijn, zijn ***2.3 Systeemoperatie(s)*** - Tijdens uitvoering v/use case zal primary actor \# acties op systeem uitvoeren waarop systeem al dan x antwoord geeft - We kunnen dit beschouwen als uitwisselen v/boodschappen tussen actor n systeem - Zo enkele boodschap v/actor aan systeem noemen we systeemoperatie - Deze wordt op schema voorgesteld als volle pijl die bij actor vertrekt n toekomt op systeem - Telkens zo boodschap op systeem ontvangen wordt, zal systeem actief worden n levenslijn dus nieuwe volle balk krijgen voor duur v/operatie - Systeemoperaties op SSD worden i/zelfde chronologische/sequentiële volgorde geplaatst zoals ze voorkomen i/gekozen scenario v/use case - Naam v/operatie die op pijl geplaatst wordt, moet wel aan enkele regels voldoen - Aangezien operatie is, moet ww bevatten aangevuld met () aangezien functie/methode voorstelt op systeem - Tussen haakjes worden, indien nodig, parameters opgesomd - Vermeld hierbij GEEN datatypes maar enkel namen v/parameters - Ook gebruiken we camelCasing notatie voor naamgeving - Zorg ervoor dat naam v/systeemoperatie duidelijk beeld geeft v/wat er gevraagd wordt aan systeem n x hoe systeem uitvoert - Bv.: gebruik x als systeemoperatie "klikKnop(username, password)" maar zet "meldAan(username, password)" - Gebruik hiervoor zelfde terminologie voor objecten n parameters uit - Als account i/DM password heeft, zet je ook i/SSD als parameter password n x wachtwoord - Aangezien ook DM x datatypes kent, worden deze ook x gebruikt i/SSD - Onze analysemodellen worden systeemonafhankelijk ontworpen n hebben dus x enkele weet v/mogelijke beschikbare datatypes later tijdens ontwerp/programmatie ***2.4 Antwoord op systeemoperatie*** - I/sommige gevallen kan gebeuren dat systeem reactie heeft op systeemoperatie die actor wens uit te voeren - Dit kan enkel voorkomen wnnr systeem data of berekeningen op data uit DM teruggeeft - Er is met altijd volle pijl v/actor nr systeem nodig alvorens er pijl kan terugkeren v/systeem nr actor - Wnnr dit gebeurt zal er terugkerende pijl, stippellijn, v/levenslijn v/systeem nr levenslijn v/actor getrokken worden - Aangezien dit antwoord is op systeemoperatie uitgevoerd door actor, hoort deze pijl ook bij zelfde activatieblokje - Op zo terugkeerpijl sommen we dan alle gegevens op die uit DM worden teruggegeven - Let er opnieuw op dat je zelfde terminologie gebruikt n dus ook klassen n attributen vermeld met hun zelfde namen - Geef je meerdere data v/eenzelfde klasse terug dan plaats je op pijl "lijst\" - Indien je x alle attributen v/enkele klasse teruggeeft dan plaats je dit als opsomming op pijl, bv. "lijst product: code, naam, prijs" - Aangezien we gegevens, of berekeningen op data, teruggeven, zijn dit NOOIT functies n is er dus ook x nood aan ww of () i/naamgeving - Er zal dus ook zeker x altijd terugkeerpijl aanwezig zijn - Enkel indien er gegevens getoond worden, volgens stap uit use case, kan er pijl zijn als die ook aan andere regels voldoet ***2.5 Herhaling*** - Kan voorkomen dat bij uitvoering v/scenario i/use case \# stappen herhaald worden - Om herhaling v/systeemoperaties, n eventuele antwoorden op systeemoperaties, aan te duiden, plaatsen we kader rond operaties die herhaald dienen te worden - Er wordt ook stopvoorwaarde toegevoegd - Is echter mogelijk dat kader die herhaling aanduidt activeringsblok op levenslijn v/systeem i/2 verdeeld - Dit komt voor wnnr antwoord v/systeemoperatie pas na herhaling gebeurt, terwijl echte systeemoperatie telkens herhaald wordt - Kan echter ook zijn dat antwoord v/systeemoperatie als 1^ste^ stap i/herhaling telkens uitgevoerd wordt, maar oproepende systeemoperatie slechts eenmalig wordt uitgevoerd - Voorbeeld v/deze laatste situatie kan je i/slides terugvinden - Daar wordt systeemoperatie "startBestellen()" slechts eenmalig uitgevoerd voor herhaling, maar antwoord op die operatie "lijst productie: code, naam, prijs" is telkens 1^ste^ stap i/herhaling ***2.6 Externe use case*** - Kan voorkomen dat bij uitvoering v/scenario i/use case primaire actor andere use case oproept - We "refereren" dus als ware nr ander schema/SSD - Omdat dit andere schema is nemen we die systeemoperaties n hun eventuele antwoorden x op i/ons SSD - We voegen enkel kader v/type "ref" toe met daari/naam v/andere use case die primaire actor oproept - Aanroepen v/externe use case door primaire actor kan je herkennen doordat deze onderlijnt is i/tekst **[3.0 SSD: Stappenplan]** - Om SSD op te stellen volgen we steeds zelfde stappen - Als 1^ste^ kiezen we use case scenario waarvoor we SSD wensen op te stellen - Dit is ofwel normaal verloop ofwel normaal verloop met integratie v/complex alt. verloop tot 1 scenario - Vervolgens voegen we 2 deelnemers toe: primary actor (als mannetje met volledige actieve levenslijn links) n systeem (als kader met inactieve levenslijn rechts) - 3^de^ stat bestaat er uit om nu systeemoperaties toe te voegen - Dit doen we door gekozen use case scenario op te delen i/blokken per nieuwe actie v/actor n bijhorende reacties v/systeem - Sla voorlopig nog acties met herhalingen over! - Nadien worden alle blokken chronologisch overlopen - Per nieuwe blok voegen we dan nieuwe systeemoperatie toe - Let op naamgeving n eventuele parameters - Dit zorgt ook voor nieuwe activeringsblokje op levenslijn v/systeem - Als systeemoperatie toegevoegd is, ga je ook na of reactie v/systeem voor antwoord op systeemoperatie zorgt i/SSD - Indien dat geval is, dan teken je terugkeerpijl met vermelding v/juiste gegevens op schema - Als laatste stap doorloop je opnieuw alle stappen v/gekozen scenario n voeg je herhalingen toe als die zich voordoen - Per herhaling voeg je dan kader toe die zich uitstrekt over systeemoperaties n eventuele antwoorden op systeemoperaties die meermaals uitgevoerd worden - Ten slotte voeg je ook per herhalingskader gepaste stopvoorwaarde toe **[4.0 OC: Doel]** - Operation contract (OC) = contract dat extra info omvat over 1 systeemoperatie uit SSD - Aangezien we bij SSD interne systeemwerking bij systeemoperatie x modelleren zou deze verloren gaan zonder bijhorend OC - OC biedt dan ook overzicht v/veranderingen/wijzigingen binnen DM die systeemoperatie te weeg zal brengen - I/OC zit dan ook veel extra info die handig is voor latere implementatie v/systeemoperatie om zo te kunnen testen of operatie op correcte manier werkt - X elke systeemoperatie v/SSD zal OC krijgen, dit is enkel voor systeemoperaties die iets wijzigen i/systeem **[5.0 OC: Onderdelen]** - OC bevat steeds volgende onderdelen: - Contract - Elk OC heef duidelijke naam/omschrijving deze is dus vrij te kiezen maar sluit beste aan bij systeemoperatie waarvoor OC wordt opgesteld - Operation - Hier wordt naam v/systeemoperatie uit SSD waarvoor je OC opstelt, overgenomen incl.() n eventuele parameters - Cross References - Wordt vermelding gemaakt v/use cases waari/deze systeemoperatie wordt uitgevoerd - Preconditions - Wordt staat v/systeem/DM beschreven voor systeemoperatie wordt uitgevoerd - Enkel x-triviale zaken worden hier opgenomen - Indien 2 opeenvolgende systeemoperaties elk OC hebben, dan neemt men i/OC v/2^e^ systeemoperatie onder precondities alle postcondities op uit OC v/voorafgaande systeemoperatie - Postconditions - Hieri/wordt gedetailleerde beschrijving opgenomen v/objecten uit DM die gewijzigd werden door uitvoeren v/systeemoperatie - Aangezien objecten n hun status beschrijft nadat systeemoperatie voltooid werd zullen deze i/verleden tijden worden genoteerd - Hoe bepalen we nu welke zaken we i/postcondities moeten opnemen? Daarvoor kijken we of er 1 v/volgende 5 zaken zich aandient tijdens uitvoeren v/systeemoperatie - Creatie v/instantie v/klasse - Verwijdering v/instantie v/klasse - Creatie v/associatie tussen 2 klassen - Verwijdering v/associatie tussen 2 klassen - Wijziging v/attribuut v/klasse - Voor elke v/bovenstaande situaties die zich voordoet wordt zin, i/verleden tijd, opgenomen i/postcondities - Er wordt dus als ware foto genomen v/staat voor uitvoeren v/systeemoperatie n deze wordt dan vergeleken met situatie na uitvoeren ervan - Verschil tussen beide situaties leg je vervolgens vast i/postcondities **[6.0 OC: Stappenplan]** - Om te bepalen of er OC, of meerdere, nodig is bij SSD overlopen we opnieuw gekozen scenario v/use case Per systeemoperatie uit SSD neem je bijhorende tekst v/use case door n controleer je of 1 v/volgende situaties zich voordoet: - Aanmaken v/instantie v/object/klasse - Verwijdering v/instantie v/object/klasse - Aanmaken v/associatie - Verwijdering v/associatie - Wijziging v/attribuut - Heb je min. 1 v/bovenstaande situaties dan stel je OC op bij bijhorende systeemoperatie - Herhaal dit voor elke overgebleven systeemoperatie