Microsoft: 'Uml gaat niet ver genoeg'

Software-ontwikkelaars zijn vragende partij voor een eenvoudiger manier om applicaties te ontwikkelen. Microsoft werkt daarom momenteel hard aan een verbetering van het object-georiënteerde uml.

Volgens analisten kunnen ontwikkelaars veel tijd winnen door gebruik te maken van object-georiënteerde programmeertechnieken tijdens het bouwen van applicaties. Toch meent Microsoft dat de flexibiliteit en de mogelijkheden van de huidige uml-benadering nog te beperkt zijn, ondanks het feit dat de modelleringstaal momenteel furore maakt in met name financiële-softwareontwikkeling. Een groot nadeel van het ontwikkelen met object-georiënteerde oplossingen zou zijn dat er heel wat tijd geïnvesteerd moet worden in het uitbouwen van het framework, zonder dat daarbij direct resultaat zichtbaar is. De softwaregigant zegt daarom hard te werken aan een meer 'fabrieksmatige' aanpak onder de codenaam Software Factories.

Met de eigen modelleringstechnologie moet programmeren vergelijkbaar worden met de productielijn in een fabrieksomgeving: snel samenvoegen van losse onderdelen tot één geheel. Microsoft is overigens niet het enige bedrijf dat in die richting denkt: softwarebedrijf CA heeft namelijk zijn CA Plex r6-ontwikkelplatform op de markt gezet, dat vergelijkbare doelstellingen nastreeft. Doel van beide is om het ontwikkeltraject te verkorten, onder meer door efficiënter gebruik te maken van kant-en-klare object-georiënteerde frameworks. Met behulp van een rapid application development environment zouden .Net- en Java 2-ontwikkelaars hun werk flink kunnen versnellen. Volgens Microsoft zullen de eerste resultaten van zijn krachtinspanning, in de vorm van een prototype van de ontwikkelomgeving, binnen een jaar zichtbaar worden. Het bedrijf heeft daarvoor Don Box en Chris Anderson, beiden betrokken bij de ontwikkeling van .Net Framework 3.0, ingezet om zich binnen de Developer Division bezig te houden met de ontwikkeling van de nieuwe modelleringstechnologie.

Reacties (58)

[Verwijderd]

UML is wel degelijk ontwikkeld als 'echte' taal. Er zijn al genoeg tools die round trip
engineering van UML naar object georienteerde talen doen. Ik ben alleen
nog geen enkele tool tegengekomen die daadwerkelijk de productiviteit ten goede komt.
Het is soms handig voor overzicht, maar of je nou met UML of bijv. java iets ontwikkeld, de
code moet nog altijd geschreven worden. Of dat nou in UML of een OO taal wordt gedaan .
UML is enigzins visueler, maar ik vraag me af of een volledige implementatie visueel
beter is te overzien in UML dan in code. Makkelijker wordt het niet, aangezien het geen
nieuwe abstractie toevoegt.

Anywats I'm not impressed.

[Verwijderd]

Hangt ervan af wat je met 'taal' bedoeld. UML is een taal om te modeleren, geen taal om te programmeren. De round trip engineering die in veel UML tools zit zal dan ook enkel maar het model van je systeem vertalen naar code, het echte werk zal je toch nog zelf moeten doen.

[Joost]

Betekent dit ook dat applicaties gemakkelijker overgezet kunnen worden naar andere besturingssystemen? Ik bedoel, een java-applicatie draait op elk systeem waarvoor Java beschikbaar is. Geld dat ook voor Uml en "software factories"? (Ik kan me niet voorstellen dat Microsoft actief zou meewerken aan betere ondersteuning van OSX en Linux.

[YaPP]

Betekent dit ook dat applicaties gemakkelijker overgezet kunnen worden naar andere besturingssystemen?

UML wordt gebruikt als notatiewijze om een software ontwerp uit te schrijven. Je beschrijft de componenten (class-diagram), de interactie en de gebruikersacties (use-case diagram). Dat kan allemaal op papier, of met speciale tekentools.

Die tool kunnen vervolgens wel het geraamte van je software automatisch genereren, maar dat zijn niets meer dan lege functies en aangmaakte variabelen. Het heeft echter allemaal weinig te maken met het schrijven van cross-platform applicaties.

[JeroenB]

Zo is het ooit begonnen. De afgelopen jaren is er veel ontwikkeling gestoken in MDA: Model-Driven Architecture. Deze methode heeft als doelstelling om UML modellen via platform-onafhankelijke en platform-specifieke transformatieslagen om te zetten in compleet werkende softwaresystemen.

Het probleem hierbij is echter dat UML daar volstrekt niet toereikend voor is. Als je kijkt naar de typische verdeling van software in drie lagen: presentatie, logica en opslag, dan is UML eigenlijk alleen geschikt om logica te modelleren en zelfs daar kun je lang niet alles uitdrukken (OCL is lang niet zo uitgebreid dat je alles erin kunt uitdrukken).

Je hebt dus helemaal gelijk dat UML er niet geschikt voor is, maar de vraag van GWX was echter wel terecht: OMG heeft er tenslotte flink wat moeite in gestopt om te proberen het te realiseren. Microsoft wijkt hier dus ook terecht van af, MDA zal waarschijnlijk nooit gaan werken.

[Verwijderd]

In principe is UML gewoon platform onafhankelijk, want het is een ontwerp en geen implementatie (de abstracte blauwdruk zeg maar). Een UML ontwerp kan dus in meerdere talen of platform (binnen de limieten van de taal) worden gerealiseerd.
Hoe dat met 'software factories' komt is speculeren, maar aangezien het een modeleer principe met RAD in het echterhoofd wordt zal het ongetwijfeld ook toepasbaar zijn voor ander platformen (afhankelijk van het framework).
De vraag is echter of er sprake is van toegevoegde waarde, ik ben namelijk erg benieuwd naar de 'revolutionaire' aanpak die alles makkelijker moet gaan maken.

[Verwijderd]

Betekent dit ook dat applicaties gemakkelijker overgezet kunnen worden naar andere besturingssystemen?

Is runs on every system as long as its a windows system.

[masteriiz]

UML is een modeleertaal, dus 'draait' helemaal nergens op. Welbeschouwd gaat het eerder om een nieuwe benadering van je programmeeromgeving, en handelt het in het geheel niet over de vraag waar iets wel of niet op zou moeten kunnen draaien.

[JeroenB]

De link met UML zit hem in dit onderdeel van de Microsoft aanpak mbt. Software Factories: Domain-Specific Language (DSL) tools. Dit is een toolkit om een custom UML-achtige taal te maken waarin bijv. domainexperts (en dus niet noodzakelijkerwijs programmeurs, maar die kunnen het ook gebruiken voor productiviteitsverhoging, zo is het idee) software kunnen ontwikkelen.

De taal is dan op maat gemaakt voor het domein waarin software wordt gemaakt. Dus een financiele expert kan dan ipv. met objecten en strings werken met polissen en consumenten (even heel kort door de ebocht gesteld )

[Reactie gewijzigd door JeroenB op 22 juli 2024 14:22]

[Killemov]

@masteriiz, @YaPP:
Als je de modellering goed en heel ver doorvoert, dan kun je theoretisch wel degelijk je UML-model draaien. Java kan bijvoorbeeld heel goed gebruikt worden om uit het model code on-the-fly te genereren. Je moet dan wel bereid zijn om heel veel zaken uit handen te geven, waaronder GUI-ontwerp en, wat minder interessant, database ontwerp.

[m0nkey]

Voor zover ik weet is UML een 'taal' zonder echte regels (meer richtijnen, parlaver anyone? ) om de werking/opbouw/functie van een programma in detail te tonen zodat er over gediscusseerd kan worden om bijvoorbeeld verbeterings voorstellen te doen. Sinds wanneer is het een 'echte' taal geworden die volgens regels en dergelijk te werk gaat?

[masteriiz]

UML is een modeleertaal die wel degelijk regels bevat. Binnen UML onderscheid men bijvoorbeeld technieken als Use-Cases, maar ook het welbekende class-diagram is onderdeel van UML. Hier is vast wel wat over te googelen.

[JeroenB]

Die regels kunnen worden uitgedrukt in de zogenaamde Object Constraint Language (OCL). In de praktijk is deze ook niet zo universeel dat je niet meer hoeft te programmeren, maar het idee is er.

[Verwijderd]

UML is sinds versie 2.0 een formele taal. Eerdere versies waren informeel, hoewel sommige onderdelen wel degelijk formeel waren.

Er zijn behoorlijk wat regels, maar vaak hoeven die niet allemaal strikt nageleeft te worden. Om bijvoorbeeld een snel inzicht te krijgen in een aantal klassen, maar ik vaak genoeg schetsjes op papier waarbij ik echt niet alle regels naleef. Als ik echter een programma verder design in een CASE-tool, dan moet het heel wat formeler.

[Jogai]

Misschien willen ze het meer aan banden leggen zodat code makkelijker en beter gegenereerd wordt. Het schuift dan steeds meer door naar een taal, dat klopt.

[iceheart]

wat ik me dan afvraag: levert dit geen gigantische overhead op?

disclaimert: niet bedoeld als fipo, maar om nou speciaal daarom te wachten met posten...

[MisterBlue]

Dat is juist de kritiek die microsoft heeft op het huidige UML.

However, Microsoft sees UML and its ilk as too hard and too heavy a process, and is working on delivering its own modeling technology.

[the_stickie]

Ik denk het wel: in plaats van zelf bepaalde dingen te gaan schrijven, val je terug op standaard objecten en modules die waarschijnlijk een stuk meer functionaiteit bieden dan nodig voor je project.
Natuurlijk is de vraag hoe efficiënt de "standaard" modules zijn en nog belangrijker: hoe de compiler omgaat met de componenten. Het zou bijvoorbeeld best kunnen dat de IDE die MS voorstelt stukken niet meecompileert als deze niet gebruikt worden.
Anyway is meer info (overhead? Duidelijk structuren, commentaar, uitgebreide bibliotheken) in design-time echt wel goed.
Alleen in runtime is dat allemaal "overbodig"; dus het hangt werkelijk allemaal van de compiler af. Bovendien zijn huidige computers meer dan krachtig genoehg om voor "standaard" programma's enkele procenten aan efficiêntie in te boeten om het programmeren vlotter/makkelijekr te maken ( * the_stickie loopt snel weg voor de hardcoredevvers dit lezen )

[Verwijderd]

Bovendien zijn huidige computers meer dan krachtig genoehg om voor "standaard" programma's enkele procenten aan efficiêntie in te boeten om het programmeren vlotter/makkelijekr te maken

En door die redanatie presteren de computers van nu nog steeds niet meer dan jaren geleden. Alle winst die behaald is met CPU's en geheugen is opgegaan aan het wilde verbruik ervan van programmeurs onder het motto we hebben er genoeg van.

[Skelt0r]

Dat is toch juist de bedoeling van de extra rekenkracht, dat je er meer mee kunt?!?! Hardware is relatief goedkoop in vergelijking met uren van een programmeur... Hieruit kun je makkelijk concluderen dat ze liever resources stoppen in extra (of nieuwere) hardware en zulke platformen dan in 'onnodig' programmeren!

[iceheart]

hmmm, als ik een paar honderd euro neertel voor een officepakket (waarvan de codebase IMO voor 80% overgenomen wordt van de vorige versie) verwacht ik toch dat men op z'n minst fatsoenlijk heeft geoptimaliseerd, en dat zal hiermee nog wel minder het geval zijn.

[Skelt0r]

waarvan de codebase IMO voor 80% overgenomen wordt van de vorige versie

verwacht ik toch dat men op z'n minst fatsoenlijk heeft geoptimaliseerd

Je geeft hier zelf al aan dat dat (helaas) niet altijd het geval is... Optimalisatie wordt vaak niet nodig geacht door de verhoogde rekencapaciteit van computers.
Het gaat er met dit framework om hoe het geimplementeerd wordt. Een framework in niet per definitie log, maar Microsoft kennende...

[MadEgg]

Maar overdrijven is ook een vak. Je zou een groot deel van de programma's van vandaag de dag in principe ook prima kunnen laten draaien op een Pentium I 200 MHz, mits je de tijd neemt om het goed te optimaliseren en geen overbodige code mee te compileren. Dit is wat mij betreft wel een beetje té, maar veel programma's hebben echt achterlijk hoge systeemeisen voor wat ze doen, en dat is pure luiheid van de programmeur. Een Pentium III 450 zou nog prima geschikt horen te zijn en dat is echt niet het geval. Gewoon verkwisting.

Op zich ben ik natuurlijk wel voor standaard libraries, als iedere programmeur 'het wiel opnieuw moet uitvinden' op zijn specifieke manier, dan krijg je wel snellere programma's maar een gevolg is ook dat er véél meer kans is op bugs in allerlei programma's, terwijl als elk programma dezelfde code gebruikt, dan wordt deze code veel intensiever getest en verbeterd een bugfix gelijk vele programma's. Maar dat ontneemt je nog niet gelijk de mogelijkheid om te optimaliseren.

[SKiLLa]

Dat mag dan economisch gezien wel wenselijk zijn (puntje voor Skelt0r), puur technisch gezien is het wel onwenselijk (puntje voor BillGaetes). Het blijft gewoon altijd een afweging, managers hebben andere priotiteiten dan techneuten of consumenten. En natuurlijk hangt het ook van het type software af; een 3D engine moet gewoon snel zijn, terwijl b.v. een backoffice app (vaak) gewoon 'goedkoop' moet zijn ...

[doskabouter]

Ja, maar de uren van de programmeur betaal je maar 1 keer, die van de hardware voor betaal je wel wat vaker..

[Jogai]

Als je vervolgens meer code beter kan genereren is dat het wel waard.

[Verwijderd]

Het hoeft uiteraard geen overhead op te leveren. Het kan zelfs snelheid opleveren.

Goed modeleren / ontwerpen zorgt ervoor dat je geen dubbele code schrijft maar ook kan het rekenkracht schelen.

Tevens hangt er vaak een code generator onder de modeleertools die ervoor zorgt dat de structuur ook daadwerkelijk gegenereerd wordt in de taal van je keuze.

MS wil denk ik meer dat mensen gebruik gaan maken van bestaande objecten dan dat ze ze zelf gaan schrijven. Vandaar ook het "efficienter omgaan met bestaande frameworks" zin.

m.a.w. De overhead ligt niet bij de modelleertools, die modelleren alleen maar. Vaak ligt het aan de keuze van je objecten en architectuur.
Bijvoorbeeld de keuze van je queries. Als je in .NET alleen maar gebruik maakt van datasets dan ben je waarschijnlijk niet goed bezig. Dat is qua modelering waarschijnlijk een trage en niet altijd een goede keuze. Aangezien een dataset ook niet ontworpen is voor iedere toepassing.
De essentie van het probleem is dat veel programeurs niet verder kijken dan hun neus lang is en een object niet goed bestuderen voor ze hem toepassen.

(tevens ook de reden waarom een goede software architect zoveel kan verdienen. Veel kennis nodig van systemen en objecten en programmeren)

Overigens denk ik niet dat dit echt gaat helpen. Zou het wel handig vinden als de tools verbeteren om objecten te vinden en te onderzoeken zoals MSDN. Minder crap en meer toe de point.

[Auredium]

Ik had zelf al deze stap voorzien. De toekomst van programmeren is met behulp van legoblokjes waarin je zelf alleen de variabelen e.d. hoeft aan te geven.
Talen zoals C++ en Pascal verdwijnen naar de achtergrond waar ze nauwelijk meer hoeven te worden bewerkt door programmeurs en zullen wellicht op den duur helemaal verdwijnen. Ik heb zelf op HBO C++ tot in de treuren moeten leren en het is gewoon een te complexe en onpractische taal. Vooral heden ten dage moet het goed mogelijk zijn met programmeerblokken te werken ipv alles individueel typen.

Die ontwikkeling is onvermijdelijk en zal menig programmeur veel (financiele) kopzorgen gaan geven in de nabije toekomst. Programmeren zal met behulp van blokkken makkelijker worden en niet noodzakelijkerwijs meer een HBO/TU opleiding zijn (goed, MBO en lager bestaat ook momenteel, maar voor het 'echte werk' is momenteel een hbo/TU opleiding nodig).

Deze ontwikkeling is logisch, want programmeren bestaat weliswaar zeer lang (denk aan ponskaartjes/draaiorgels), maar het is gewoon nog niet uit de testfase gegroeit. Er komen steeds meer 'bouwblok' talen en ze zullen alleen nog maar toenemen.

[TaXaN]

John Ousterhout, uitvinder van Tcl, heeft hier een tiental jaar geleden al een paper over geschreven: http://home.pacbell.net/ouster/scripting.html
Een beetje gedateerd maar het toont aan dat er op tien jaar nog niet zo veel veranderd is. Zoals hyriand al zegt: wie maakt de blokken? En het operating system?

[hyriand]

Ok... Maar ehm... Wie maakt de blokken? En hoe maak je nieuwe blokken?

Het is praktisch onmogelijk om alle aspecten van applicatieontwikkeling van te voren vast te leggen in hapklare blokjes. Voor logische processen en algorithmen is het misschien wel mogelijk, maar voor veel dingen is het gewoon niet haalbaar.

Kijk bijvoorbeeld naar HyperCard, je kon er heel veel mee maar er was ook heel veel wat niet kon.

[Reactie gewijzigd door hyriand op 22 juli 2024 14:22]

[Auredium]

Was dit dan neit zo met de eerste programmeertalen?
Tuurlijk wel.

Je krijgt gewoon blokken die inhouden:

if({invulbaar])
{
[meer blokken]
}
else if ([invulbaar]
{
[meer blokken]
}

blokken in blokken in blokken waarbij de gebruiker alleen nog maar dom de stellingen hoeft in te vullen.

[dsdevries]

dit zou echt een uitkomst zijn! Dat uml komt me zo langzamerhand de strot uit! Vooral die vage grenzen in hoever je moet gaan detailleren in uml zijn super irritant als je snel software moet opleveren. je kunt namelijk wel het hele pakket uitwerken in uml maar dan ben je al gauw maanden aan het modelleren zonder nog maar 1 regel gecodeerd te hebben. En feit is ook dat je tijdens coderen altijd wel weer fouten tegenkomt in het ontwerp of onderdelen die op papier eenvoudig te realiseren leken maar in de praktijk niet te doen blijken te zijn met als gevolg dat er tijdens het coderen bijna nooit meer naar het ontwerp gekeken word.

echt een waste of time in de meeste gevallen!

[Verwijderd]

Dat is niet het probleem van UML. UML geeft je gewoon de mogelijkheid om verschillende aspekten van je systeem te modeleren, wat je juist gaat modeleren en in welk detail hangt af van jezelf en de methodologie die je gebruikt.

[Verwijderd]

True, soms is het makkelijker om het maar gewoon te programmeren. In een essay uit begin jaren '90 las ik eens dat het succes van C++ te danken was aan het feit dat OO code 'zelf documenterend' was. Wat ik handig vind in Visual Studio (kan ook in andere IDE's denk ik) is om zo nu en dan vanuit de code een Class Diagram te generen voor de documentatie i.p.v. andersom. OO code is dus in zekere zin ook de documentatie, zeker als je je commentaar goed bijhoudt.

[Verwijderd]

Ruikt verdacht veel naar een of ander 4GL taal, met alle voor en nadelen die daar aan vast zitten.

[Verwijderd]

Ben ik nou de enige die dit verhaal van MS meer zie als een voorbereiding zodat MS weer zijn eigen 'standaarden' en producten er doorheen kan drukken ??

[mOrPhie]

In dit geval niet. Software Factories zijn namelijk een denkwijze die hand in hand gaat met UML.

[Dreamvoid]

M$ steunt gewoon hun grootste groep klanten in het idee dat ze niet hoeven nadenken en alles voor hen gedaan wordt.

Er wordt bij die klanten genoeg nagedacht, ze willen alleen niet voor elke beetje andere applicatie compleet nieuwe code laten schrijven en jarenlang blijven debuggen. Het developersgilde ziet dat natuurlijk wel zitten (een hele app van top tot teen zelf bedenken is interessant, en een steady stroom van inkomsten van het debuggen, hoera!), maar de klant draait uiteindelijk wel voor de kosten op en zit weer eens met een custom app waar elk radertje en moertje net weer anders is dan bij alle andere apps.

Er zijn veel klanten, met name in de financiele sector, waarbij er van een applicatie geen revolutionaire dingen gevraagd worden, maar er 1 ding geldt: hoe snel kan je het bouwen met kwalitatief robuuste code? Robuuste code krijg je door veel generieke objecten te gebruiken (oftewel: hergebruikte, bewezen, debugged code ipv elke keer het wiel uitvinden en debuggen), en met UML-achtige suites kan je ook de verbanden tussen de objecten automatiseren (en daardoor de eeuwige menselijke programmeerfouten voorkomen). Je centraliseert het probleem dus naar het debuggen van de RAD-suite ipv het moeten debuggen van elke individuele applicatie.

Binnen de grenzen van de "simpele wereld" van een applicatie had je overigens dat soort dingen al, ik heb jarenlang met veel plezier gewerkt met Simulink (automatische code generen via flowcharts in MATLAB).

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 14:22]

[P_de_B]

M$ steunt gewoon hun grootste groep klanten in het idee dat ze niet hoeven nadenken en alles voor hen gedaan wordt. Lekker met VBA wat in elkaar flansen en je dan software engineer noemen. Ik haat die RAD terminologie en dat popie quick en dirty gezwam. Het zorgt gewoon voor bergen ongedocumenteerde code die niet te onderhouden is.

Heb je ook onderbouwing voor deze flame, of praat je gewoon anderen na? Microsoft heeft met .Net/Visual Studio/SQL Server absoluut een volwassen ontwikkelplatform neergezet.

[humbug]

Sorry hoor, maar er zijn heel veel mensen die met microsoft producten goede gestructureerde code kunnen schrijven. Tegelijkertijd zijn er ook heel veel die in J2EE werken en er absoluut een zooitje van maken. De taal en softwareleverancier staat los van de kwaliteit van de ontwikkelaars maar als je dan wil generaliseren kun je de meeste flansers tegenwoordig vinden op het lamp platform. PHP en mySQL hebben ondertussen de fakkel wat dat betreft ruimschoots overgenomen van de combinatie VB en Access.

Dus ga daar maar over klagen. O, nee. Dat zijn je Linux vriendjes......

[H!GHGuY]

UML 2.0 ondersteuning toevoegen aan Visio zou misschien al meteen een goede stap in die richting zijn.
Ik gebruik ondertussen het gratis beschikbare StarUML ipv Visio aangezien Visio zich beperkt tot (imo gebrekkig geimplementeerd) UML 1.0.

Ik vraag me af hoe toepasbaar dit zal zijn? Het zou me niet verwonderen dat je het enkel kan gebruiken als je een 13-in-een-dozijn business applicatie schrijft en niet wanneer je met andere types applicaties bezig bent (bvb embedded/game/... development of zelfs een programma als bvb winrar)

[mulder]

Games en tooltjes zijn hier 123 niet geschikt voor nee. Maar voor 'kantoor' applicaties is dit uitermate geschikt, het neemt je een heleboel klop werk uithanden. Je kunt hier mee het hele fundament van je applicatie mee neerleggen. Je kunt je adhv van je cases, modellen en diagrammen de business logica, business rules, autorisatie, workflow, etc etc voor je framework laten genereren.