UML диаграма. Видове UML диаграми. Общи характеристики на езика UML Пример за диаграми на езика uml

UML (Unified Modeling Language - унифициран език за моделиране) - език за графично описание за моделиране на обекти в областта на разработката на софтуер. UML е общ език, това е отворен стандарт, който използва графична нотация за създаване на абстрактен модел на система, наречен UML модел. UML е създаден, за да дефинира, визуализира, проектира и документира предимно софтуерни системи. UML не е език за програмиране, но генерирането на код е възможно в инструментите за изпълнение на UML модели като интерпретиран код.Уикипедия

Търговски продукти

Microsoft Visio

Тип: търговски софтуер

Популярен софтуерен продукт от Microsoft, който ви позволява да рисувате богати диаграми, включително UML:

Започвайки от версия 2010, стана възможно публикуването на диаграми в мрежата (SharePoint + Visio Services):

Visio Viewer- безплатна програма, която ви позволява да преглеждате предварително създадени диаграми на Visio. Можете да изтеглите от %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Моделиране,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Поредица%20Диаграма%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Визуализация%20и%20Моделиране%20Функция%20Пакет%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A
  • %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
    • %0A
  • %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20слой%20диаграми%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
    • %0A
  • %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20слой%20диаграми
    • %0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Визуализация%20и%20Моделиране%20Функция%20Пакет%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Възможности:

  • Диаграма на случаите на използване (диаграми на прецеденти);
  • Диаграма на разполагане (топологични диаграми);
  • Диаграма на Statechart (диаграми на състоянията);
  • Диаграма на дейността (диаграми на дейността);
  • Диаграма на взаимодействие (диаграми на взаимодействие);
  • Диаграма на последователност (диаграми на последователности от действия);
  • Диаграма на сътрудничество (диаграми на сътрудничество);
  • Класова диаграма (класови диаграми);
  • Компонентна диаграма (компонентни диаграми).

Екранни снимки:

програми с отворен код

StarUML

Възможности:

  • Поддръжка на UML 2.0
  • MDA (моделно управлявана архитектура)
  • Plug-in Architecture (можете да пишете на COM съвместими езици: C++, Delphi, C#, VB, ...)

StarUML е написан основно на Delphi, но могат да се добавят компоненти и на други езици, като C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. По-долу са някои екранни снимки.

Диаграма на класа:

Диаграма на случаите на използване:

ArgoUML

Поддържани диаграми:

  • клас
  • състояние
  • случаи на употреба
  • Дейност
  • Сътрудничество
  • Разгръщане
  • Последователност

Възможности:

  • Поддръжка за девет UML 1.4 диаграми
  • Независимо от платформа (Java 5+)
  • UML 1.4 Стандартен метамодел
  • XMI поддръжка
  • Експортирайте в GIF, PNG, PS, EPS, PGML и SVG
  • Езици: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
  • OCL поддръжка
  • Напред, обратно инженерство

екранна снимка:

UML е унифициран език за графично моделиране за описване, визуализиране, проектиране и документиране на OO системи. UML е предназначен да поддържа процеса на моделиране на PS въз основа на OO подхода, да организира връзката между концептуални и програмни концепции и да отразява проблемите на мащабирането на сложни системи. UML моделите се използват на всички етапи от жизнения цикъл на софтуера, от бизнес анализ до поддръжка на системата. Различните организации могат да използват UML по свой начин, в зависимост от техните проблемни области и използваните технологии.

Кратка история на UML

До средата на 90-те години няколко десетки методи за моделиране на ОО бяха предложени от различни автори, всеки от които използваше своя собствена графична нотация. В същото време всеки от тези методи имаше своите силни страни, но не позволи да се изгради достатъчно пълен PS модел, за да се покаже „от всички страни“, т.е. всички необходими проекции (вижте статия 1). В допълнение, липсата на стандарт за OO моделиране затруднява разработчиците да изберат най-подходящия метод, което възпрепятства широкото използване на OO подхода към разработването на софтуер.

По искане на Object Management Group (OMG) - организация, отговорна за приемането на стандарти в областта на обектните технологии и бази данни, неотложният проблем с унификацията и стандартизацията беше решен от авторите на трите най-популярни OO метода - G. Booch , Д. Рамбо и А. Джейкъбсън, които комбинираха усилия, създадоха UML версия 1.1, одобрена от OMG през 1997 г. като стандарт.

UML е език

Всеки език се състои от речник и правила за комбиниране на думи, за да се направят смислени конструкции. Така, по-специално, езиците за програмиране са подредени, като UML. Неговата отличителна черта е, че речникът на езика се формира от графични елементи. Всеки графичен символ има специфична семантика, така че модел, създаден от един разработчик, може да бъде недвусмислено разбран от друг, както и от инструмент, който интерпретира UML. От това, по-специално, следва, че PS модел, представен в UML, може да бъде автоматично преведен на OO език за програмиране (като Java, C ++, VisualBasic), тоест с добър инструмент за визуално моделиране, който поддържа UML, от изграждане на модел, ние също ще получим празен код на програмния код, съответстващ на този модел.

Трябва да се подчертае, че UML е език, а не метод. Обяснява от какви елементи да създавате модели и как да ги четете, но не казва нищо за това кои модели и в какви случаи трябва да бъдат разработени. За да създадете метод, базиран на UML, е необходимо да го допълните с описание на процеса на разработка на PS. Пример за такъв процес е Rational Unified Process, който ще бъде обсъден в следващите статии.

Речник

Моделът е представен под формата на обекти и връзки между тях, които са показани на диаграми.

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

Връзкипоказват различни връзки между обекти. В UML са дефинирани следните типове релации:

  • Пристрастяванепоказва такава връзка между две същности, когато промяна в една от тях - независима - може да повлияе на семантиката на другата - зависима. Зависимостта е представена от пунктирана стрелка, сочеща от зависимия обект към независимия обект.
  • Асоциацияе структурна връзка, показваща, че обектите на един обект са свързани с обекти на друг. Графично асоциацията се показва като линия, свързваща свързаните обекти. Асоциациите се използват за навигация между обекти. Например асоциацията между класовете "Поръчка" и "Продукт" може да се използва за намиране на всички продукти, посочени в определена поръчка - от една страна, или за намиране на всички поръчки, които съдържат този продукт - от друга. Ясно е, че съответните програми трябва да внедрят механизъм, който осигурява такава навигация. Ако се изисква навигация само в една посока, това се обозначава със стрелка в края на асоциацията. Специален случай на асоцииране е агрегацията - връзка от формата "цяло" - "част". Графично е подчертано с ромб в края близо до цялостното цяло.
  • Обобщениее връзка между родителски обект и дъщерен обект. По същество тази връзка отразява свойството на наследяване за класове и обекти. Обобщението е показано като линия, завършваща с триъгълник, сочещ към родителския обект. Детето наследява структурата (атрибути) и поведението (методи) на родителя, но в същото време може да има нови структурни елементи и нови методи. UML позволява множествено наследяване, когато даден обект е свързан с повече от един родителски обект.
  • Внедряване- връзката между обекта, който определя спецификацията на поведението (интерфейс) с обекта, който определя изпълнението на това поведение (клас, компонент). Тази връзка обикновено се използва при моделиране на компоненти и ще бъде описана по-подробно в следващите статии.

Диаграми. UML предоставя следните диаграми:

  • Диаграми, описващи поведението на системата:
    • Диаграми на състоянието (диаграми на състоянието),
    • Диаграми на активността,
    • Диаграми на обекти,
    • Диаграми на последователности,
    • Диаграми на сътрудничество;
  • Диаграми, описващи физическото изпълнение на системата:
    • Компонентни диаграми;
    • Диаграми на разгръщане.

Контролен изглед на модела. Пакети.

Вече казахме, че за да бъде даден модел добре разбран от човек, е необходимо да се организира йерархично, оставяйки малък брой обекти на всяко ниво на йерархията. UML включва средство за организиране на йерархично представяне на модел - пакети. Всеки модел се състои от набор от пакети, които могат да съдържат класове, случаи на използване и други обекти и диаграми. Един пакет може да включва други пакети, което ви позволява да създавате йерархии. UML не предоставя отделни пакетни диаграми, но те могат да се появят в други диаграми. Пакетът се показва като правоъгълник с раздел.

Какво предлага UML.

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

И последното…

Въпреки цялата привлекателност на UML, би било трудно да се използва в реално PS моделиране без инструменти за визуално моделиране. Такива инструменти ви позволяват бързо да представяте диаграми на екрана на дисплея, да ги документирате, да генерирате празни програмни кодове в различни OO програмни езици и да създавате схеми на бази данни. Повечето от тях включват възможността за реинженеринг на програмни кодове - възстановяване на определени проекции на PS модела чрез автоматично анализиране на изходните кодове на програмите, което е много важно за гарантиране, че моделът и кодовете съвпадат и при проектиране на системи, които наследяват функционалността на предшестващите системи .

Анотация: Предметът на този курс е UML - унифициран език за моделиране. В предишната лекция говорихме за това какво е UML, неговата история, предназначение, начини за използване на езика, структурата на неговата дефиниция, терминология и нотация. Беше отбелязано, че UML моделът е набор от диаграми. В тази лекция ще разгледаме такива въпроси: защо имаме нужда от няколко вида диаграми; видове диаграми; ООП и диаграми на последователности

Преди да преминем към обсъждането на основния материал на тази лекция, нека поговорим защо изобщо да изграждаме някакви диаграми. Разработването на модел на всяка система (не само софтуер) винаги предшества нейното създаване или актуализиране. Това е необходимо най-малкото, за да си представим по-ясно проблема, който се решава. Обмислените модели са много важни както за взаимодействието в екипа за разработка, така и за взаимното разбирателство с клиента. В края на краищата, той ви позволява да се уверите, че проектът е „архитектурно последователен“, преди да бъде внедрен в код.

Изграждаме модели на сложни системи, защото не можем да ги опишем напълно, „разгледайте ги с един поглед“. Ето защо ние отделяме само свойствата на системата, които са от съществено значение за конкретна задача и изграждаме нейния модел, който отразява тези свойства. Методът на обектно-ориентирания анализ дава възможност да се опишат по най-адекватния начин реални сложни системи. Но тъй като системите стават по-сложни, има нужда от добра технология за симулация. Както казахме в предишната лекция, като такава "стандартна" технология се използва унифицирана система. език за моделиране(Unified Modeling Language, UML), който е графичен език за спецификация, визуализация, проектиране и документиране на системи. Използвайки UML, можете да разработите подробен модел на създаваната система, отразяващ не само нейната концепция, но и специфични характеристики на изпълнение. В рамките на UML модела всички представяния на системата са фиксирани под формата на специални графични конструкции, наречени диаграми.

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

Защо имате нужда от няколко вида диаграми

Първо, нека дефинираме терминологията. В предговора към тази лекция многократно използвахме понятията система, модел и диаграма. Авторът е сигурен, че всеки от нас интуитивно разбира значението на тези понятия, но за да стане напълно ясно, нека погледнем отново речника и прочетем следното:

Система- набор от взаимосвързани управлявани подсистеми, обединени от обща цел на функциониране.

Да, не е много информативно. Какво тогава е подсистема? За да изясним ситуацията, нека се обърнем към класиката:

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

Е, нищо не можете да направите, трябва да потърсите определението за подсистема. Там също пише, че подсистемае набор от елементи, някои от които определят поведението на други елементи. Иън Сомървил обяснява концепцията по следния начин:

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

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

Разберете концепцията за система. По време на процеса на проектиране системата се разглежда от различни гледни точкис помощта на модели, чиито различни изображения се появяват под формата на диаграми. Отново, читателят може да има въпроси относно значението на понятията моделии диаграми. Смятаме, че това е красиво, но не много ясно определение модели като семантично затворена системна абстракцияе малко вероятно да изясни ситуацията, така че нека се опитаме да обясним "с нашите собствени думи".

Модел- това е определен (материален или не) обект, който показва само най-значимите характеристики на системата за тази задача. Моделите са различни - материални и нематериални, изкуствени и естествени, декоративни и математически...

Нека дадем няколко примера. Познатите на всички ни пластмасови коли играчки, на които сме си играли с такава страст в детството, не са нищо повече от материал изкуствен декоративенистински модел кола. Разбира се, в такава "кола" няма двигател, не пълним резервоара й с бензин, скоростната кутия не работи (още повече, че изобщо не съществува), но като модел тази играчка изпълнява напълно функциите си : дава на детето представа за колата, защото показва нейните характерни черти са наличието на четири колела, каросерия, врати, прозорци, способността за шофиране и др.

В медицинските изследвания тестовете върху животни често предхождат клиничните изпитвания на лекарства върху хора. В този случай животното действа като естествен материалчовешки модели.

Уравнението, показано по-горе, също е модел, но това е математически модел и описва движението на материална точка под действието на гравитацията.

Остава само да се каже какво е диаграма. Диаграмае графично представяне на набор от елементи. Обикновено се изобразява като графика с върхове (обекти) и ръбове (релации). Има много примери за диаграми. Това е блокова диаграма, позната на всички нас от ученически години, и диаграми за инсталиране на различно оборудване, които можем да видим в ръководствата за потребителя, и дърво от файлове и директории на диск, което можем да видим, като изпълним командата дърво в Windows конзола и много, много други. В ежедневието диаграмите ни заобикалят от всички страни, защото картината ни е по-лесна за възприемане от текста...

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

Въпреки факта, че в предходния параграф бяхме много свободни с концепцията за модел, трябва да се разбере, че в контекста на горните определения нито една диаграма не е модел. Диаграмите са само средство за визуализиране на модела и двете трябва да се разграничават. само набор от диаграми представлява системен модели го описва най-пълно, но нито една диаграма, извадена от контекста.

Видове диаграми

Дефиниран UML 1.5 дванадесет вида диаграмиразделени на три групи:

  • четири вида диаграми представят статичната структура на приложението;
  • пет представляват поведенческите аспекти на системата;
  • три представляват физическите аспекти на работата на системата (диаграми за изпълнение).

Текущата версия на UML 2.1 не е направила твърде много промени. Диаграмите са леко променени на външен вид (появили са се рамки и други визуални подобрения), нотацията е леко подобрена, някои диаграми са получили нови имена.

Точната бройка обаче канонични диаграмитова е абсолютно маловажно за нас, тъй като няма да ги разгледаме всички, а само някои - поради това, че броят на типовете диаграми за конкретен модел на конкретно приложение не е строго фиксиран. За прости приложения няма нужда да се изграждат всички диаграми без изключение. Например, за локално приложение не е необходимо да се изгражда диаграма за разполагане. Важно е да се разбере, че списъкът с диаграми зависи от спецификата на разработвания проект и се определя от самия разработчик. Ако любопитният читател все още иска да знае за всички UML диаграми, ще го насочим към UML стандарта (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Спомнете си, че целта на този курс не е да опише абсолютно всички възможности на UML, а само да въведе този език, да даде първоначална представа за тази технология.

Така че ще разгледаме накратко такива видове диаграми като:

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

За някои от тези диаграми ще говорим по-подробно в следващите лекции. Междувременно няма да се съсредоточаваме върху подробностите, а си поставяме за цел да научим читателя поне визуално да прави разлика между видовете диаграми, да даде първоначална представа за предназначението на основните типове диаграми. . И така, да започваме.

Диаграма на случаи на използване

Всички (включително софтуерни) системи са проектирани, като се вземе предвид фактът, че в процеса на тяхната работа те ще бъдат използвани от хора и / или ще взаимодействат с други системи. Обектите, с които системата взаимодейства в процеса на своята работа, се наричат актьории всеки участник очаква системата да се държи по строго определен, предвидим начин. Нека се опитаме да дадем по-строга дефиниция на ектор. За да направим това, ние използваме прекрасен визуален речник за UML Зиком Ментор:

Хектор (актьор)- това е набор от логически свързани роли, изпълнявани при взаимодействие с прецеденти или обекти (система, подсистема или клас). Актьорът може да бъде лице или друга система, подсистема или клас, които представляват нещо извън обекта.

Графично векторът е изобразен или " малък човек“, подобни на тези, които рисувахме в детството, изобразяващи членове на нашето семейство, или класов символ със съответния стереотип, както е показано на снимката. И двете форми на представяне имат едно и също значение и могат да се използват в диаграми. „Стереотипната“ форма се използва по-често за представяне на системни актьори или в случаите, когато актьорът има свойства, които трябва да бъдат показани (фиг. 2.1).

Внимателният читател може веднага да зададе въпроса: Защо е хектор, а не актьор?? Съгласни сме, думата "ектор" малко реже ухото на руски човек. Причината, поради която казваме това, е проста - екторът се образува от думата действие, което в превод означава действие. Буквалният превод на думата "ектор" - актьор- твърде дълъг и неудобен за използване. Затова ще продължим да твърдим така.


Ориз. 2.1.

Същият внимателен читател би могъл да забележи думата "прецедент", проблясваща в определението на ектора. Какво е? Този въпрос ще ни заинтересува още повече, ако си спомним за какво говорим сега диаграма на случаите на използване. Така,

Прецедент (случай на употреба)- описание на определен аспект от поведението на системата от гледна точка на потребителя (Butch).

Определението е доста разбираемо и изчерпателно, но може да бъде допълнително прецизирано с помощта на същото Зиком Ментор"ом:

случай на употреба- описание на набора от последователни събития (включително варианти), извършени от системата, които водят до резултата, наблюдаван от актьора. Случаят на употреба представлява поведението на обект чрез описание на взаимодействието между участниците и системата. Прецедентът не показва "как" е постигнат определен резултат, а само "какъв" е той.

Прецедентите се обозначават по много прост начин - под формата на елипса, вътре в която е посочено името му. Случаите на използване и актьорите са свързани с линии. Често в единия край на линията е изобразен ориз. 2.3

  • формиране на общи изисквания към поведението на проектираната система;
  • разработване на концептуален модел на системата за последващото й детайлизиране;
  • изготвяне на документация за взаимодействие с клиенти и потребители на системата.
    • Езикът UML е език за графично моделиране с общо предназначение за спецификация, визуализация, дизайн и документиране на всички артефакти, създадени по време на разработката на софтуерни системи.

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

    Бележката използва материали от книги: Иванов Д. Ю., Новиков Ф. А. Унифициран език за моделиране UMLи Леоненков. Урок за UML.

    Да започнем с редактора. Под Linux пробвах различни UML редактори, най-много ми хареса UMLet, въпреки че е написан на Java, се движи много бързо и повечето празни обекти са в него. Има и ArgoUML, междуплатформен UML редактор, също написан на Java, функционално богат, но забавящ повече.

    Спрях се на UMLet, инсталирайте го под Arch Linuxи ubuntu:

    # под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

    В UML всички обекти могат да бъдат разделени на следните типове:

    • структурни;
    • поведенчески;
    • групиране;
    • анотационен;

    UML използва четири основни типа релации:

    Зависимост- показва, че промяната на независимия обект засяга по някакъв начин зависимия обект. Графично връзката на зависимост се изобразява като пунктирана линия със стрелка, сочеща от зависимия обект към независимия обект.

    Асоциация- има място, ако една единица е пряко свързана с друга (или с други - асоциацията може да бъде не само бинарна). Графично асоциацията се изобразява като плътна линия с различни допълнения, свързващи свързани обекти.

    Обобщениее връзка между две единици, едната от които е частен (специализиран) случай на другата. Графично обобщението се изобразява като линия с триъгълна незапълнена стрелка в края, насочена от конкретното (подклас) към общото (суперклас).

    Реализации- релацията на изпълнение показва, че един обект е изпълнение на друг. Графично изпълнението се изобразява като пунктирана линия с триъгълна незапълнена стрелка в края, насочена от изпълняващия обект към изпълнявания.

    AT UML 2дефинирани 13 типове диаграми. По стандарт всяка диаграма трябва да има рамка с правоъгълник (скосен долния десен ъгъл) в горния ляв ъгъл, който показва ID (етикета) на диаграмата и заглавието.

    Диаграми за изобразяване на структурата на системата:

    • Диаграма на компонент (диаграма на компонент, етикет компонент);
    • Диаграма на разгръщане (диаграма на разгръщане, етикет разгръщане);
    • Диаграма на клас (диаграма на клас, етикет клас);
    • Диаграма на обект (диаграма на обект, етикет обект);
    • Диаграма на вътрешната структура (диаграма на съставна структура, етикет клас);

    Диаграми за изобразяване на поведението на системата:

    • Диаграма на синхронизация (диаграма на взаимодействие, етикет синхронизация);
    • Диаграма на дейността (диаграма на дейността, етикет дейност);
    • диаграма на последователност (диаграма на последователност, етикет sd);
    • Комуникационна диаграма (комуникационна диаграма, етикет ком);
    • Диаграма на автомат (диаграма на автоматична машина, етикет държавна машина);
    • Диаграма за преглед на взаимодействието, етикет взаимодействие);

    Графиките се открояват:

    • Диаграма на случаите на използване (диаграма на случаите на използване, етикет за случаи на използване);
    • Диаграма на опаковката (диаграма на опаковката, етикет пакет);

    Диаграма на използване

    Диаграма на използване(диаграма на случаи на използване) е най-общото представяне на функционалното предназначение на системата.

    Разглеждайки диаграма на случаи на използване като модел на система, човек може да я асоциира с модел на черна кутия. Всеки случай на използване дефинира последователност от действия, които трябва да бъдат извършени от проектираната система, когато взаимодейства със съответния актьор.

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

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

    Релация на разширение- дефинира връзката между екземпляри на единичен случай на употреба с по-общ случай на употреба, чиито свойства се определят въз основа на начина, по който тези екземпляри се комбинират заедно. По този начин, ако има връзка на разширение от случай на употреба A към случай на употреба B, това означава, че свойствата на екземпляр на случай на употреба B могат да бъдат допълнени поради наличието на свойства в случай на разширена употреба A.

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

    Отношение на обобщениеслужи за указване на факта, че някакъв случай на употреба A може да се обобщи до случай на употреба B. В този случай случай на употреба A ще бъде специализация на случай на употреба B. В този случай B се нарича предшественик или родител на A и използва A е потомък на случай на употреба B използване на V.

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

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

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

    Връзка на включване, от случай на употреба A до случай на употреба B, показва, че всеки екземпляр на случай на употреба A включва функционалните свойства, посочени за случай на употреба B.

    Графично тази връзка е представена от пунктирана линия със стрелка (вариант на връзката на зависимост), сочеща от основния случай на употреба към включения случай на употреба.

    класова диаграма

    класова диаграма(диаграма на класове) - основният начин за описание на статичната структура на системата.

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

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

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

    Специални ключови думи (стереотипи) могат да бъдат поставени над стрелката:

    • "достъп" - служи за указване на наличието на публични атрибути и операции на изходния клас за клиентските класове;
    • "bind" - клиентският клас може да използва някакъв шаблон за последващата си параметризация;
    • "derive" - ​​атрибутите на клиентския клас могат да бъдат изчислени от атрибутите на изходния клас;
    • "импорт" - публичните атрибути и операции на изходния клас стават част от клиентския клас, сякаш са декларирани директно в него;
    • "refine" - показва, че клиентският клас служи като усъвършенстване на изходния клас по исторически причини, когато в хода на работата по проекта стане достъпна допълнителна информация.

    асоциативна връзкасъответства на наличието на някаква връзка между класовете. Тази връзка се обозначава с плътна линия с допълнителни специални символи, които характеризират отделните свойства на конкретна асоциация. Като допълнителни специални знаци могат да се използват името на асоциацията, както и имената и множеството ролеви класове на асоциацията. Името на асоциация е незадължителен елемент от нейното обозначение.

    Отношение на агрегираневъзниква между няколко класа, ако един от класовете е обект, който включва други обекти като компоненти. Използва се за представяне на системни връзки от типа "част-цяло".

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

    Отношение на обобщениее връзка между по-общ елемент (родител или предшественик) и по-специфичен или специален елемент (дете или потомък). Приложено към диаграма на класове, тази връзка описва йерархичната структура на класовете и наследяването на техните свойства и поведение. Това предполага, че класът наследник има всички свойства и поведение на класа предшественик, а също така има свои собствени свойства и поведение, които не присъстват в класа предшественик.

    схема на автомат

    схема на автомат(диаграма на държавната машина) или диаграма на състояниетов UML 1 (диаграма на диаграмата на състоянието) е един от начините за подробно описание на поведението в UML. По същество автоматните диаграми, както подсказва името, са графика на състояния и преходи на краен автомат, зареден с много допълнителни детайли и подробности.

    Диаграмата на състоянието описва процеса на промяна на състоянията само на един клас или по-скоро на един екземпляр от определен клас, т.е. моделира всички възможни промени в състоянието на конкретен обект. В този случай промяната в състоянието на даден обект може да бъде причинена от външни влияния от други обекти или отвън. Използват се диаграми на състоянието, за да се опише реакцията на даден обект на такива външни влияния.

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

    Първоначално състояниее частен случай на състояние, което не съдържа никакви вътрешни действия (псевдосъстояния). Обектът е в това състояние по подразбиране в началния момент от време. Той служи за указване на диаграмата на състоянието на графичната област, от която започва процеса на промяна на състоянията.

    Окончателен (окончателен)състояние е частен случай на състояние, което също не съдържа никакви вътрешни действия (псевдосъстояния). Обектът ще бъде в това състояние по подразбиране след завършване на автомата в крайния час.

    диаграма на дейността

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

    диаграма на дейността(диаграма на дейността) е друг начин за описване на поведение, което визуално наподобява добра стара блок-схема на алгоритъм. Използва се за симулиране на процеса на извършване на операции.

    Основната посока на използване на диаграми на дейности е визуализиране на характеристиките на изпълнението на операциите на класа, когато е необходимо да се представят алгоритми за тяхното изпълнение.

    В диаграмата на активността се използват един основен тип същности – действие, и един тип връзка – преходи (прехвърляне на управление). Използват се и такива конструкции като вилици, сливания, връзки, разклонения. Препоръчително е да използвате глагол с обяснителни думи като име на просто действие.

    диаграма на последователността

    диаграма на последователността(диаграма на последователност) е начин за описване на поведението на системата "чрез примери".

    Всъщност диаграмата на последователността е запис на протокола на определена сесия на системата (или фрагмент от такъв протокол). В обектно-ориентираното програмиране най-същественото нещо по време на изпълнение е предаването на съобщения между взаимодействащи обекти. Това е последователността на изпращане на съобщения, която се показва на тази диаграма, откъдето идва и името.

    В диаграмата на последователността се използва един основен тип същности – екземпляри на взаимодействащи си класификатори (основно класове, компоненти и актьори), и един тип взаимоотношения – връзки, чрез които се обменят съобщения.

    Възможни типове съобщения (изображението е взето от larin.in):

    Комуникационна диаграма

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

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

    Диаграма на компонентите

    Диаграма на компонентите(компонентна диаграма) - показва връзката между модулите (логически или физически), които изграждат симулираната система.

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

    • имплементации между компоненти и интерфейси (компонентът имплементира интерфейса);
    • зависимости между компоненти и интерфейси (компонентът използва интерфейс);

    Диаграма на поставяне

    Диаграма на поставяне(диаграма на разгръщане), заедно с показването на състава и връзките на системните елементи, показва как те са физически поставени върху изчислителните ресурси по време на изпълнение.

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

    Диаграма на обекта

    Диаграма на обекта(обектна диаграма) - е екземпляр на класова диаграма.

    В обектната диаграма се използва един основен тип същности: обекти (инстанции на клас), между които са посочени специфични връзки (най-често инстанции на асоциация). Обектните диаграми са от спомагателен характер - всъщност това са примери (може да се каже, изхвърляния на паметта), които показват какви обекти съществуват и връзките между тях в определен момент от работата на системата.

    Диаграма на вътрешната структура(диаграма на съставна структура) се използва за по-подробно представяне на структурни класификатори, предимно класове и компоненти.

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

    Диаграма за преглед на взаимодействието(обзорна диаграма на взаимодействие) е вид диаграма на дейността с разширен синтаксис: като елементи на обща диаграма на взаимодействие могат да действат връзки към взаимодействия (използване на взаимодействие), определени от диаграми на последователности.

    Времева диаграма

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

    Диаграма на опаковката

    Диаграма на опаковката(пакетна диаграма) е единственият инструмент, който ви позволява да управлявате сложността на самия модел.

    Основните елементи на нотацията са пакети и зависимости с различни стереотипи.

    Модел субект-връзка (ER-модел)

    аналогов класови диаграми(UML) може да бъде ER модел, който се използва при проектирането на бази данни (релационен модел).

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

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

    Основни понятия:

    Същност(субект) е субект, който може да бъде идентифициран по някакъв начин, който го отличава от други субекти, например, КЛИЕНТ 777. Един обект всъщност е набор от атрибути.

    Набор от обекти(entity set) - набор от обекти от един и същи тип (с еднакви свойства).

    Връзка(връзка) е асоциация, установена между множество обекти.

    Домейн(домейн) - набор от стойности (домейн) на атрибута.

    Има три вида двоични връзки:

    • едно към едно- единичен екземпляр на обект от един клас е свързан с единичен екземпляр на обект от друг клас, например РЪКОВОДИТЕЛ – ОТДЕЛ;
    • 1 до Nили един към много- единичен екземпляр на обект от един клас е свързан с много екземпляри на обект от друг клас, например ОТДЕЛ - СЛУЖИТЕЛ;
    • N до Mили много към много- много екземпляри на обект от един клас са свързани с много екземпляри на обект от друг клас, например СЛУЖИТЕЛ - ПРОЕКТ;
      • Речник на основните понятия в UML

      обект- образувание, което има уникалност и капсулира състоянието и поведението.

      клас- описание на набор от обекти с общи атрибути, определящи състояние и операции, определящи поведение.

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

      Сътрудничество- набор от обекти, които си взаимодействат за постигане на някаква цел.

      актьор- субект, който е извън моделираната система и директно взаимодейства с нея.

      компонент- модулна част от системата с добре дефиниран набор от необходими и предоставени интерфейси.

      Артефакт- елемент от информация, който се използва или генерира в процеса на разработка на софтуер. С други думи, артефактът е физическа единица на изпълнение, получена от моделен елемент (като клас или компонент).

      Възел- изчислителен ресурс, върху който се поставят артефакти и, ако е необходимо, се изпълняват.

      Поведенческите субекти имат за цел да опишат поведението. Има само две основни поведенчески единици: състояние и действие.

      състояние- период от жизнения цикъл на обект, в който обектът отговаря на определено състояние и извършва собствена дейност или чака настъпването на някакво събитие.

      действие- примитивно атомно изчисление.

      машинае пакет, който дефинира набор от концепции, необходими за представяне на поведението на моделирания обект като дискретно пространство с краен брой състояния и преходи.

      класификаторе дескриптор за набор от обекти от същия тип.

      Допълнително четене

      • Фаулър М. UML. Основи, 3-то издание
      • Буч Г., Рамбо Д., Джейкъбсън И. UML език. Упътване

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

    План за действие

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

    След като прочетете другите раздели ("Пример", "Използване"), можете да опитате ръката си в създаването на диаграми на състоянието сами.

    Бележки (описание)

    Ето основния набор от герои диаграми на състояниетонеобходими, за да можете да четете диаграмата. След като прочетете останалите раздели („Пример“, „Приложение“), ще можете да съставяте диаграми на състояниетосам!

    Срок Образ Описание
    Първоначално псевдосъстояние Първоначално състояние на системата
    Преход Преходът означава преминаване от едно състояние в друго.
    състояние Обозначава действията, извършвани от системата (може да включва възможни опции), които водят до резултатите, наблюдавани от участниците.
    състояние
    състояние на активност    		 Трудна стъпка в случай на употреба може да бъде представена от друг случай на употреба.
    В термините на UML казваме, че първият случай на употреба включва втория.
    Крайно състояние Позволява ви да посочите границите на системи или подсистеми.
    Вътрешни дейности Случаят, при който състоянията могат да реагират на събития, без да се прави преход, в който случай събитието, защитата и дейността се поставят вътре в правоъгълника на състоянието.
    входна дейност Дейността за влизане се изпълнява всеки път, когато влезете в състоянието
    изходна дейност Изходна дейност - изпълнява се всеки път, когато напуснете държавата.
    свръхдържава
    		Често се случва няколко държави да имат общи преходи и вътрешни дейности. В такива случаи можете да ги превърнете в подсъстояния (подсъстояния) и да прехвърлите цялостното поведение в суперсъстояние (суперсъстояние).
    Паралелни държави
    		Състоянията могат да бъдат разделени на множество едновременни състояния, които се изпълняват по едно и също време.

    Как да приложим техниката на творчеството

    UML диаграмите на състоянието са добри за описание на поведението на един обект в множество случаи на употреба. Но те не са много подходящи за описание на поведение, характеризиращо се с взаимодействието на много обекти. Следователно има смисъл да се използват други технологии във връзка с диаграмите на състоянието. Например, диаграмите на взаимодействие (глава 4) са чудесни при описване на поведението на множество обекти в един случай на употреба, докато UML диаграмите на активност са добри за показване на основната последователност от действия на няколко обекта в няколко случая на употреба.

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

    Ако използвате диаграми на състояния, не се опитвайте да ги начертаете за всеки клас в системата. Този подход често се използва в името на формално строга пълнота, но почти винаги е загуба на усилия. Използвайте диаграми на състояния само за класове, които показват интересно поведение, където начертаването на диаграмата на състоянието ви помага да разберете как вървят нещата.

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

    Как да се научим

    Тук сме се опитали да предоставим най-лесния начин за учене UML диаграми на състоянието.

    Подобно на много други езици, той използва набор от знаци за описание. Значението на тези символи можете да намерите в таблицата в раздела "Бележки (описание)". Всеки знак има свое име (термин) и правопис. Освен това всеки термин е снабден с кратко обяснение, за да разберете бързо основната му същност.

    След това препоръчваме да отидете в секцията „Примери“. диаграми на състояниетода опитате ръката си в четенето на различни диаграми. След това трябва да проучите раздела "Използване", тъй като, въпреки че броят на типовете диаграми в UML е малък, можете да получите максимална полза от използването им само ако използвате подходящите диаграми за предназначението им.

    Пример за употреба

    Диаграми на държавни машиние добре позната техника за описание на поведението на система. Диаграмите на състоянието съществуват под една или друга форма от 60-те години на миналия век и в ранните дни на обектно-ориентираното програмиране те са били използвани за представяне на поведението на система. При обектно-ориентираните подходи вие рисувате диаграма на състоянието на един клас, за да покажете поведението на един обект по време на живота му.

    Винаги, когато се пише за машини с ограничени състояния, системите за круиз контрол или автоматите за продажба неизбежно се цитират като примери.
    Решихме да използваме контролера на тайния контролен панел в Готическия замък. В този замък искаме да скрием нашите съкровища, така че да са трудни за намиране. За да получим достъп до ключалката на сейфа, трябва да извадим стратегическа свещ от канделабъра, но ключалката ще се появи само ако вратата е затворена. След като се появи ключалката, можем да поставим ключа в нея и да отворим сейфа. За по-голяма сигурност сме направили така, че сейфът да може да се отваря само след отстраняване на свещта. Ако крадецът не се съобрази с тази предпазна мярка, тогава ще отприщим отвратително чудовище, което ще погълне крадеца.

    На фиг. 10.1 показано диаграма на състояниетоклас контролер, който управлява моята необичайна система за сигурност. Диаграмата на състоянието започва със състоянието на обекта на контролера, който се създава: състояния изчакайте. Това е показано на диаграмата с първоначално псевдосъстояние, което не е състояние, но има стрелка, сочеща към първоначалното състояние.
    Диаграмата показва, че контролерът може да бъде в едно от трите състояния: Изчакайте (Изчакване), Заключете (Заключете) и Отворете (Отворено). Диаграмата показва и правилата, по които контролерът преминава от едно състояние в друго. Тези правила са представени като преходи - линии, свързващи състояния.

    Преходът означава преминаване от едно състояние в друго. Всеки преход има свой етикет, който се състои от три части:
    тригер-идентификатор [защита]/дейност (тригер-подпис /дейност). Всички те не са задължителни. обикновено, trigger-idе единственото събитие, което може да причини промяна на състоянието.

    Гардът, ако е посочен, е логично условие, което трябва да бъде изпълнено, за да се осъществи преходът. Активността е някакво поведение на системата по време на прехода. Това може да бъде всякакъв поведенчески израз. Пълната форма на ID тригер може да включва множество събития и параметри. Преходът от състояние на изчакване (фиг. 10.1) към друго състояние може да се прочете като „В състояние на изчакване, ако свещта бъде премахната, виждате заключване и преминавате в състояние на заключване.“

    И трите части на описанието на прехода не са задължителни. Пропускането на активност означава, че нищо не се случва по време на прехода. Предпазители за пропускане означава, че преходът винаги се изпълнява, ако настъпи задействащото събитие. Идентификаторът на тригера рядко липсва, но се случва. Това означава, че преходът настъпва незабавно, което може да се наблюдава главно в активни състояния.

    Когато събитие възникне в определено състояние, тогава може да се направи само един преход от това състояние, например в състояние Lock (фиг. 10.1), защитите трябва да са взаимно изключващи се. Ако възникне събитие и няма разрешени преходи - например затваряне на сейф в състояние на изчакване или премахване на свещ, докато вратата е отворена - събитието се игнорира.

    Крайно състояние ( крайно състояние) означава, че крайната машина е приключила работата си, което води до изтриване на обекта на контролера. Така че за тези от вас, които не бяха достатъчно внимателни, за да попаднат в капана, тъй като обектът на контролера престава да съществува, ние сме принудени да върнем заека обратно в клетката му, да избършем пода и да рестартираме системата.

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

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

    Вътрешни дейности в диаграма на състоянието

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

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

    На фиг. 10.2 също показва специални дейности: входни и изходни дейности. входна дейностизпълнява се всеки път, когато влезете в държавата; изходна дейност– всеки път, когато напуснете щата. Вътрешни дейности обаче не започват входна и изходна дейност; това е разликата между вътрешни дейности исамопреходи .

    Състояния на дейност в диаграма на състоянието

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

    състояние Търсенена фиг. 10.3 е такова състояние състояние на активност: текущата дейност се обозначава със символа направи/; оттук и терминът правете дейност (Бъди активен). След приключване на търсенето се извършват преходи без активност, като например показване на ново оборудване (Показване на нов хардуер). Ако възникне събитие за отмяна по време на дейността ( анулиране), тогава извършване на дейностпросто се прекъсва и се връщаме в състоянието Прозорец за актуализиране на хардуера.

    Както правещите дейности, така и нормалните дейности представляват проява на някакво поведение. Основната разлика между двете е, че нормалните дейности се случват „мигновено“ и не могат да бъдат прекъснати от нормални събития, докато дейностите могат да се изпълняват за известно ограничено време и могат да бъдат прекъсвани, както е показано на фигура 2. 10.3. Мигновеността за различните системи се тълкува по различен начин; за системи в реално време това може да отнеме няколко машинни инструкции, а за настолен софтуер може да отнеме няколко секунди.

    AT UML 1обичайните дейности бяха обозначени с термина действие(действие) и срока дейност(дейност) се използва само за извършване на дейности.

    Супердържави

    Често се случва няколко държави да имат общи преходи и вътрешни дейности. В такива случаи можете да ги превърнете в подсъстояния (подсъстояния) и да прехвърлите цялостното поведение в суперсъстояние (суперсъстояние), както е показано на фиг. 10.4. Без супердържавата ще трябва да начертаем прехода анулиране(отказ) и за трите състояния в рамките на една държава Въведете подробности за връзката.

    Паралелни държави

    Състоянията могат да бъдат разделени на множество едновременни състояния, които се изпълняват по едно и също време. На фиг. Фигура 10.5 показва прост будилник, който може да включи CD или радио и да показва или текущото време, или времето на сигнала.

    Опциите за CD/радио и текущото време/времето за аларма са паралелни. Ако искахте да представите това с непаралелна диаграма на състоянието, ще завършите с разхвърляна диаграма, тъй като трябва да се добавят състояния. Разделянето на двете поведения в две диаграми на състоянието го прави много по-ясно.

    Ориз. 10.5 включва също праисторическо състояние(псевдосъстояние на историята). Това означава, че когато часовникът е включен, опцията за радио/CD се променя в състоянието, в което е бил часовникът, когато е бил изключен. Стрелка, излизаща от историята, показва коя държава е съществувала първоначално, когато не е имало история.

    Внедряване на диаграми на състояния

    Диаграмата на състоянието може да бъде реализирана по три основни начина: с помощта на вложен оператор за превключване, модел на състояние и таблица на състоянието. Най-прекият подход за работа с диаграми на състояния е вложен оператор за превключване, като този на Фигура 1. 10.6.

    Въпреки че този метод е ясен, той е много дълъг дори за този прост случай. Освен това с този подход е много лесно да загубите контрол, така че не препоръчваме да го използвате дори в елементарни ситуации.
    Моделът на състоянието представлява йерархия от класове на състояние за обработка на поведението на състоянието. Всяко състояние в диаграмата на състоянията има свой собствен подклас на състояния. Контролерът има методи за всяко събитие, които просто пренасочват към класа на състоянието. Диаграмата на състоянието, показана на фиг. 10.1 може да се реализира с помощта на класовете, показани на фиг. 10.7.

    Горната част на йерархията е абстрактен клас, който съдържа описание на всички методи, които обработват събития, но не и имплементация.
    За всяко конкретно състояние е достатъчно да пренапишете метода на манипулатора на конкретно събитие, което инициира прехода от състоянието.
    Таблицата на състоянието представя диаграмата на състоянието като данни.

    И така, диаграмата на фиг. 10.1 може да се представи под формата на таблица. 10.1.
    След това изграждаме интерпретатор, който използва таблицата на състоянието по време на изпълнение на програмата, или генератор на код, който генерира класове въз основа на тази таблица.

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

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

    Абонирайте се за новини на сайта, можете да намерите формата за абонамент в дясната колона на сайта.

    Ако искате да научите как да работите професионално на свободна практика, ви каним на курса "".