OOS Object geOrienteerd Software-ontwerp 1 Organisatie OOS Proces van software-ontwikkeling Requirements Inleiding Analyse & Ontwerp

Organisatie OOS Leerdoelen Leerproces Activiteiten Afronding Informatie http://intranet.hi.fontys.nl/users/hem/

Leerdoelen Correct interpreteren van UML en toepassen gedurende het ontwerp in een juiste volgorde schetsen proces van software ontwikkeling en van de diverse stappen aangeven wat de belangrijkste kenmerken zijn toepassen van een aantal ontwerppatronen en het gebruik van packages leren werken met een OO case-tool

Leerproces Werken in projectgroepjes van maximaal 4 studenten aan casus. Individuele begeleidingsgesprekken, eenmaal halverwege de module, 15 minuten per student. Wekelijkse werkbijeenkomsten per groep Taakverdeling tussen docent en student Docent begeleidt, student moet zorgen dat hij iets leert

Activiteiten 1/2 Opstellen van een conceptueel klassendiagram en formuleren van belangrijke use-cases. 2/3 Coderen van de klassen conform statisch klassendiagram. Toepassen van compositie. 3 Uitwerken van concrete scenario’s bij de use-cases: werk verdelen over de groepsleden. Per persoon een sequentiediagram maken naar het zelf opgestelde scenario. 4 Singleton patroon en facade patroon toepassen. Klassendiagram verfijnen. Verder werken aan het coderen van de methoden die in week 3 werden toegevoegd. 5/6 Per persoon: een toestandsdiagram van een door de docent aangewezen klasse maken als huiswerk. een grote of een klein aantal samenhangende use-cases onderbrengen in een gui-panel ontwerp in overleg met de docent. 5/6/7 Per persoon een gui bouwen voor het gekozen deel van de casus. 8 Afronden van de module.

Activiteiten 1 /2 Opstellen van een conceptueel klassendiagram en formuleren van belangrijke use-cases. 2/3 Coderen van de klassen conform statisch klassendiagram. Toepassen van compositie. 3 Uitwerken van concrete scenario’s bij de use-cases: werk verdelen over de groepsleden. Per persoon een sequentiediagram maken naar het zelf opgestelde scenario. 4 Singleton patroon en facade patroon toepassen. Klassendiagram verfijnen. Verder werken aan het coderen van de methoden die in week 3 werden toegevoegd. 5/6 Per persoon: een toestandsdiagram van een door de docent aangewezen klasse maken. een grote of een klein aantal samenhangende use-cases onderbrengen in een gui-panel ontwerp in overleg met de docent. 5/6/7 Per persoon een gui bouwen voor het gekozen deel van de casus. 8 Afronden van de module.

Afronding Student moet aantonen dat hij de doelen gerealiseerd heeft. Voorbeelden verzamelen en daar een goed verhaal bij vertellen. In de voorbeelden alleen die dingen opnemen die zelf gemaakt zijn. Het gerealiseerde product speelt op zich geen rol Mondeling van 30 minuten waarin student aantoont doelen gerealiseerd te hebben. Docent gebruikt checklist en criteria. Om de mondelinge toets met een voldoende te kunnen afronden, is een eerste voorwaarde dat de doelen duidelijk zijn. Dit zal niet vanaf week 1 het geval zijn. Het is daarom zaak steeds weer naar te doelen terug te kijken en “doelgericht” te werken. Herkansing: Voor de herkansing geeft de docent op basis van de beoordeling voor de toets een extra opdrachten en een deadline waarvoor die moeten zijn afgerond. Deze deadline ligt altijd voor het begin van het volgende blok. Daarna volgt opnieuw een mondelinge toets over alle onderwerpen. Voor deze herkansing is nog slecht 15 minuten beschikbaar.

Proces van Software ontwikkeling

Watervalmodel

Iteratief proces

Interactief Een systeem voor klanten Domeindeskundige Communicatie mbv standaardtaal (UML) Use case (diagram) Klassendiagram (statisch) Sequentiediagram Klassendiagram (dynamisch) Toestanddiagram … Bij het eerste punt kan uitgewijd worden over het punt dat automatiseerders al te vaak zelf weten wat handig is. Voorbeelden te over, bijvoorbeeld uit bekende Microsoft interfaces. Het tweede punt heb ik opgenomen als link naar UML. Dat dit een belangrijke rol speelt in de communicatie met klanten.

Incrementele software ontwikkeling Incrementeel Iteratief Interactief Hier aankondigen waarover de instructie gaat

Requirements

Use-case Template: name actor(s) preconditions normal flow (alles gaat goed) results (alles gaat goed) alternate flow

Mediatheek ‘De Uitleen’ Uitlening van boeken, audio-cd’s, cd-rom’s, videocassettes, video en dvd’s. Er zijn allerlei categoriën voor de diverse uitleenbare media. Klanten kunnen lenen, reserveren, afgeschreven items kopen. Bij te laat terugbezorgen is boete verschuldigd. Van klanten worden naam, adres en telefoonnummer bijgehouden.

Use case (voorbeeld) name actors pre normal flow results alternate Registreer klant actors Baliemedewerker pre normal flow Medewerker voert klantgegevens in Systeem toont klanten met hetzelfde adres Medewerker bevestigt registratie Systeem toont klantnummer results Klant is geregistreerd met klantnummer alternate Klant was al geregistreerd [3]  Medewerker annuleert registratie

Use case (voorbeeld 2) name Leen uit actors Baliemedewerker pre Klant is bekend normal flow Medewerker voert klantnummer in Systeem toont klantgegevens Medewerker voert item-nummers in Systeem toont gegevens uit te lenen items Medewerker bevestigt uitlening results Uitlening van deze items is voor deze klant geregistreerd alternate Klant bezit items waarvan de uitleentermijn is verstreken [2]  uitlening wordt door systeem geweigerd. Klant wil te veel items lenen [3]  ga terug naar [3]

voorbeeld 2: verbeterde versie name Leen uit actors Baliemedewerker pre normal flow Medewerker voert klantnummer in Systeem toont klantgegevens Medewerker voert item-nummers in Systeem toont gegevens uit te lenen items Medewerker bevestigt uitlening results Uitlening van deze items is voor deze klant geregistreerd alternate Klant bezit items waarvan de uitleentermijn is verstreken [2]  uitlening wordt door systeem geweigerd. Klant wil te veel items lenen [3]  ga terug naar [3] Klantnr bestaat niet [2]  ga terug naar [1]

Use Case Diagram

OO Analyse en ontwerp

Object: 2 dimensies object creatie gedrag (inspectie, wijziging) (opruiming) gedrag object toestand eigenschappen statische constraints

Klassendiagram Bouwtekening Eigenschappen van objecten (statisch) Associaties Attributen Gedrag van objecten (dynamisch) Methoden Constructoren Restricties (statische)

Statisch klassendiagram (voorbeeld) naam : Text adres : Text Bedrijf 1 ◄vindt plaats bij 0..* Student Praktijk periode afk : Text Docent 1 0..3 0..* 0..1 id : Integer naam : Text doet wordt begeleid door start : Date Hierbij een korte toelichting op de betekenis en rol van dit diagram. Afstuderen nr : Integer Stage is voorzitter bij 1 0..* datum : Date Voordracht ◄i.v.m.

Klassendiagram Conceptueel perspectief Specificatie perspectief communicatie analist/ontwerper communicatie met domeindeskundige? Specificatie perspectief Implementatie perspectief communicatie ontwerper/programmeur welke keuze in programmacode

Associatie Relatie associatienaam Uiteinden: rolnaam multipliciteit

Attribuut verschil met associatie: conceptueel nivo specificatieniveau geen verschil minder details specificatieniveau eenrichting implementatieniveau: zichtbaarheid suggestie voor opslag van data

Domeinmodel binnen totaal systeem GUI Legacy Domeinmodel Netwerk Persistentie

deze week keuze casus bestudeer: UML distilled opstellen use cases Hoofdstukken over Klassendiagram en Use Cases opstellen use cases eerste aanzet klassendiagram (domein)

volgende week Together Werken met CRC Gedrag Navigatie Generalisatie Compositie