[uml] klassendiagram functioneel of technisch?

[Verwijderd]

Is het klassendiagram van UML op te vatten als een functioneel of technisch ontwerp???

Ik twijfel zelf hierover, maar ik denk functioneel, aangezien je in dit klassendiagram weergeeft welke business objects (entiteiten) er binnen de scope van het project vallen.

Wat denken jullie?

^{(vind het altijd erg lastig om iets te typeren als functioneel of technisch)}

[BoAC]

Is het geen stap tussen functioneel en technisch.
Je wilt met je UML aan je functionaliteit voldoen maar direct de stap doen naar je technisch ontwerp -> je deelt je functioneel probleem op in delen.

[whoami]

Een klassendiagram is imo technisch, aangezien je daar al -naast je classes, en de relaties ertusen- ook de attributten en methods gaat gaan definieren.

[Pooh]

Ik ga met whoami mee. Niet alleen omdat er al attributen en methods worden gedefinieerd (die zijn voor een deel onderdeel van de functionaliteit), maar juist ook omdat er door een klassediagram al duidelijk gekozen wordt voor een object-gorienteerde benadering, wat mij een technische, en geen functionele keuze lijkt. Een OO-model is zeker niet de enige manier om de wereld te modelleren.

[CubicQ]

Dat ligt eraan hoe je een Class Diagram gebruikt. Gebruik je het als pure representatie van je implementatie-classes + relaties + attributen + operations dan is het technisch. Maar je kan een UML Class Diagram ook voor totaal andere dingen gebruiken (aangezien de semantiek van UML niet formeel vastgelegd is!).

Je zou bijvoorbeeld ook mbv het EDOC profile een UML Class Diagram met ProcessComponents kunnen maken. Dat zit op een compleet ander abstractieniveau en heeft helemaal niets met implementatie-classes, attributen etc te maken.

[Verwijderd]

hmm, is dat echt zo, of komt dit door jullie (??) technische invalshoek?

Het is nml ook erg goed mogelijk om functioneel een te bouwen app te beschrijven. Bijv. de classes zijn de bedrijfsobjecten (bijv. alleen klanten, orders en offertes vallen binnen de scope) en de methoden vormen dan de elementaire processen in een systeem (offertes verwerken, order toevoegen e.d.)

En kijk maar eens naar de Use-cases. Ook functioneel.

Dus ik weet het nog steeds niet... de grens tussen functioneel en technisch is erg vaag..
Andere redenaties zijn nog steeds welkom

[Creepy]

De keuze in welk paradigma je gaat ontwikkelen lijkt mij een technische keuze (of maak jij in je FO al de keuze welke ontwikkelomgeving e.d. er gebruikt gaat worden, als je deze keuze uberhaupt kunt maken natuurlijk). Als je UML gaat gebruiken zit je volgens mij vast aan OO. Dus zeker het klasse diagram lijkt me thuis te horen in het technisch ontwerp.

[Pooh]

Verwijderd schreef op 17 September 2003 @ 12:01:
...Het is nml ook erg goed mogelijk om functioneel een te bouwen app te beschrijven. Bijv. de classes zijn de bedrijfsobjecten (bijv. alleen klanten, orders en offertes vallen binnen de scope) en de methoden vormen dan de elementaire processen in een systeem (offertes verwerken, order toevoegen e.d.)

En kijk maar eens naar de Use-cases. Ook functioneel...

Natuurlijk is het mogelijk een functioneel ontwerp te maken. Sterker nog, dat kan zelfs in UML. Maar dat is GEEN klassediagram.

[Verwijderd]

Ok maar wat is DAT dan wel volgens jou?

[Pooh]

Types of UML Diagrams
UML defines nine types of diagrams: class (package), object, use case, sequence, collaboration, statechart, activity, component, and deployment.

Eerste hit, google: "uml diagrams"

[kasper_vk]

UML beschijft geen werkwijze, maar alleen een taal. Of jij met (onderdelen uit) die taal een techinsch of functioneel aspect wil beschrijven is, zoals CubicQ al een beetje zegt, jouw keuze omdat de semiantiek geen deel uitmaakt van UML.

Verder denk ik dat op het klassemodel niet de vraag "Funcioneel of technisch?", maar de vraag "Domein of implementatie (/ technisch) ?" van toepassing is.

[Verwijderd]

klopt helemaal kasper... die conclusie kon ik er idd uit trekken.

Mijn vraag is dan:
wanneer ik in een klassendiagram de classes als bedrijfsobjecten zie en de methodes als activiteiten (onderdeel van de elementaire processen) die op deze bedrijfsobjecten van toepassing zijn, is dit dan een technisch(implementatie)diagram of een functioneel(domein)diagram?

Mijn gevoel zegt functioneel, maar deze activiteiten komen ook in de implementatie terug natuurlijk

[ Voor 5% gewijzigd door Verwijderd op 17-09-2003 13:05 ]

[kasper_vk]

Volgens mij heb je dan inderdaad een domeinmodel.

Al zul je moeten uitkijken om activiteiten uit bedrijftcritische processen direct als method op te nemen; meestal betreffen het dan use cases i.p.v. methods.

Vanaf de use cases ga je dan m.b.v. enkele sequence-(of collaboratie-) diagrammen uiteenzetten hoe die activiteiten worden uitgevoerd door de domeinklassen. Zodra je dat helemaal hebt uitgewerkt bevindt je klassendiagram zich in mindere mate in het 'domeinstadium' en al veel meer in het 'implementatiestadium'.

[ Voor 4% gewijzigd door kasper_vk op 17-09-2003 13:14 ]

[Soultaker]

Maar mijn idee is de UML niet alleen een taal, maar ook een methode. Als "taal" zegt het namelijk niet zoveel, aangezien het dan simpelweg een samenraapsel van notatietechnieken is, die al veel eerder (ergens anders) bedacht waren. Naar mijn idee is dus wel relevant dat de UML een geintegreerde ("unified") aanpak voorschrijft (of tenminste aanraadt).

Een klassendiagram beschrijft de statische structuur van het systeem dat je aan het ontwerpen bent. Naar mijn idee is zo'n beschrijving niet functioneel; je beschrijft uitsluitend de bestaande of gewenste entiteiten en hun eigenschappen en relaties, maar niet hoe deze entiteiten in de prakijk samenwerken om een doel te bereiken. Deze conclusie leunt natuurlijk sterk op de gebruikte definitie van "functie", maar naar mijn idee is de "functie" van een systeem datgene wat het systeem bewerkstelligd in de omgeving.

Verder kan het klassendiagram technisch zijn, wanneer het de structuur van het feitelijke systeem modelleert, of niet-technisch, wanneer je er de structuur van de omgeving mee modelleert. Een klassendiagram is redelijk formeel en lijkt me dus vooral nuttig voor het eerste doel: voornamelijk technisch dus.

[kasper_vk]

Soultaker schreef op 17 September 2003 @ 13:30:
Maar mijn idee is de UML niet alleen een taal, maar ook een methode. Als "taal" zegt het namelijk niet zoveel, aangezien het dan simpelweg een samenraapsel van notatietechnieken is, die al veel eerder (ergens anders) bedacht waren. Naar mijn idee is dus wel relevant dat de UML een geintegreerde ("unified") aanpak voorschrijft (of tenminste aanraadt).

Uiteraard heb je niets aan een taal zonder werkwijze; UML schrijft er inderdaad ook een voor, maar die maakt geen onderdeel uit van de formele specificatie van UML. Op die manier is de taal nog steeds 100% gescheiden van de manier waarop je het systeem ontwikkeld; zelfs de taal voor het weergeven van OO ontwerpen is ontwikkeld voor duurzaamheid en hergebruik....

Soultaker schreef op 17 September 2003 @ 13:30:
Een klassendiagram ... ... omgeving.

Mee eens.

Volgens mij komt eventuele verwarring in deze discussie voort uit het feit dat de scheiding Functioneel / Technisch niet meer in die vorm van toepassing is bij OOA / OOD. Natuurlijk wil je functionele zaken weten, anders ben je snel uitontwikkeld ; dus die functionele zaken komen in andere vormen terug.

Het technische aspect begint (bij nader inzien) eigelijk inderdaad al zodra de eerste klasse aan het schematiseren bent, omdat die klasse in je implementatie letterlijk terugkomt.

[guanpedro]

Unified Modelling Language zelf is een taal, hoe je UML gebruikt is een werkwijze. Zoals Rational UML in rup gebruikt als onderdeel van de ontwikkelmethode.

Of het technisch of functioneel is hangt af voor welk doeleinde je het model gaat gebruiken. Is het om je projectmanager te overtuigen van de tijd van een project dan is het functioneel. Ga je het gebruiken om c# code mee te genereren dan is het technisch.