UML диаграма

Съдържание

 [СЃРєСЂРёР№] 

• 1 История
• 1.1 Преди UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Дизайн
• 2.1 Методи за разработване на софтуер
• 2.2 Моделиране
• 3 диаграми
• 3.1 Структурни диаграми
• 3.2 Диаграми на поведението
• 3.2.1 Диаграми на взаимодействието
• 4 Метамоделиране
• 5 Приемане
• 6 критики
• 6.1 Критика на UML 1.x

История [редактиране на източника | редактиране]

История на обектно-ориентираните методи и нотация

UML се развива от втората половина на 90-те години на миналия век и води началото си от обектно-ориентираните методи, разработени в края на 80-те и началото на 90-те години на миналия век. В хронологията (вж. изображението) са показани основните моменти от историята на обектно ориентираните методи и нотация за моделиране.

Първоначално той се основава на нотациите на метода на Бух, техниката на обектното моделиране (OMT) и обектно-ориентираното софтуерно инженерство (OOSE), които са интегрирани в един език. ^[5]

Преди UML 1.x[редактиране на източника | редактиране]

През 1994 г. Rational Software Corporation наема Джеймс Румбо от General Electric и след това компанията става източник на два от най-популярните по това време подходи за обектно-ориентирано моделиране:^[6] Румбау и метода на Грейди Бух. Скоро усилията им бяха подпомогнати от Ивар Якобсон, създател на метода на обектно-ориентираното софтуерно инженерство (OOSE), който се присъедини към тях в Rational през 1995 г. ^[1]

Под техническото ръководство на тези трима (Rumbaugh, Jacobson и Booch) през 1996 г. беше организиран консорциум, наречен UML Partners, който да завърши спецификацията на Unified Modeling Language (UML) и да я предложи на Object Management Group (OMG) за стандартизация. Партньорството включваше и други заинтересовани страни (например HP, DEC, IBM и Microsoft). Проектът UML 1.0 на партньорите по UML беше предложен на OMG през януари 1997 г. от консорциума. През същия месец партньорите по UML сформираха група, предназначена да определи точното значение на езиковите конструкции, председателствана от Крис Кобрин и администрирана от Ед Ейхолт, която да финализира спецификацията и да я интегрира с други усилия за стандартизация. Резултатът от тази работа, UML 1.1, е представен на OMG през август 1997 г. и е приет от OMG през ноември 1997 г. ^[1][7]

UML 1.x[редактиране на източника | редактиране]

След първото издание е създадена^[1] работна група за подобряване на езика, която публикува няколко малки преработки - 1.3, 1.4 и 1.5. ^[8]

Изготвените от него стандарти (както и оригиналният стандарт) са отбелязани като двусмислени и непоследователни. ^[9][10]

UML 2.x[редактиране на източника | редактиране]

Основната ревизия на UML 2.0 замени версия 1.5 през 2005 г., която беше разработена от разширен консорциум, за да се подобри допълнително езикът и да се отрази новият опит в използването на неговите функции. ^[11]

Въпреки че UML 2.1 никога не е публикуван като официална спецификация, през 2007 г. се появяват версии 2.1.1 и 2.1.2, последвани от UML 2.2 през февруари 2009 г. UML 2.3 е официално публикуван през май 2010 г.^[12] UML 2.4.1 е официално публикуван през август 2011 г.^[12] UML 2.5 беше пуснат през октомври 2012 г. като версия "В процес на разработка" и беше официално пуснат през юни 2015 г. ^[12]

Спецификацията на UML 2.x се състои от четири части:

1. Суперструктурата, която определя нотацията и семантиката на диаграмите и техните елементи на модела
2. Инфраструктурата, която определя основния метамодел, на който се основава надстройката.
3. Езикът за ограничаване на обекти (OCL) за определяне на правила за елементите на модела
4. Обменът на UML диаграми, който определя как се обменят оформленията на UML 2 диаграмите

Следват актуалните версии на тези стандарти: UML Superstructure версия 2.4.1, UML Infrastructure версия 2.4.1, OCL версия 2.3.1 и UML Diagram Interchange версия 1.0.^[13] Той продължава да се актуализира и усъвършенства от работната група за ревизия, която разрешава всички проблеми с езика. ^[14]

Дизайн[редактиране на източника | редактиране]

Унифицираният език за моделиране (UML) предлага начин за визуализиране на архитектурните проекти на системата в диаграма (вж. изображението), включваща елементи като: ^[5]

• Всякакви дейности (работни места)
• Отделни компоненти на системата
• И как те могат да взаимодействат с други софтуерни компоненти.
• Как ще работи системата
• Как единиците си взаимодействат с другите (компоненти и интерфейси)
• Външен потребителски интерфейс

Въпреки че първоначално е бил предназначен единствено за обектно-ориентирана документация за проектиране, унифицираният език за моделиране (UML) е разширен, за да обхване по-голям набор от документи за проектиране (както е посочено по-горе), ^[15]и е полезен в много контексти. ^[16]

Методи за разработване на софтуер[редактиране на източника | редактиране]

UML сам по себе си не е метод за разработка; ^[17]въпреки това той е проектиран така, че да бъде съвместим с водещите за времето си методи за разработка на обектно-ориентиран софтуер (напримерOMT, Booch method, Objectory) и особено с RUP, който първоначално е бил предназначен да се използва, когато работата по него започва в Rational Software Inc.

Моделиране[редактиране на източника | редактиране]

Важно е да се прави разлика между UML модела и набора от диаграми на дадена система. Диаграмата е частично графично представяне на модела на системата. Не е необходимо наборът от диаграми да покрива напълно модела и изтриването на диаграма не променя модела. Моделът може да съдържа и документация, която управлява елементите на модела и диаграмите (например писмени случаи на употреба).

UML диаграмите представляват два различни изгледа на модела^[18] на системата:

• Статичен (или структурен) поглед: подчертава статичната структура на системата, използваща обекти, атрибути, операции и връзки. Структурният поглед включва диаграми на класовете и диаграми на съставните структури.
• Динамичен (или поведенчески) изглед: подчертава динамичното поведение на системата, като показва взаимодействието между обектите и промените във вътрешните състояния на обектите. Този изглед включва диаграми на последователността, диаграми на дейностите и диаграми на машините на състоянията.

UML моделите могат да бъдат обменяни между UML инструменти с помощта на формата за обмен на метаданни XML (XMI).

Диаграми[редактиране на източника | редактиране]

UML 2 има много видове диаграми, които се разделят на две категории.^[5] Някои типове представят структурна информация, а останалите - общи типове поведение, включително няколко, които представят различни аспекти на взаимодействието. Тези диаграми могат да бъдат категоризирани йерархично, както е показано в следващата диаграма^[5] на класовете:

Всички тези диаграми могат да съдържат коментари или бележки, обясняващи употребата, ограничението или намерението.

Структурни диаграми[редактиране на източника | редактиране]

Структурните диаграми акцентират върху нещата, които трябва да присъстват в моделираната система. Тъй като структурните диаграми представят структурата, те се използват широко при документирането на софтуерната архитектура на софтуерните системи. Например диаграмата на компонентите, която описва как една софтуерна система е разделена на компоненти и показва зависимостите между тези компоненти.

• Диаграма на компонентите
• Диаграма на класовете

Диаграми на поведението[редактиране на източника | редактиране]

Диаграмите на поведението подчертават какво трябва да се случи в моделираната система. Тъй като диаграмите на поведението илюстрират поведението на дадена система, те се използват широко за описание на функционалността на софтуерните системи. Като пример, диаграмата на дейностите описва бизнес и оперативните дейности стъпка по стъпка на компонентите в една система.

• Диаграма на дейностите
• Диаграма на случаите на употреба

Диаграми на взаимодействието[редактиране на източника | редактиране]

Диаграмите на взаимодействие, подмножество на диаграмите на поведение, подчертават потока на управление и данни между нещата в моделираната система. Например диаграмата на последователността, която показва как обектите комуникират помежду си чрез последователност от съобщения.

• Диаграма на последователността
• Комуникационна схема

Метамоделиране[редактиране на източника | редактиране]

Основна статия: Механизъм за метаобекти

Илюстрация на механизма за метаобекти

Групата за управление на обекти (OMG) е разработила архитектура за метамоделиране, за да дефинира унифицирания език за моделиране (UML), наречена Meta-Object Facility (MOF).^[19] Meta-Object Facility е проектирана като четирислойна архитектура, както е показано на изображението вдясно. Тя предоставя мета-мета-модел на най-горния слой, наречен слой M3. Този M3-модел е езикът, използван от Meta-Object Facility за изграждане на метамодели, наречени M2-модели.

Най-известният пример за модел на метаобектно съоръжение от ниво 2 е метамоделът на UML - моделът, който описва самия UML. Тези М2-модели описват елементи на М1-слой, а следователно и М1-модели. Това биха били например модели, написани на UML. Последният слой е М0-слой или слой данни. Той се използва за описване на екземпляри на системата по време на изпълнение. ^[20]

Метамоделът може да бъде разширен с помощта на механизъм, който се нарича стереотипизиране. Това е критикувано като недостатъчно/недостатъчно от Брайън Хендерсън-Селърс и Сезар Гонзалес-Перес в "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Осиновяване[редактиране на източника | редактиране]

UML е полезен в много контексти на проектиране, ^[16]дотолкова, че е станал почти повсеместен в ИТ общността. ^[22]

Понякога той се разглежда като "сребърен куршум" в дизайна, което води до проблеми при използването му. Неправилната му употреба включва прекомерното му използване (проектиране на всяка малка част от кода на системата с него, което е ненужно) и приемането, че всеки може да проектира всичко с него (дори тези, които не са програмирали). ^[23]

Той е голям език с много конструкции. Някои (включително Джейкъбсън) смятат, че те са твърде много и че това затруднява изучаването (и съответно използването) му. ^[24]

Критики[редактиране на източника | редактиране]

Общите критики към UML от страна на индустрията включват: ^[4]

• не е полезен: "[не] им предлага предимства в сравнение с техните настоящи, еволюирали практики и представяния"
• твърде сложни, особено за комуникация с клиенти: "Най-добрата причина да не се използва UML е, че той не е "четим" за всички заинтересовани страни. Колко струва UML, ако бизнес потребителят (клиентът) не може да разбере резултата от вашите усилия за моделиране?"
• нуждата от синхронизиране на UML и кода, както и при документацията като цяло.

Критика на UML 1.x[редактиране на източника | редактиране]

Записване на кардиналност

Както и при диаграмите за бази данни на Чен, Бахман и ISO ER, моделите на класовете са специфицирани да използват кардинални стойности "look-across", въпреки че някои автори (Merise, ^[25]Elmasri & Navathe^[26] и др^[27].) предпочитат същите страни или "look-here" за ролите, както и минимални и максимални кардинални стойности. Неотдавнашни изследователи (Feinerer, ^[28]Dullea и др.^[29]) показаха, че техниката "look-across", използвана от UML и ER диаграмите, е по-малко ефективна и по-малко последователна, когато се прилага към n-крайни връзки от ред >2.

Файнер казва: "Проблеми възникват, ако работим по семантиката на кръстосания поглед, използвана за асоциациите на UML. Хартман ^[30]изследва тази ситуация и показва как и защо различните трансформации се провалят." (Въпреки че споменатото "намаление" е фалшиво, тъй като двете диаграми 3.4 и 3.5 всъщност са едни и същи) и също "Както ще видим на следващите няколко страници, интерпретацията look-across въвежда няколко трудности, които пречат на разширяването на простите механизми от двоични към n-ярни асоциации."