[UML] Opstellen klassediagram

[X-Lars]

Zie evt. [rml][ PDA applicatie] Hoe te beginnen?[/rml]

Ik wil graag dit project met UML 'ondersteunen'. Aardig boek erbij: Praktisch UML 3de editie (Warmer & Kleppe). Ik gebruik Enterprise Architect om de UML te visualiseren.

We gaan een applicatie maken waarmee een gebruiker gegevens uit een relatiemanager met z'n PDA kan synchroniseren (middels een XML bestand die de RM kan exporteren). Volgens mij wordt de situatie wel duidelijker aan de hand van deze modeldictionary:

Modeldictionary

Applicatie - Is verantwoordelijk voor het bidirectioneel synchroniseren van het XML bestand, het weergeven van de records en het wijzigen, toevoegen en verwijderen van de records.

RM (relatiemanager) - Is verantwoordelijk voor het XML bestand.

Gebruiker - Representatie binnen het systeem van een reëel persoon.

Record - Elk record representeert een klant uit het klantenbestand zoals deze is opgeslagen in de RM.

PC - Hier draait de RM op; kan het XML bestand in het geheugen opslaan.

PDA - Hier draait de applicatie op; kan het XML bestand in het geheugen opslaan.

XML bestand - Een XML bestand bevat de records uit de RM die gesynchroniseerd worden door de applicatie. Een XML bestand staat op de PC en op de PDA.

Vragen:
[list=1]
• Lijkt dit überhaupt ergens op?
• Hoe moet ik eigenlijk het XML bestand in het klassediagram opnemen? Omdat het fysiek op de PC en op de PDA wordt opgeslagen kunnen het prima twee instanties van 1 object zijn, maar ze moeten gesynchroniseerd worden. En dan vind ik het niet meer zo logisch om het zo te doen:

[Verwijderd]

1. Nee

Probeer niet te denken vanuit processen (wie is waar verantwoordelijk voor) want dan denk je modulair. Probeer liever na te denken over de entiteiten (gebruiker, gebruikersgroep, etc) en probeer vandaaruit omhoog te werken.

[NMe]

Verwijderd schreef op woensdag 02 maart 2005 @ 15:33:
1. Nee

Probeer niet te denken vanuit processen (wie is waar verantwoordelijk voor) want dan denk je modulair. Probeer liever na te denken over de entiteiten (gebruiker, gebruikersgroep, etc) en probeer vandaaruit omhoog te werken.

UML mag dan bedoeld zijn om relaties tussen objecten in een OO omgeving weer te geven, maar voor de relaties tussen processen is het ook wel geschikt. Een tekening dient informatie te geven waar je wat aan hebt. Als je meer waarde hecht aan de relatie tussen processen, dan is dit een nette tekening. Echter, je hebt wel gelijk dat een klassendiagram geen klassendiagram meer is op het moment dat er geen klassen in staan.

Een echt zinnig klassendiagram in de volle zin van het woord maak je door eerst eens in het echte leven te kijken welke "objecten" je zou kunnen gebruiken in je applicatie. Daarop bouw je dan verder. Na verloop van tijd vind je in een volgende iteratieslag wel uit welke aanpassingen of uitbreidingen noodzakelijk zijn.

[X-Lars]

Bedankt, maar met deze replies kan ik toch niet echt verder.

Een object is een zelfstandig iets wat van belang is voor andere objecten in de omgeving en kan diensten die het voor zijn omgeving kan uitvoeren. Het is zijn eigen verantwoordelijkheid om deze diensten correct uit te voeren.

Moet ik soms meer de klassen Gebruiker, PC en PDA onderscheiden en daarmee verder gaan? Want dat is wat ik volgens mij gedaan heb...

[Jigs]

1.In een klasse diagram beschrijf je de entiteiten. Welke klasse is waarvoor verantwoordelijk? Je kan dit makkelijk doen door op een a4-tje de omschrijving van de applicatie uit te schrijven. De zelfstandige naamwoorden zijn dan de kandidaat klassen. Die moet je onder elkaar zetten en vervolgens moet je gaan strepen.
2.Het XML bestand zelf hoef je niet op te nemen in het klasse diagram. Je kan wel een klasse maken die verantwoordelijk is voor het inlezen van het xml bestand.

[X-Lars]

1. Zo heb ik ook zo'n beetje gedaan:

Functionele eisen

• De applicatie moet eenvoudig te installeren zijn op de PDA.
• De applicatie op de PDA moet bij plaatsing op het docking station automatisch of na activering de eigen records met de records van de PC synchroniseren.
• Welke records dit zijn wordt op de PC in de RM bepaald middels de XML exportfunctie. De gebruiker kan alle records hier filteren en zo specificeren welke records op de PDA zullen komen.
• Op de PDA kan door alle records gebladerd worden.
• Op de PDA kunnen records gewijzigd worden.
• Op de PDA kunnen records toegevoegd worden.
• Op de PDA kunnen records verwijderd worden.
• Bij synchronisatie na mutatie van één of meerdere records op de PDA wordt gecontroleerd of de originele records op de PC gemuteerd zijn. Bij elk record waarbij dat het geval is wordt de gebruiker gevraagd welk record het juiste record is. Bij alle records waarbij dat niet het geval is wordt het oude record op de PC vervangen door het gemuteerde record op de PDA.

Resultaat van klasseselectie

adressenbestand: irrelevant (redundant met RM)
applicatie: klasse
RM: klasse
database: irrelevant (redundant met RM)
desktop PC: klasse
docking station: irrelevant (redundant met RM)
gebruiker: klasse
klant: redundant met record
notitie: attribuut
PDA: klasse
records: klasse
Windows besturingssysteem: irrelevant
XML bestand: klasse
XML exportfunctie: redundant met PC

2. Dat was dan de XML exportfunctie

[Verwijderd]

Jigs schreef op woensdag 02 maart 2005 @ 16:35:
2.Het XML bestand zelf hoef je niet op te nemen in het klasse diagram. Je kan wel een klasse maken die verantwoordelijk is voor het inlezen van het xml bestand.

Hoe heet die klasse dan? XMLFile

edit
in reactie op de laatste post van TS:
Als je een meervoudsvorm als klasse naam definieert dien je altijd te verifieren of dit daadwerkelijk correct is. Als voorbeeld je klassificatie "records". In principe bestaat er dan altijd nog eerst een klasse genaamd "Record". De klasse "Records" zou dan een collectie klasse impliceren waaraan je meerdere Records kan toevoegen (dus bevat add/remove methodes). Om iets te doen met een enkel record gebruik je een manager, oftewel een "RecordManager" (bijvoorbeeld in het geval van persistent maken van data, anders gezegd: in de database proppen)

[ Voor 77% gewijzigd door Verwijderd op 02-03-2005 16:52 ]

[FendtVario]

Verander het woord Record eens in Klant (of relatie). Record is net als het woord 'data' of 'gegevens' iets waar je niets mee kunt. Je merkt gebruiker aan als klasse, heeft deze nog betekenis in de applicatie of is alleen de wezenlijke persoon die een knop indrukt. De gebruiker is dan geen entiteit maar de actor.

PDA en PC zijn de machines waarop je beide delen van je applicatie uitvoert, zijn ze alleen hulpmiddel?

Aan de hand van de functionele eisen kun je use-cases maken, vanuit de use-cases kun je dan de entiteiten halen.

Ik vind Pragmatisch modelleren met UML 2 van Sander Hoogendoorrn trouwens een beter boek.

[farlane]

X-Lars schreef op woensdag 02 maart 2005 @ 15:30:
Hoe moet ik eigenlijk het XML bestand in het klassediagram opnemen? Omdat het fysiek op de PC en op de PDA wordt opgeslagen kunnen het prima twee instanties van 1 object zijn, maar ze moeten gesynchroniseerd worden.

Je kunt je afvragen of je wel een klasse XMLbestand moet hebben. Het is een beetje afhankelijk van wat je met dit ontwerp wilt. Maar zelfs als je wilt weergeven dat er 'gegevensuitwisseling' plaatsvindt, kun je je afvragen of je wel wilt vermelden dat het een XML bestand is. Het gaat in principe al vrij diep in op de manier waarop je die uitwisseling wil laten plaatsvinden, terwijl de rest van het diagram behoorlijk abstract is.

Overigens, staar je niet al te blind op die mooie diagrammetjes. Mijn ervaring is dat een globale opzet wel vruchten afwerpt omdat je gedwongen wordt goed over je ontwerp na te denken. Echter, een groot deel van het detailontwerp wordt in de praktijk gereversed-engineered.

[Remus]

Als ik jouw was zou ik Praktisch UML eens lezen voordat je maar wat gaat doen. Dit lijkt namelijk helemaal nergens op en is voor mij een teken dat je het boek niet hebt gelezen, maar alleen hebt doorgebladerd. Ik kan je aanraden om iig de case-hoofdstukken te lezen om een beetje feeling te krijgen met modelleren met UML.
Je denkt namelijk te veel naar de implementatie en niet naar de objecten/klassen die je nodig hebt om je probleem op te lossen. Begin eerst daar en ga pas daarna denken hoe je dat om gaat vormen tot een bruikbare applicatie.

[X-Lars]

Bedankt voor alle input! Het is duidelijk dat ik het niet goed aanpak. Het probleem ligt imo vooral bij het vaststellen van de objecten/klassen. Ik ga het nog eens proberen vanuit een andere optiek. Alle goed bedoelde commentaar is imo nog wat abstract (algemeen). Als iemand nog suggesties heeft dan hoor ik deze natuurlijk graag. De functionele eisen zijn in ieder geval een basis.

FendtVario schreef op woensdag 02 maart 2005 @ 17:29:
[...] Je merkt gebruiker aan als klasse, heeft deze nog betekenis in de applicatie of is alleen de wezenlijke persoon die een knop indrukt. De gebruiker is dan geen entiteit maar de actor. [...]

Gebruiker is een actor in het use-case diagram. Maar volgens mij is het ook een klasse, omdat het een zelfstandige rol speelt in deze omgeving (de omgeving kan niet zonder).

offtopic:
@Remus: het boek heb ik wel goed doorgelezen (t/m H. 10-11, waar we het nu over hebben gaat t/m H. 5).

[Verwijderd]

Wat doet de actor 'gebruiker' in je use-case diagram?
Staat daar bijvoorbeeld 'meld zich aan' dan betekend dit dat er binnen je applicatie een entiteit bestaat die 'Gebruiker' heet en attributen als gebruikersnaam en wachtwoord heeft.

[X-Lars]

Ik heb nog geen use-case diagram, maar de actor Gebruiker kan bijvoorbeeld 'Relaties synchroniseren' of 'Relatie wijzigen'.

[SPee]

Volgens mij lijkt je diagram meer op een Use-Case.

Bij een Use-Case en Sequence diagram krijg je te maken met andere entiteiten dan binnen je programma. Zo kan een handeling van een gebruiker (op een knop klikken of export maken van RM) wel in deze diagrammen voorkomen.
Als je een klasse diagram maakt, dan moet je alleen rekening houden met het programma dat je gaat schrijven en wat het gaat opslaan en bewerken. Als je een entiteit PC maakt, dan betekent dat dat je gegevens over PC gaat bewerken/bewaren. Dat is met een PDA ook zo. Zo kun je deze klasses wel bv. bij de pricewatch tegenkomen, maar niet in een klanten relatie systeem (tenzij je ook hun pc systemen gaat bijhouden). Je houdt in een klasse diagram geen (of in lichte mate) rekening mee met processen of handelingen die een gebruiker gaat doen. Je houdt er geen rekening mee met "De gebruiker maakt een xml export bestand in RM en importeert deze". Je denkt "Ik wil een xml bestand importeren en wil ik deze ook in zijn geheel opslaan (als gegevensbron), wil ik daar een aparte entiteit voor aanmaken of wil ik alleen de gegevens uitlezen en die opslaan". Bij dat laatste maak je dan aparte klasses voor de gegevensobjecten die in de xml bestand staan.

Om een lang verhaal wat korter samen te vatten.
Je moet uit je programma denken, niet aan de handelingen die je als gebruiker moet doen. Zo moet je geen rekening houden met de export bestand die aangemaakt moet worden, omdat de applicatie die je gaat schrijven dat niet voor je gaat doen. Die app weet alleen dat er een bestand is. Hoe dat tot stand is gekomen boeit niet.

Als je eenmaal weet hoe UML werkt, dan kun je er best wel veel mee. Het bevat alleen veel denkwerk hoe je dat moet opzetten.

[FendtVario]

SPee schreef op donderdag 03 maart 2005 @ 11:38:
Volgens mij lijkt je diagram meer op een Use-Case.

Een use-case is geen diagram. Een use-case is geschreven tekst waarin (grof gezegd) je van een handeling aangeeft wie de actor is, welke handelingen de actor uitvoert, welke reactie het systeem hierop geeft en wat de pre- en post condities zijn.

Als je eenmaal weet hoe UML werkt, dan kun je er best wel veel mee. Het bevat alleen veel denkwerk hoe je dat moet opzetten.

Als ik bovenstaande lees moet je volgens mij zelf ook nog een hoop leren.

[SPee]

Volgens mij bestaat er ook een Use-Case diagram
Leuk tekenen met poppetjes enzo

Het klopt idd dat er voor een officiele use-case ook nog tekst erbij moet, maar als je het alleen voor je zelf schrijft, waarom zou je dan. Veelal beschrijft die tekst: "user klikt op knop", terwijl er geen andere logische actie kan plaatsvinden. Als je een echte Use-Case voor collega of klant schrijft, dan wordt het idd een uitgebreid document met veelal logische acties. Dus ik weet mss wel meer dan jou

[ Voor 3% gewijzigd door SPee op 03-03-2005 12:58 ]

[FendtVario]

Er bestaat wel een use-case diagram, dat klopt. In dit diagram kun je zien hoe de use-cases aan elkaar gerelateerd zijn en door wie ze uitgevoerd kunnen worden. Dus een actor die bijvoorbeeld de use-case Relatie zoeken uitvoert. De use-case beschrijft de handeling.

"user klikt op knop" is geen use case, dat is misschien een van de handelingen in een use-case. Voorbeeldje;

Use-case Relatie zoeken
Naam: Relatie zoeken
Actor: Een balie mederwerker
Voorwaarde: De baliemedewerker is ingelogd
Beschrijving: 1) De actor vult een of meerdere parameters oa. naam, plaats, postcode
2) De actor verstuurt de voorwaarden door een klik op de knop Zoeken
3) Het systeem toont een lijst met relaties die voldoen aan de voorwaarden
4) De actor kiest een relatie
5) Het systeem toont de gegevens van de relatie
Eindtoestand: De gezochte relatie staat op het scherm

Een use-case diagram:

(Edit: Actor moet baliemedewerker heten)

Natuurlijk kunnen er in de use-case nog uitzonderingen voorkomen zoals dat geen relaties voldoen aan de gestelde voorwaarden, het zoeken wordt afgebroken of dat er opnieuw gezocht wordt.

[ Voor 3% gewijzigd door FendtVario op 03-03-2005 13:42 ]

[X-Lars]

Poging #2:



RelatiesExtern stelt dan de records uit de RM voor en RelatiesIntern de records op de PDA. In de klasse Applicatie staan wat voorbeeldoperaties.

Ik zit nog wel te twijfelen hoe ik de klasse Relatie nou moet zien. Is dat meer een superklasse voor RelatiesExtern en RelatiesIntern (door de overeenkomstige eigenschappen/attributen) of is elke instantie van Relatie een object dat bijv. RelatiesIntern nodig heeft om zijn services te kunnen verlenen aan Applicatie?

Of doe ik weer heel vreemd?

[whoami]

Waarom is 'Applicatie' uberhaupt een class ?
Je doet idd wel heel vreemd; ik denk dat je eerst eens jouw probleem vanuit een OO standpunt moet bekijken, want voor zover ik het nu zie, doe je dat niet.

Ik veronderstel dat de applicatie die je wilt ontwikkelen een soort van veredelde adresboek ofzo is?
Als je een klassendiagram maakt, dan ga je de classes die jouw applicatie nodig heeft, en de relaties tussen deze classes schematisch gaan voorstellen.
Een class in het diagram moet dan 'iets' voorstellen dat door jouw applicatie zal gebruikt worden; een class stelt een 'entiteit' voor die voorkomt in jouw probleem-domein.
In jouw diagram zie ik eigenlijk niets daarvan terug.

In jouw startpost praat je bv. over 'klanten', maar ik zie nergens een klasse 'Klant' ofzo in jouw diagram.

Ik zie ook dat je een boek gebruikt over UML; maar ik denk dat je eerst beter eens een boek leest over 'Object Oriented software engineering' ofzo. Je moet eerst snappen wat OO ontwikkelen is en inhoudt, alvorens je iets gaat gaan lezen over de notatie (want dat is UML).

[ Voor 19% gewijzigd door whoami op 03-03-2005 14:33 ]

[X-Lars]

Ik had er ook al niet echt een goed gevoel bij. Ik zal er zo eens wat beter over nadenken.

Relatie is in ieder geval hetzelfde als Klant en het wordt idd een soort adresboek op de PDA.

[whoami]

Maak eerst eens een 'domein-model'. Definieer de classes die nodig zullen zijn om al die informatie te kunnen opslaan / verwerken, en de relaties tussen die classes.

Dit zal dan jouw model zijn waar je applicatie waarmee je die 'relaties/klanten' mee beheert zal werken, en het zal ook met dit model zijn dat de service/applicatie die je nodig hebt om de synchronisatie te doen mee zal werken.

[X-Lars]

*KICK*

Hopelijk wil je de moeite nemen om het topic door te lezen

Ik ben nu in de analysefase tot het volgende domeinmodel gekomen:



en dit use case diagram:



Met als mogelijke aannames:
- Relaties synchroniseren kan alleen als er verbinding is met de PC.
- De overige use cases kunnen alleen als er tenminste éénmaal is gesynchroniseerd.

Ik zou graag jullie reactie hierover horen, zodat ik weet of ik op de goede weg ben

[X-Lars]

Nog maar een kick

Voor de duidelijkheid het functioneel verhaaltje in het kort:

Op de PC draait een relatiemanager (RM). Deze kan een XML bestand met relatiegegevens exporteren. De PDA kan dit XML bestand ophalen en met zijn eigen (lokale) XML bestand synchroniseren. Op de PDA draait een applicatie waarmee deze relatiegegevens bekeken en gewijzigd kunnen worden. Uiteindelijk moeten ook de gegevens naar de PC kunnen worden gesynchroniseerd.

Op basis hiervan zijn de diagrammen uit de vorige post tot stand gekomen. Het ziet er misschien wat simpel uit, maar in het begin was ik helemaal verkeerd aan het denken. Hopelijk gaat het nu beter.

Ik zou graag nogmaals om jullie reactie willen vragen

[THIJZEL]

X-Lars schreef op vrijdag 18 maart 2005 @ 11:30:
*KICK*

Hopelijk wil je de moeite nemen om het topic door te lezen

Ik ben nu in de analysefase tot het volgende domeinmodel gekomen:

[afbeelding]

en dit use case diagram:

[afbeelding]

Met als mogelijke aannames:
- Relaties synchroniseren kan alleen als er verbinding is met de PC.
- De overige use cases kunnen alleen als er tenminste éénmaal is gesynchroniseerd.

Ik zou graag jullie reactie hierover horen, zodat ik weet of ik op de goede weg ben

Je moet in je domain klasse diagram nog geen rekening houden met het platform( pc/pda)..
De domeinklasse 'relatie' heb je, wat je voor de rest moet hebben is me nog niet helemaal duidelijk.
Probeer eerst je eisen goed en gedetailleerd te beschrijven, probeer daar niet de vraag 'hoe?' te beantwoorden maar eerder de vraag 'wat?'.

Probeer ook de attributen van relatie eens vast te leggen.(misschien komen hier wel meer klassen naar voor).

[ Voor 3% gewijzigd door THIJZEL op 21-03-2005 12:28 ]

[X-Lars]

Zou mijn domeinmodel dan alleen bestaan uit de klasse 'Relatie'?

De vragen die met 'wat' beginnen gaan over de objecten die nodig zijn om dit probleem op te lossen? Volgens mij kom ik dan alleen uit op de klasse 'Applicatie' die de klasse 'Relatie' (het XML bestand) uit gaat lezen, bewerken en opslaan. En eventueel de klasse 'RM' o.i.d. die hetzelfde doet aan de andere kant.

[ Voor 9% gewijzigd door X-Lars op 22-03-2005 09:44 ]

[THIJZEL]

Ok, stel Relatie is vooralsnog je enige domeinklasse. Welke attributen/eigenschappen heeft deze klasse dan, som ze eens op.

[X-Lars]

Excuses dat ik zo traag reageer, ben hier namelijk wel heel erg in geïnteresseerd.

De attributen van Relatie zijn bijvoorbeeld naam, adres en notitie.

Eigenschappen?

Volgens mij kan ik er ook geen operaties aanhangen, want andere objecten (RM, Applicatie?) voeren er bewerkingen op uit (inlezen, zoeken, bewerken, etc.). Een object Relatie doet zelf niets, lijkt me toch? Deze is imo alleen verantwoordelijk voor het vasthouden van data.

Ik kan hier ook nog niet echt nieuwe klassen uit afleiden. Of het moeten Applicatie en RM zijn, zoals ik in mijn vorige post aangaf.

[Wokker]

X-Lars schreef op donderdag 24 maart 2005 @ 15:00:
Excuses dat ik zo traag reageer, ben hier namelijk wel heel erg in geïnteresseerd.

De attributen van Relatie zijn bijvoorbeeld naam, adres en notitie.

Eigenschappen?

Volgens mij kan ik er ook geen operaties aanhangen, want andere objecten (RM, Applicatie?) voeren er bewerkingen op uit (inlezen, zoeken, bewerken, etc.). Een object Relatie doet zelf niets, lijkt me toch? Deze is imo alleen verantwoordelijk voor het vasthouden van data.

In de klasse Relatie kan je zeker wel methoden hangen zoals bijvoorbeeld setNaam(Naam); of de getNotitie(relatieId, datum);. Als ik het goed begrepen is doen ander klassen alleen aanvragen op een de klasse relatie maar voeren nooit zelf de bewerkingen uit op een attribuut van de klasse relatie. Dit moet afgehandeld worden door methode van deze klasse.

Een klasse XML (maar mischien denk ik al te ver) kan er ook in zitten deze klassen kan bijvoorbeeld methode bevatten om allee gevens in een xml document te zetten. Die vervolgens door de Klasse communicatie. verstuurd kan worden(met de nodige methoden daar bij natuurlijk.)

[ Voor 1% gewijzigd door Wokker op 24-03-2005 20:18 . Reden: kleine tik foutjes ]

[farlane]

Overigens kan het heel goed zijn dat je in je implementatie een klasse 'RelatieManager" oid hebt die de zoekacties e.d. doet. ( Maw de UI interact voornamenlijk met de RelatieManager' klasse ). Pas vooral bij die objecten op dat ze niet te groot worden.

Niet alleen de 'zelfstandige naamwoorden' zijn objecten. Er zijn er meer.

[X-Lars]

Update

Het domeinmodel uit de analysefase:


Het gaat uiteindelijk om de wisselwerking tussen de beide Relatie-objecten (XML bestanden) die beheerd en gesynchroniseerd moeten worden (op PC en PDA).

En vervolgens het klassemodel uit de designfase:


RelatieIO zorgt ervoor dat de records uit de database van RM worden gehaald en in een XML bestand op de PC (RelatiesRM) worden opgeslagen. Die worden vervolgens met ActiveSync naar de PDA verplaatst (RelatiesApplicatie), dit gebeurt ook door RelatieIO. RelatieIO zorgt ook voor de synchronisatie tussen beide bestanden (door ze eerst te vergelijken). Met RM en Applicatie kunnen de records op resp. de PC en PDA beheerd worden (de operatie beheerRelaties() is even gebruikt om dat samen te vatten).

Reacties meer dan welkom!

[X-Lars]

*kick*

Reacties nog steeds meer dan welkom

[Verwijderd]

Ik heb niet het hele verhaal gelezen. Bij je laatste schema: je hebt klasses die niets toevoegen aan hun basisklasse (alle vakken behalve 'naam' zijn leeg). Zulke klasses heb je niet nodig .

[X-Lars]

De vermelde attributen en operaties staan nog niet vast, die staan er meer ter illustratie. Ik snap dat een klasse zonder attributen en/of operaties in principe van weinig nut is (al weet ik niet zeker of een klasse verplicht attributen en/of operaties moet bevatten). Maar ik ga er deze week weer eens goed mee aan de slag.