Унифициран јазик за моделирање

Унифициран јазик за моделирање или UML (анг. Unified Modeling Language) е стандарден јазик од областа софтверско инженерство, за визуелно претставување и моделирање на објекти. UML е општ јазик за моделирање кој преку графички симболи прави апстрактен модел на системот познат како UML модел. UML стандардот е создаден во 1997 година од страна на Object Management Group (OMG) и од тогаш станува индустриски стандард за моделирање на софтвер-интензивни системи.

UML logo

Колаж од UML дијаграми.

Преглед

UML се користи за одредување, визуализација, менување, изградба и документирање на предметите од објектно-ориентиран софтверско-интензивен систем под изградба. UML нуди стандарден начин за визуализација на архитектонски шематски планови од еден систем, вклучувајќи елементи како што се:

• Активности
• Актори
• Бизнис процеси
• Шеми од база на податоци
• (Логички) компоненти
• Извештаи од програмски јазик
• Повторно-употребливи софтверски компоненти

UML комбинира техники од моделирање на податоци, бизнис моделирање, објектно моделирање и компонентно моделирање. Може да биде користено со сите процеси, во текот на животниот век на софтверскиот развој и низ различна имплементација на технологии. UML првично беше изведен од јазиците за објектно моделирање од три водечки методи за објектно-ориентирање: Booch, техника за објектно моделирање (OMT) и објектно-ориентирано софтверско инженерство (OOSE).UML сега ги користи сите три методи коишто се споени во еден заеднички и широко употреблив јазик за моделирање.

UML моделите можат да бидат автоматски трансформирани во други репрезентации (на пример Java) по пат на QVT (Пребарување/Преглед/Трансформација, анг. Query/View/Transformation) трансформациски јазик. UML е растеглив, со три механизми за прилагодување: стереотипи, обележани вредност и огрничувања.

Историја

Во доцните '80-ти имало многу различни методи и секоја имала своја сопствена нотација. Проблемот било тоа што кога различни луѓе користеле различни нотации, тие морале да ги преведат нотациите од една во друга. Многупати, еден симбол значел едно во една нотација а во друга нотација друго. Во 1991 година, почнало да се пишуваат многу книги за UML. Grady Booch создал свој Booch метод, Jim Rumbaugh создал свој OMT (Object-modeling technique) метод и Ivar Jacobson создал свој OOSE (Object-oriented software engineering) метод. Секоја книга имала свои предности како и свои недостатоци. Booch методот бил добар во дизајн, но слаб во анализа; OMT методот бил многу добар во анализа, но бил слаб во дизајн, додека пак OOSE методот бил многу добар во искуството со корисниците – нешто што ниту Booch методот ниту OMT методот не го зеле предвид. Во 1994 година, Grady Booch и Jim Rumbaugh официјално ги соединиле своите сили за да создаваат стандардна нотација. Една година подоцна, тие го објавиле унифицираниот метод верзија 0.8 (анг. Unified method 0.8). Подоцна, Ivar Jacobson се придружил на тимот и сите тројца биле наречени тројцата пријатели (three amigos) помеѓу објектно-ориентираните кругови. Во 1996 година, Rational заклучи дека изобилството на јазиците за моделирање го забавувала усвојувањето на објект-технологијата, и ги задолжила тројцата пријатели за развој на не-комерцијален UML јазик. Во јануари, 1997 година UML 1.0 беше предложен на OMG. Истиот месец, UML партнерите формараат Semantic Task Force, со кој претседавал Cris Kobryn и администриран од страна на Ed Eykholt, за да ја завршат семантиката на спецификација и да ја интегрираат со други напори за стандардизација. Резултатот на ова дело, UML 1.1, беше доставен до OMG во август, 1997 година и усвоен од страна на OMG во ноември истата година. Во 2005 година, OMG го усвои UML 2.0, каде што се поправени недостатоци и грешки од претходните верзии (UML 1.3, 1.4 и 1.5). Иако UML 2.1 никогаш не беше издаден формално, во 2007 се појавија две верзии: 2.1.1 и v2.1.2, проследени со UML 2.2 во февруари 2009 година. UML 2.3 официјално беше издаден во мај, 2010 година. UML 2.4.1 беше официјално издаден во август 2011 година.

UML дијаграми

Во самиот стандард постојат девет типови на дијаграми, кои според нивните одлики можат да се поделат во три групи:

• Статични:
  • Дијаграм на кориснички сценарија (анг. Use case diagram)
  • Класен дијаграм (анг. Class diagram)
• Динамички:
  • Објектен дијаграм (анг. Object diagram)
  • Состојбен дијаграм (анг. State chart diagram)
  • Дијаграм на активности (анг. Activity diagram)
  • Колаборациски дијаграм (анг. Collaboration diagram)
  • Секвенцијален дијаграм (анг. Sequence diagram)
• Имплементациони:
  • Компонентен дијаграм (анг. Component diagram)
  • Развивачки дијаграм (анг. Deployment diagram)

Дијаграм на кориснички сценарија

Дијаграмот на кориснички сценарија се употребува за идентификација на основните елементи и процеси коишто формират еден систем. Основните елементи се нарекуваат “актeри”, а процесите се нарекуваат “кориснички сценарија”. Овој дијаграм покажува кој актeр во кое корисничко сценарио дејствува.

Класен дијаграм

Класниот дијаграм се употребува за да ја прецизира употребата на дијаграмот на кориснички сценарија и да дефинира детален дизајн на системот. Класниот дијаграм ги класифицира глумците дефинирани во дијаграмот на кориснички сценарија во група од меѓусебно поврзани класи. Врската помеѓу класите може да биде “IS-A” или “HAS-A” врска. Секој класа во класниот дијаграм може да биде способна за обезбедување на одредени функционалности. Овие функционалности обезбедени од класата се нарекуваат методи на класата. Покрај тоа, секоја класа има одредени атрибути коишто уникатно ја идентификуваат класата.

Објектен дијаграм

Објектниот дијаграм е посебен вид на класен дијаграм. Еден објект е инстанца на една класа, што во суштина значи дека еден објект ја претставува состојбата на една класа во даден момент додека системот работи. Овој дијаграм ја доловува состојбата на различни класи во системот и нивните врски во дден момент од времето.

Состојбен дијаграм

Состојбениот дијаграм ги претставува различните состојби кои објектите во системот ги поднесуваат за време на нивниот животен циклус. Објектите во системот менуваат состојби во одговор на настаните. Во прилог на ова, еден состојбен дијаграм исто така ја доловува промената на состојбата на еден објект од почетна состојба во завршна состојба како одговор на настаните кои влијаат на системот.

Дијаграм на активности

Протокот на процеси во системот се опфатени во дијаграмот на активности. Слично на состојбениот дијаграм, овој дијаграм се состои од активности, акции, премини, почетна и завршна состојба и услови.

Колаборациски дијаграм

Колаборацискиот дијаграм ги групира зааедно интеракциите помеѓу различни објекти. Интеракциите се наведени како нумерирани интеракции коишто помагаат да се следи секвенцијата на интеракциите. Колаборацискиот дијаграм помага да се идентификуваат сите можни интеракции коишто се случуваат помеѓу објектите.

Секвенцијален дијаграм

Секвенцијалниот дијаграм претставува заемно дејство помеѓу различни објекти во системот. Важен аспект на секвенцијалниот дијаграм е тоа што тој е временски подреден. Ова значи дека една секвенца на интеракција помеѓу два објекти е претставена постепено. Различни објекти во дијаграмот на секвенции комуницираат едни со други со праќање на пораки.

Компонентен дијаграм

Компонентниот дијаграм ги претставува деловите коишто го сочинуваат системот коишто се на високо ниво. Овој дијаграм опишува, на високо ниво, кои компоненти формираат дел од системот и како се тие меѓусебно поврзани.

Развивачки дијаграм

Развивачкиот дијаграм ја опфаќа конфигурацијата од времетраењето на елементите во една апликација. Овој дијаграм е најкорисен кога еден изграден систем е подготвен за развивање.

Надворешни врски

• Официјална страна на UML
• UML туторијал Архивирано на 24 март 2007 г.