Unified Modeling Language ( UML ) er en software modellering sprog med vægt på grafik og bevægelse . Det er branchens standard sproget for software modellering og design , ifølge Sparx Systems . Dog kan nogle udviklere og software design virksomheder oplever problemer med at bruge UML . Ulemper ved at bruge UML inkluderer at tilføje opgaver til et projekt arbejde omfang og stole på UML diagrammer for tungt . Time
En ulempe nogle udviklere kan finde , når du bruger UML er den tid , det tager at administrere og vedligeholde UML-diagrammer . At arbejde ordentligt, skal UML diagrammer være synkroniseret med den software kode, som kræver tid at sætte op og vedligeholde , og tilføjer arbejde til en software- udviklingsprojekt. Små virksomheder og selvstændige udviklere måske ikke være i stand til at håndtere den ekstra mængde arbejde, der kræves for at synkronisere koden .
Uklar Hvem Fordele
Det er ikke altid klart, hvem fordele fra en UML diagram . Ifølge en artikel offentliggjort på Eiffel Software website , er UML ikke fordelagtigt at softwareudviklere , primært fordi software- udviklere arbejder med kode , ikke billeder eller diagrammer . UML-diagrammer kan være gavnligt for projektledere eller ledere til at illustrere , hvordan en software-værktøj vil arbejde, men det kan være lettere at trække diagrammet ud på en tavle eller et stykke papir , snarere end at tage sig tid til at lære UML sprog. < Br >
Diagrammer kan få overvældende
Når du opretter et UML diagram i forbindelse med softwareudvikling , kan diagrammet bliver overvældende eller kompliceret , som kan være forvirrende og frustrerende for udviklere . Udviklere kan umuligt kortlægge hver eneste scenario for et software-værktøj i diagrammet , og selv hvis de forsøger at , diagrammet bliver rodet. En måde udviklere kan bekæmpe dette problem er kun at omfatte grundlæggende fakta og højt niveau information i UML-diagrammer , ifølge et indlæg på Stack Overflow af Stefano Borini , en kvante kemiker og UML -udvikler.
Too meget vægt på design
UML lægger meget vægt på design, som kan være problematisk for nogle udviklere og virksomheder. Ser man på en software- rækkevidde i et UML -diagram kan føre til software projektets interessenter over- analysere problemer , samt få folk til at miste fokus ved at bruge for meget tid og opmærksomhed på software features . Virksomheder kan ikke løse alle problemer med et software-værktøj ved hjælp af en UML diagram - i sidste ende , de bare nødt til at begynde kodning og test . Brody Gooch , en co- skaberen af UML , sagde, at den oprindelige vision for UML var en " grafisk sprog til at hjælpe årsagen om udformningen af et system , som det udfolder sig. " Hvis folk bliver hængt op ved hjælp af et diagram til at identificere og løse spørgsmål, kan det forsinke det faktiske arbejde , der skal gøres for at løse problemerne.
