История на UML

Развитието на UML започна през октомври 1994 г., когато Грейди Бууч и Джим Ръмбо от Rational Software Corporation започнаха да работят заедно за обединяване на методите Booch и OMT (Object Modeling Technique). И двата метода се развиват независимо един от друг и с право се наричат ​​едни от най-добрите методи на обектно-ориентирания подход при разработването на софтуерни системи. Беше решено да се комбинират тези два метода и през октомври 1995 г. беше пусната бета версия, наречена Unified Method.

До края на 1996 г. стана ясно, че редица големи компании са готови да разглеждат UML като основна бизнес стратегия. Създаден е консорциум с нестопанска цел OMG (Object Modeling Group), който обединява водещи производители на софтуер като DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. През януари 1997 г. беше издаден UML 1.0. Скоро компании като IBM, Objectime, Platinum Technology и Softeam се присъединиха към OMG. В резултат на това сътрудничество се появи UML 1.1. През 2003 г. беше приета версия 1.5. 2004 г. – приета е версия 2.0

UML структура

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

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

На първо място, UML наследява техники от Booch, OMT и OOSE.

Второ, покрива ги.

Трето, трябва да се отбележи, че UML е езиков стандарт, а не стандарт за процеси.

Езикът UML включва набор от графични елементи, използвани в диаграми. Като език UML съдържа правила за комбиниране на тези елементи. Диаграмите се използват за показване на различни изгледи на система. Този набор от различни представяния се нарича модел. UML моделът описва какво ще трябва да направи системата. В същото време не се казва нищо за това как ще се реализира.

От най-обща гледна точка описанието на езика UML се състои от две взаимодействащи си части, като например:

Семантика на езика UML. Той представлява определен метамодел, който дефинира абстрактния синтаксис и семантиката на концепциите за моделиране на обекти в езика UML.

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

UML диаграми

Нека сега преминем към общ преглед на UML графичната нотация. Графичната нотация е картографиране на визуално представяне в семантиката на даден език. Както бе споменато по-рано, UML е квинтесенцията на трите техники за моделиране и по същество наследява тяхната графична нотация, като изхвърля малко използвани и неизразителни елементи и добавя нови, за да отговори на нуждите на съвременния пазар на софтуерни системи. При създаването на UML се опитахме да поддържаме баланс между простотата и разбираемостта на езика и неговата изразителна сила и прецизност. Моделът на разработваната система е набор от взаимосвързани подмодели, всеки от които е описан от набор от диаграми, описани с помощта на графична нотация, дефинирана в UML.

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

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

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

· Диаграми на поведение

o Диаграма на Statechart

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

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

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

§ Диаграма на сътрудничество

· Диаграми на изпълнение

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

o Диаграма на разгръщане

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

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

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

може да представлява различни нива на детайлност,

гарантира постигането на конкретна цел, която е важна за потребителя.

Случаят на употреба е обозначен на диаграмата с овал, свързан с потребители, които обикновено се наричат ​​актьори. Актьорите използват системата (или се използват от системата) в даден случай на употреба. Актьорът играе известна роля в този случай на употреба. Диаграмата изобразява само един актьор, но може да има много реални потребители, действащи в тази роля по отношение на IS. Списъкът с всички прецеденти всъщност определя функционалните изисквания към информационната система, които са в основата на разработването на технически спецификации за създаване на системата.

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

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

За да разрешат тази трудна ситуация, Стив Мелър и Мартин Фаулър независимо един от друг излязоха с определение три режима на използване на UMLот разработчици: режим скица, режим дизайни режим програмен език. Разбира се, най-важният от трите е начинът на използване. UML за скициране.В този режим разработчиците използват UML, за да комуникират информация за различни аспекти на системата. В режим на проектиране можете да използвате скици за напред и обратно инженерство. При директно развитие(перспективен инженеринг)диаграмите се чертаят преди кодирането и кога обратно инженерство(обратно инженерство)диаграмите са изградени въз основа на изходния код, за да го разберете по-добре.

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

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

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

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

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

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

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

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

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

Един от интересните въпроси относно UML като език за програмиране е въпросът за моделирането на поведенческата логика. UML 2 предлага три начина за моделиране на поведение: диаграми на взаимодействие, диаграми на състояния и диаграми на активност. Всички те имат своите поддръжници в областта на програмирането.

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

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

Няма строги правила за избор на гледна точка. Тъй като проблемът може да се разглежда от различни ъгли, има доста начини за прилагането му. Някои инструменти автоматично конвертират изходния код в диаграми, третирайки UML като алтернативна форма на изходния код. Това до голяма степен е програмна гледна точка. Ако UML диаграмите се използват за тестване и разбиране на различните значения на термините „пул от активи“ с група счетоводители, тогава трябва да се приеме много по-близък концептуален възглед.

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

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

Резюме:Бяха идентифицирани 3 режима на използване на UML.

1 - режим на скица. Изготвя се скица или на бъдещия код (тогава ще трябва да напишете код въз основа на модела), или на съществуващ (за да го разберете по-добре). Целта е бърз обмен на информация. Характеристика - избирателност. Не е важна пълнотата, важен е самият процес на обмен.

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

3 - режим на език за програмиране. Графичните диаграми се компилират в код, UML става изходният код.

Отговор от предишни години (Ден)

език Унифициран език за моделиране (UML)може да се счита за резултат от доста дълга и все още незавършена еволюция на методологиите за моделиране и проектиране.

Това обединение преследва три основни цели:

· моделиране на системата, от концепция до изпълним модул, използвайки обектно-ориентирани техники;

· разрешаване на проблеми с мащабиране в сложни системи;

· създаване на език за моделиране, използван както от хора, така и от компютри.

За какво се използва UML?

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

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

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

UML е език за документация.

UML диаграми

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

По-долу са дефинициите на диаграмите:

· Класова диаграма- структурна диаграма, показваща много класове, интерфейси, сътрудничество и връзки между тях;

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

· Диаграма на случаите на използване- диаграма на поведение, която показва много прецеденти и действащи лица, както и връзките между тях;

· Диаграма на взаимодействие:

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

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

· Диаграма на състоянието- диаграма на поведението, която показва машината и подчертава поведението на обектите по отношение на реда, в който се получават събитията;

· Диаграма на дейността- диаграма на поведението, която показва машината и подчертава преходите на контролния поток от една дейност към друга;

· Диаграма на компонентите- диаграма, която показва организацията на определен набор от компоненти и зависимостите между тях – отнася се за статистическия тип система;

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

Отговор от предишни години (Мадина)

Опция 1

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

Unified Modeling Language (UML) е език за специфициране, визуализиране, конструиране и документиране, базиран на обектно-ориентиран подход, на различни видове системи: софтуерни, хардуерни, софтуерно-хардуерни, смесени, изрично включващи човешки дейности и др.

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

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

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

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

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

Една класова диаграма може да включва три различни категории връзки: зависимост, обобщение и асоциация.

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

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

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

В тази диаграма класовете СтудентИ изследователполучени от същия суперклас ManFromUniversity. Към класа Студентсе отнасят до тези обекти от класа ManFromUniversity, които съответстват на учениците и на класа изследовател- клас обекти ManFromUniversity, съответстващ на изследователите. Често се случва, че много студенти вече започват да участват в изследователски проекти по време на студентските си години, така че може да има такива два обекта на класа СтудентИ изследовател, които съответстват на един обект от класа ManFromUniversity. Така сред обектите на кл Студентможе да са изследователи, а някои изследователи може да са студенти. След това можем да дефинираме класа StudentResearcherчрез множествено наследяване от суперкласове СтудентИ изследовател. Обект на класа StudentResearcherима всички свойства и операции на класовете СтудентИ изследователи може да се използва навсякъде, където могат да се използват обекти от тези класове. Така че включващият полиморфизъм продължава да работи. Това обаче води след себе си редица проблеми. Например при създаване на подкласове СтудентИ изследователи двете могат да имат дефиниран атрибут IP_адрес на компютъра. За класни обекти Студентстойностите на този атрибут ще бъдат IP адреса на компютъра от терминалния клас и за обектите от класа изследовател- IP адрес на компютъра на изследователската лаборатория. Освен това, за клас обект StudentResearcherИ двата атрибута с едно и също име могат да бъдат значими (студент изследовател може да има както IP адреса на компютър от терминален клас, така и IP адреса на компютър от изследователска лаборатория). На практика се използва едно от следните решения:

• забранява образуването на подклас StudentResearcherдокато атрибутът не бъде преименуван в един от суперкласовете IP_адрес на компютъра;
• наследяват това свойство само от един от суперкласовете, така че например стойността на атрибута IP_адрес на компютъраза класови обекти StudentResearcherвинаги ще бъде IP адресът на компютъра на изследователската лаборатория;
• Наследява и двете свойства в подклас, но автоматично преименува и двата атрибута, за да изясни значението им; именувайте ги, например IP_адрес на компютъра на ученикаИ IP_адрес на компютъра на изследователя.

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

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

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

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

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

Най-често срещаният начин за указване на множествеността на асоциативна роля е да се укаже конкретно число или диапазон. „1“ показва, че всеки обект от клас с дадена роля трябва да участва в някакъв екземпляр на тази асоциация и само един обект от клас с дадена роля може да участва във всеки екземпляр на асоциацията. Указването на диапазона "0..1" показва, че не всички обекти от клас с дадена роля са задължени да участват във всеки екземпляр на дадена асоциация, но само един обект може да участва във всеки екземпляр на асоциация. По същия начин, указването на диапазона "1..*" показва, че всички обекти от клас с дадена роля трябва да участват в някакъв екземпляр на тази асоциация и поне един обект трябва да участва във всеки екземпляр на асоциацията (не е посочена горна граница ). В по-сложни случаи на определяне на множествеността могат да се използват списъци с диапазони.

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

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

Има случаи, когато връзката между „частта” и „цялото” е толкова силна, че разрушаването на „цялото” води до унищожаване на всички негови „части”. Агрегирани асоциации с това свойство се наричат композитен, или просто композиции.

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

Диаграмите на класове могат да указват ограничения за интегритет, които трябва да се поддържат в проектираната база данни. UML позволява два начина за дефиниране на ограничения: на естествен език и на OCL (Език за ограничения на обекти).

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

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

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

1. Изразете в OCL ограничението, според което служители над 30 години трябва да работят в отдели с номера над 5

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

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

Вариант 2

1. RUP модел. Основни диаграми на RUP модела.

Rational Unified Process (RUP) е една от спиралните методологии за разработка на софтуер. Методологията се поддържа от Rational Software и продуктът се актуализира приблизително два пъти годишно. Унифицираният език за моделиране (UML) се използва като език за моделиране в общата база от знания.

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

Итеративно развитие;

Управление на изискванията;

Използване на модулни архитектури;

Визуално моделиране;

Проверка на качеството;

Проследяване на промените.

Графични представяния на системни модели в UML се наричат диаграми. По отношение на езика UML се дефинират следните типове:

· случай на употреба или диаграма на случай на употреба(диаграма на случаите на използване)

· класова диаграма(класова диаграма)

· диаграми на поведението(диаграми на поведение)

· диаграма на състоянието(диаграма на състоянието)

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

· диаграми на взаимодействие(диаграми на взаимодействие)

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

· диаграма на сътрудничество(диаграма на сътрудничество)

· диаграми за изпълнение(диаграми за изпълнение)

· компонентна диаграма(диаграма на компонентите)

· диаграма на разгръщане(диаграма на разполагане)

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

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

За UML диаграми има три вида визуални символи, които са важни по отношение на информацията, която съдържат:

· комуникации, които са представени от различни линии на равнината;

· текст, съдържащи се в границите на отделни геометрични форми;

· графични символи, изобразени близо до визуалните елементи на диаграмите.

· всяка диаграма трябва да бъде пълно представяне на някакъв фрагмент от моделираната предметна област;

· моделните обекти, представени на диаграмата, трябва да бъдат на едно и също концептуално ниво;

· цялата информация за обектите трябва да бъде ясно представена на диаграмата;

· диаграмите не трябва да съдържат противоречива информация;

· диаграмите не трябва да се претоварват с текстова информация;

· всяка диаграма трябва да е самодостатъчна за правилната интерпретация на всички нейни елементи;

· броят на типовете диаграми, необходими за описание на конкретна система, не е строго фиксиран и се определя от разработчика;

Системните модели трябва да съдържат само онези елементи, които са дефинирани

22. IC дизайн [J]

Тони е готов за отговор

Отговорите на Денис Ковалевич са актуализирани

Етап на изпълнение

Една от основните причини за неуспешни внедрявания е лошото развитие на проекта за ИС на етап управленско консултиране. В резултат на това информационната система се оказва недостатъчно интегрирана в цялостната система за управление на компанията.

· липса на подкрепа от ключовия персонал, особено когато трябва да се посвети достатъчно време и енергия на критичните етапи;

· твърде амбициозни планове вместо поетапен, мъдър подход;

· невъзможност за получаване на достатъчно съвети от практици с действителен опит в използването на подобни системи в подобни бизнеси.

Етап на операция

o ежедневна употреба;

Изхвърляне

Отговор от предишни години (Мадина)

Внедряване.

2.1. Изготвяне на технически проекти (ТП).

консултантите на изпълнителя и ИТ специалистите на клиента съставят ТП;

Клиентът одобрява TP.

Уточняват се обхватът на работата, времето и цената.

TP материали се използват при планиране и документиране на работата.

Състав на ТП:

структура на съхраняваните данни;

алгоритми;

използвани системни ресурси, тяхната структура и връзки;

потребителски интерфейс.

2.2. Планиране на работата.

В съответствие с утвърдените разпоредби

ръководителите на проекти на изпълнителя и клиента изготвят работни програми (РП);

клиентът и изпълнителят одобряват RP.

Изготвят се индивидуални планове за членовете на работния екип.

RP състав:

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

време за изпълнение;

отговорен за всеки елемент от RP.

2.3. Попълване на основни справочници.

Характеристики на сцената:

може да изисква от 1 до 18 месеца;

изисква централизация на въвеждането на информация;

е необходимо условие за функционирането на системата.

Методи за изпълнение:

конвертиране на данни;

ръчно въвеждане на данни от потребители (оператори).

2.4. Настройка, тестване, приемане.

Характеристики на сцената:

най-трудоемките и отговорни;

значително зависи от предварителната подготовка (наредби, технически спецификации, технически спецификации, RP);

изисква строга дисциплина както от страна на изпълнителя, така и от страна на клиента;

придружен от появата на допълнителни задачи от клиента;

изисква гъвкавост от страна на клиента и изпълнителя за преодоляване на конфликтни ситуации.

2.5. Пробна експлоатация.

Характеристики на сцената:

изисква бърза и надеждна реакция от страна на изпълнителя;

може да изисква значителни усилия от клиента (двойна работа);

има значителна продължителност (1-3 месеца);

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

2.6. Документация.

изготвяне на инструкции за потребителите;

изготвяне на правила за взаимодействие на отделите в системата;

финализиране на техническа документация;

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

2.7. Завършване на проекта.

правно прекратяване на договорни отношения;

окончателни финансови разчети;

вземане на решения за по-нататъшно сътрудничество: сключване на споразумения за техническа поддръжка и следгаранционна поддръжка, изпълнение на нови проекти.

IP рециклиране– извършва се с бутон DELETE.

Отговор от предишни години (Ден)

Етап на изпълнение

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

Ако на този етап възникнат проблеми, те са свързани със следните три основни причини:

липса на подкрепа от ключов персонал, особено когато трябва да се посвети достатъчно време и енергия на критичните етапи;

прекалено амбициозни планове вместо поетапен, мъдър подход;

липса на достатъчно съвети от практици с действителен опит в използването на подобни системи в подобни бизнеси.

Етап на операция

· Въвеждане на информационната система в експлоатация

o въвеждане в опитна експлоатация на техническото оборудване;

o въвеждане на софтуер в пробна експлоатация;

o обучение и сертифициране на персонала;

o провеждане на пробна експлоатация на компоненти и системата като цяло;

o въвеждане в експлоатация и подписване на актове за приемане на работа.

· Работа на информационната система

o ежедневна употреба;

o поддръжка на софтуер, хардуер и целия проект.

Етап на поддръжка (поддръжка).

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

Основните предварителни действия при подготовката за организиране на поддръжка на информационна система са:

· идентифициране на най-критичните компоненти на системата и определяне на критичността на времето на престой за тях (това ще позволи идентифициране на най-критичните компоненти на информационната система и оптимизиране на разпределението на ресурсите за поддръжка);

· идентифициране на задачите по поддръжката и тяхното разделяне на вътрешни, решавани от сервизния отдел, и външни, решавани от специализирани сервизни организации (по този начин се прави ясно дефиниране на обхвата на изпълняваните функции и разпределение на отговорностите);

· анализ на наличните вътрешни и външни ресурси, необходими за организиране на поддръжката в рамките на описаните задачи и разпределение на компетенциите (основни критерии за анализ: наличие на гаранция на оборудването, състояние на ремонтния фонд, квалификация на персонала);

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

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

Изхвърляне

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

Тази тема е разгледана много подробно на http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 и на http://www.rus-lib.ru/book/38/men/21 /2.3 .html

23. IC дизайн [J]

Свързана информация.

определение, подобно на това по-долу.

език- система от знаци, която служи за:

• средство за човешка комуникация и умствена дейност;
• начин за изразяване на самосъзнанието на човек;
• средство за съхранение и предаване на информация.

Езикът включва набор от знаци (лексика) и правила за тяхното използване и тълкуване (граматика).

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

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

1. синтаксис, тоест определяне на правилата за конструиране на езикови конструкции;
2. семантика, тоест дефинирането на правила, в съответствие с които езиковите структури придобиват семантично значение;
3. прагматика, тоест определяне на правилата за използване на езикови конструкции за постигане на целите, от които се нуждаем.

Освен това, горе-долу по същото време (началото на 80-те) започва „обектно-ориентираната ера“. Всичко започна с появата на фамилията езици за програмиране SmallTalk, която приложи някои от концепциите на езика Simula-67, използван през 60-те години. Появата на обектно-ориентирания подход се дължи главно на нарастващата сложност на проблемите. Обектно-ориентиран подходнаправи доста радикални промени в самите принципи на създаване и работа на програмите, но в същото време позволи значително да се увеличи производителностработата на програмистите, погледнете по различен начин проблемите и методите за решаването им, направете програмите по-компактни и лесно разширяеми. В резултат на това езиците, които първоначално са били ориентирани към традиционния подход към програмирането, получиха редица обектно-ориентирани разширения. Един от първите, в средата на 80-те, беше Apple с проекта си Object Pascal. Освен това, обектно-ориентиран подходгенерира мощна вълна от напълно нови софтуерни технологии, чиито върхове бяха такива общопризнати платформи като Microsoft. NET Framework и Sun Java.

Но най-важното е, че появата на ООП изисква удобен инструмент за моделиране, унифицирана нотация за описание на сложни софтуерни системи. И така „тримата приятели“, трима големи специалисти, трима автори на най-популярните методи, решиха да обединят своите разработки. През 1991 г. всеки от „тримата амиго“ започва с написването на книга, в която очертава своя OOAP метод. Всяка методология беше

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

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

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

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

UML е език

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

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

UML речник

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

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

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

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

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

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

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

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

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

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

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

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

Унифицираният език за моделиране (UML) е стандартен инструмент за създаване на „планове“ на информационни системи (IS). С помощта на UML можете да визуализирате, специфицирате, проектирате и документирате елементите на тези системи.

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

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

UML е език за визуализиране, специфициране, конструиране и документиране на елементи от софтуерни системи. Езикът се състои от речник и правила, които ви позволяват да комбинирате думите, които съдържа, и да създавате смислени конструкции. В езика за моделиране речникът и правилата се фокусират върху концептуалното и физическо представяне на системата. Език за моделиране като UML е стандартен инструмент за изготвяне на IC "чертежи".

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

Използването на UML решава третия проблем: изричният модел прави комуникацията по-лесна.

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

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

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

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

При разработването на ИС елементи като:

• Системни изисквания;
• описание на архитектурата;
• проект;
• източник;
• проектни планове;
• тестове;
• прототипи;
• версии и др.

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

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

Къде се използва UML

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

• Информационни системи в мащаб на предприятието;
• банкови и финансови услуги;
• телекомуникации;
• транспорт;
• отбранителна промишленост, авиация и космонавтика;
• на дребно;
• медицинска електроника;
• науката;
• разпределени уеб системи.

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

UML концептуален модел

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

UML градивни блокове

UML речникът включва три типа градивни елементи:

• есенции;
• връзка;
• диаграми.

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

В UML има четири типа обекти:

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

Обектите са основните обектно-ориентирани блокове на езика. С тяхна помощ можете да създавате правилни модели. Има седем вида структурни единици:

• Клас
• Интерфейс
• Сътрудничество
• Случай на употреба
• Активен клас
• Компонент
• Възел

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

Поведенческите неща са динамичните компоненти на UML модела. Това са глаголи на езика: те описват поведението на модела във времето и пространството. Има само два основни типа поведенчески субекти:

• Взаимодействие
• Държавна машина

Тези два елемента на взаимодействие и автомати са основните поведенчески обекти, включени в UML модела. Семантично те често се свързват с различни структурни елементи, предимно класове, сътрудничества и обекти.

Групиращите обекти са организиращите части на UML модел. Това са блокове, на които моделът може да бъде разложен. Има само един първичен групиращ обект, а именно найлонов плик.

Пакетите са основните групиращи обекти, които могат да се използват за организиране на UML модел.Съществуват и варианти на пакети, като Frameworks, модели и подсистеми.

Анотационни обекти— обяснителни части на UML модела. Това са коментари за предоставяне на допълнително описание, пояснение или коментар на който и да е елемент от модела. Има само един основен тип анотационен елемент: Забележка. Бележката е просто символ за представяне на коментари или ограничения, прикрепени към елемент или група от елементи. Графично бележката се изобразява като правоъгълник с извит ръб, съдържащ текст или графичен коментар.

UML дефинира четири типа релации:

• пристрастяване;
• асоциация;
• генерализация;
• изпълнение.

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

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

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

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

Правила на езика UML

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

Езикът UML има семантични правила, които ви позволяват да дефинирате правилно и недвусмислено:

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

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

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

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

Общи UML механизми

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

• спецификации (Спецификации);
• добавки (украси);
• общи деления;
• Механизми за разширяване.

Архитектура

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

Архитектурата е набор от важни решения относно:

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

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

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

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

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

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

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

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