Softwaroví vývojáři se často učí o programování UML na vysoké škole.
Kredit obrázku: Stockbyte/Stockbyte/Getty Images
Unified Modeling Language (UML) je softwarový modelovací jazyk s důrazem na grafiku a pohyb. Podle Sparx Systems je to průmyslový standardní jazyk pro softwarové modelování a návrh. Někteří vývojáři a společnosti zabývající se návrhem softwaru však mohou mít problémy s používáním UML. Nevýhody používání UML zahrnují přidávání úkolů do rozsahu práce projektu a přílišné spoléhání se na diagramy UML.
Čas
Jednou nevýhodou, kterou mohou někteří vývojáři najít při používání UML, je čas, který zabere správa a údržba diagramů UML. Aby správně fungovaly, musí být diagramy UML synchronizovány se softwarovým kódem, což vyžaduje čas na nastavení a údržbu a přidává práci na projektu vývoje softwaru. Malé společnosti a nezávislí vývojáři nemusí být schopni zvládnout dodatečné množství práce potřebné k synchronizaci kódu.
Video dne
Není jasné, kdo má prospěch
Není vždy jasné, kdo těží z diagramu UML. Podle článku zveřejněného na webu Eiffel Software není UML pro vývojáře softwaru výhodné, hlavně proto, že vývojáři softwaru pracují s kódem, nikoli s obrázky nebo diagramy. Diagramy UML mohou být přínosné pro projektové manažery nebo vedoucí pracovníky, aby ilustrovaly, jak bude softwarový nástroj fungovat, ale je to tak může být jednodušší nakreslit diagram na tabuli nebo kus papíru, než věnovat čas učení UML Jazyk.
Diagramy mohou být ohromující
Při vytváření diagramu UML ve spojení s vývojem softwaru může být diagram zahlcující nebo příliš komplikovaný, což může být pro vývojáře matoucí a frustrující. Vývojáři nemohou v diagramu zmapovat každý jednotlivý scénář pro softwarový nástroj, a i když se o to pokoušejí, diagram je zmatený. Jedním ze způsobů, jak mohou vývojáři s tímto problémem bojovat, je zahrnout do něj pouze základní fakta a informace na vysoké úrovni UML diagramy, podle příspěvku na Stack Overflow od Stefana Boriniho, kvantového chemika a UML vývojář.
Příliš velký důraz na design
UML klade velký důraz na design, což může být pro některé vývojáře a společnosti problematické. Pohled na rozsah softwaru v diagramu UML může vést k nadměrné analýze zúčastněných stran softwarového projektu problémy a také způsobí, že lidé ztratí pozornost tím, že tráví příliš mnoho času a pozornosti softwaru funkce. Společnosti nemohou vyřešit každý problém pomocí softwarového nástroje pomocí diagramu UML - nakonec musí začít kódovat a testovat. Brody Gooch, spolutvůrce UML, řekl, že původní vizí UML byl „grafický jazyk, který má pomoci uvažovat o návrhu systému jako rozvine se." Pokud se lidé zavěsí pomocí diagramu k identifikaci a vyřešení problémů, může to zpozdit skutečnou práci, kterou je třeba udělat k vyřešení problému. problémy.
