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

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

10.4. UML ДИЈАГРАМИ 10.4.1. Видови визуелни дијаграми UMLUML ви овозможува да креирате неколку типови на визуелни дијаграми: користете дијаграми на случаи; дијаграми за низа; кооперативни дијаграми; дијаграми за часови; дијаграми на состојби; дијаграми

1.2.6. Рамка на дијаграмот на сл. Слика 1.2.26 покажува типичен пример на дијаграм на распаѓање со гранични кутии наречени рамка на дијаграмот. Ориз. 1.2.26. Пример за дијаграм на распаѓање со жичана рамка Жичната рамка содржи заглавие (горниот дел на рамката) и подножјето (долу).

Дијаграми за тајминг За да ги добиете временските дијаграми на влезниот и излезниот напон, треба малку да ја измените влезната датотека. Како и во претходниот пример, ќе се користи синусоидален влезен напон: Vi 1 0 sin (0 0. 5V 5kHz) Заедно со минлива анализа

Табели и графикони Само експерт може да го распознае значењето зад бескрајните редови на броеви, но секој може да разбере (или барем да тврди дека разбира) хистограм или пита шема. VBA нема вградени алатки за креирање дијаграми, туку такви

5.1.14. Графикони Графиконите се графички прикази на нумерички податоци во табела. Pages нуди неколку типови графикони: колона, наредена колона, дијаграм со ленти, дијаграм со наредени ленти, линија, област, наредена област

5.2.8. Графикони Графиконот е графички приказ на податоци од избраниот опсег За да изградите графикон, следете го следниов алгоритам1. Направете табела со пресметани вредности.2. Изберете го саканиот опсег (може да се состои од несоседни правоаголни

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

Има многу добри книги кои детално го опишуваат UML (понекогаш дури и со големи детали), би сакал на едно место да ги соберам основните концепти за дијаграмите, ентитетите и врските меѓу нив за брзо потсетување, нешто како лист за измама.

Оваа статија користи материјали од книгите: Иванов Д. Ју., Новиков Ф. А. Унифициран јазик за моделирање UMLИ Леоненков. Упатство за UML.

Прво, да одлучиме за уредникот. Под Linux, пробав различни UML уредници, најмногу ми се допадна UMLet, иако е напишан во Java, се движи многу брзо и ги содржи повеќето шаблони за ентитети. Исто така постои и ArgoUML, UML-уредувач на повеќе платформи, исто така напишан во Java, кој е функционално богат, но повеќе го успорува.

Застанав на UMlet, инсталирајте го под Арх ЛинуксИ Убунту:

# на Arch Linux yaourt -S umlet # на Ubuntu sudo apt-get install umlet

Во UML, сите ентитети може да се поделат на следниве типови:

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

Постојат четири главни типа на врски што се користат во UML:

Зависност- укажува дека промената во независен ентитет некако влијае на зависен ентитет. Графички, односот на зависност е прикажан како испрекината линија со стрелка насочена од зависниот ентитет кон независниот.

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

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

Имплементации- Односот за имплементација покажува дека еден ентитет е имплементација на друг. Графички, имплементацијата е прикажана како испрекината линија со триаголна, непополнета стрелка на крајот, насочена од ентитетот имплементатор до ентитетот што се спроведува.

ВО UML 2дефинирани 13 видови на дијаграми. Според стандардите, секој дијаграм мора да има рамка со правоаголник (закосен долен десен агол) во горниот лев агол, што ги означува идентификаторот (ознаката) на дијаграмот и насловот.

Дијаграми за прикажување на структурата на системот:

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

Дијаграми за прикажување на однесувањето на системот:

• Дијаграм за синхронизација (дијаграм за интеракција, ознака тајмингот);
• Дијаграм на активност (ознака активност);
• Дијаграм на низа, ознака SD);
• Дијаграм за комуникација (ознака ком);
• Дијаграм на состојбата на машината, ознака државна машина);
• дијаграм за преглед на интеракција, ознака интеракција);

Дијаграмите се издвојуваат:

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

Дијаграм за користење

Дијаграм за користење(дијаграм за случаи на употреба) е најопшт приказ на функционалната намена на системот.

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

Дијаграмот за употреба користи два вида основни ентитети: случаи на употреба и актери, меѓу кои се воспоставуваат следните основни типови на односи.

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

Релација на проширување- ја дефинира врската помеѓу примерите на одреден случај на употреба и случајот со поопшта употреба, чии својства се одредуваат врз основа на начинот на кој овие примери се комбинираат заедно. Така, ако постои проширен однос од случајот на употреба А до случајот на употреба Б, тогаш тоа значи дека својствата на примерот на употреба случај Б може да се прошират поради присуството на својства во случајот со продолжена употреба А.

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

Релација на генерализацијаслужи за да укаже на фактот дека некои случаи на употреба А може да се генерализираат за употребата на случајот Б. Во овој случај, опцијата А ќе биде специјализација на опцијата Б. Во овој случај, Б се нарекува предок или родител на А, а опцијата А е дете на опција за употреба В.

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

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

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

Врската на вклучување насочена од случајот на употреба А до случајот на употреба Б покажува дека секој примерок од случајот на употреба А ги вклучува функционалните својства наведени за случајот на употреба Б.

Графички, оваа врска е означена со испрекината линија со стрелка (варијанта на односот на зависност) насочена од случајот за основна употреба до вклучената.

Дијаграм за класа

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

Класниот дијаграм користи еден главен тип на ентитет: класи (вклучувајќи бројни специјални случаи на класи: интерфејси, примитивни типови, класи на асоцијација итн.), меѓу кои се воспоставуваат следните главни типови на врски: зависности, асоцијации, генерализации, имплементации.

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

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

Може да има посебни клучни зборови (стереотипи) над стрелката:

• „пристап“ - служи за означување на достапноста на јавните атрибути и операции на изворната класа за класите на клиентите;
• "bind" - класата на клиентот може да користи некој шаблон за неговата последователна параметризација;
• „изведе“ - атрибутите на класата на клиентот може да се пресметаат од атрибутите на изворната класа;
• „увоз“ - јавните атрибути и операции на изворната класа стануваат дел од класата на клиентот, како да се декларирани директно во неа;
• „Рафинирај“ - означува дека класата на клиентот служи како рафинирање на изворната класа од историски причини кога се појавуваат дополнителни информации во текот на работата на проектот.

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

Агрегациска врскасе јавува помеѓу неколку класи ако една од класите претставува ентитет кој вклучува други ентитети како компоненти. Се користи за претставување на системски односи од типот „дел-цела“.

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

Релација на генерализацијае однос помеѓу поопшт елемент (родител или предок) и поспецифичен или специјализиран елемент (дете или потомок). Кога се применува на класичен дијаграм, оваа врска ја опишува хиерархиската структура на класите и наследството на нивните својства и однесување. Ова претпоставува дека класата потомок ги има сите својства и однесување на класата на предците, а исто така има свои својства и однесување што класата предци ги нема.

Дијаграм на машината

Дијаграм на машината(дијаграм на состојбата на машината) или дијаграм на состојбиво UML 1 (дијаграм на табелата со состојби) е еден начин детално да се опише однесувањето во UML. Во суштина, машинските дијаграми, како што сугерира името, се график на состојби и транзиции на машина со конечни состојби натоварени со многу дополнителни детали и детали.

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

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

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

Финале (финале)држава е посебен случај на држава која исто така не содржи никакви внатрешни дејства (псевдо-состојби). Објектот стандардно ќе биде во оваа состојба откако машината ќе ја заврши својата работа во последниот момент во времето.

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

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

Дијаграм на активност(дијаграм на активност) е уште еден начин за опишување на однесување кое визуелно наликува на стариот добар дијаграм на тек на алгоритам. Се користи за моделирање на процесот на извршување на операции.

Главната употреба на дијаграмите на активности е да се визуелизираат карактеристиките за имплементација на операциите на класата, кога е неопходно да се претстават алгоритми за нивна имплементација.

Дијаграмот на активности користи еден главен тип на ентитет - акција, и еден тип на врска - транзиции (пренос на контрола). Се користат и конструкции како вилушки, спојувања, врски и гранки. Се препорачува да се користи глагол со објаснувачки зборови како име на едноставно дејство.

Дијаграм за низа

Дијаграм за низа(дијаграм на секвенца) е начин да се опише однесувањето на системот „користејќи примери“.

Всушност, секвенцискиот дијаграм е запис од протоколот на одредена сесија на системот (или фрагмент од таков протокол). Во објектно-ориентираното програмирање, најважното нешто за време на извршувањето е пренесувањето на пораките помеѓу објектите што комуницираат. Тоа е низата на испраќање пораки што е прикажана на овој дијаграм, па оттука и името.

Секвенцискиот дијаграм користи еден основен тип на ентитет - примери на интеракции на класификатори (главно класи, компоненти и актери) и еден тип на врска - врски по кои се разменуваат пораките.

Можни видови пораки (слика преземена од larin.in):

Дијаграм за комуникација

Дијаграм за комуникација(комуникациски дијаграм) - начин на опишување на однесување што е семантички еквивалентно на дијаграм на секвенца. Всушност, ова е истиот опис на низата на размена на пораки на интерактивни примери на класификатори, изразена само со други графички средства.

Така, во комуникацискиот дијаграм, како и во дијаграмот на секвенца, се користи еден главен тип на ентитети - инстанци на класификатори кои дејствуваат и еден тип на односи - врски. Меѓутоа, овде акцентот не е на времето, туку на структурата на врските помеѓу конкретните инстанци.

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

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

Главниот тип на ентитети во компонентен дијаграм се самите компоненти, како и интерфејсите преку кои се специфицирани односите помеѓу компонентите. Следниве односи се применуваат во дијаграмот на компонентите:

• имплементации помеѓу компоненти и интерфејси (компонента имплементира интерфејс);
• зависности помеѓу компонентите и интерфејсите (компонентата го користи интерфејсот);

Дијаграм за поставување

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

Дијаграмот за распоред, во споредба со компонентен дијаграм, додава два вида ентитети: артефакт, кој е имплементација на компонента и јазол (може да биде или класификатор што го опишува типот на јазол или специфичен пример) и врска на асоцијација помеѓу јазлите, што покажува дека јазлите физички се поврзани за време на извршувањето.

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

Дијаграм на објектот(објект дијаграм) - е инстанца на дијаграм на класа.

Објектен дијаграм користи еден главен тип на ентитет: објекти (инстанци на класи), меѓу кои се означени специфични врски (најчесто примери на асоцијации). Дијаграмите за објекти се од помошна природа - всушност, ова се примери (мемориски депонии, може да се каже) кои покажуваат кои предмети се достапни и врските меѓу нив во одреден момент од работата на системот.

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

Структурен класификатор е прикажан како правоаголник со името на класификаторот на врвот. Внатре има делови. Може да има неколку делови. Деловите можат да комуницираат едни со други. Ова е означено со употреба на конектори од различни типови. Локацијата на надворешната граница на делот на кој се прицврстува конекторот се нарекува порта. Пристаништата се наоѓаат и на надворешната граница на структурниот класификатор.

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

Тајминг дијаграм

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

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

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

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

Модел на врска со ентитет (ER модел)

Аналоген дијаграми за часови(UML) можеби ЕР модел, кој се користи при дизајнирање бази на податоци (релациски модел).

Моделот на ентитет-врска (ER-модел) е модел на податоци кој ви овозможува да опишете концептуални дијаграми на предметна област. Моделот ER се користи при дизајнирање на бази на податоци на високо ниво (концептуално). Со негова помош, можете да ги идентификувате клучните ентитети и да ги идентификувате врските што може да се воспостават помеѓу овие ентитети. википедија

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

Основни концепти:

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

Комплет ентитети(ентитет множество) - збир на ентитети од ист тип (со исти својства).

Поврзување(врска) е асоцијација воспоставена помеѓу повеќе субјекти.

Домен(домен) - збир на вредности (домен на дефиниција) на атрибутот.

Постојат три типа на бинарни врски:

• еден до еден- единствена инстанца на ентитет од една класа е поврзана со една инстанца на ентитет од друга класа, на пример, HEAD - DEPARTMENT;
• 1 до Нили еден до многу- еден примерок на ентитет од една класа е поврзан со многу примероци на ентитет од друга класа, на пример, ОДДЕЛЕНИЕ - ВРАБОТЕН;
• Н до Мили многу на многу- многу примероци на ентитет од една класа се поврзани со многу примероци на ентитет од друга класа, на пример, ВРАБОТЕН - ПРОЕКТ;
Речник на основни поими во UML

Објект- ентитет кој е уникатен и ја опфаќа состојбата и однесувањето.

Класа- опис на збир на објекти со заеднички атрибути кои ја дефинираат состојбата и операции кои го дефинираат однесувањето.

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

Соработка- збир на предмети кои комуницираат за да постигнат некоја цел.

Актер- ентитет лоциран надвор од моделираниот систем и директно во интеракција со него.

Компонента- модуларен дел од системот со јасно дефиниран сет на потребни и обезбедени интерфејси.

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

Јазол- компјутерски ресурс на кој се наоѓаат артефактите и, доколку е потребно, се извршуваат.

Бихејвиоралните ентитети се наменети да го опишат однесувањето. Постојат само два главни бихејвиорални ентитети: состојба и акција.

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

Акција- примитивна атомска пресметка.

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

Класификаторе дескриптор на збир на објекти од ист тип.

Дополнително читање

• Фаулер М. УМЛ. Основи, трето издание
• Buch G., Rambo D., Jacobson I. UML јазик. Упатство за корисникот

Во моментов, UML е стандардна нотација за визуелно моделирање на софтверски системи, усвоена од конзорциумот за управување со објекти (OMG) во есента 1997 година, што е поддржано од многу објектно-ориентирани производи CASE.

Стандардот UML го нуди следниот сет на дијаграми за моделирање:

· дијаграм на случаи на употреба – за моделирање на деловните процеси на организација или претпријатие и одредување на барањата за информацискиот систем што се креира;

· дијаграм на класи – за моделирање на статичка структура на системски класи и врски меѓу нив;

· дијаграми на однесување на системот;

· дијаграми за интеракција;

· дијаграми за секвенца – за моделирање на процесот на испраќање пораки помеѓу објекти во рамките на еден случај на употреба;

· дијаграм за соработка – за моделирање на процесот на испраќање пораки помеѓу објекти во рамките на еден случај на употреба;

· дијаграм на состојба – за моделирање на однесувањето на системските објекти при преминот од една во друга состојба;

· дијаграм на активности – за моделирање на однесувањето на системот во рамките на различни случаи на употреба, или активности за моделирање;

дијаграми за имплементација:

· дијаграми на компоненти – за моделирање на хиерархија на компоненти (потсистеми) на информациски систем;

· дијаграм на распоредување – за моделирање на физичката архитектура на дизајнираниот информациски систем.

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

Ориз. 1. Интегриран модел на информациски систем во UML нотација

4.2. Користете дијаграм на случај

Случај за употреба е низа од дејства извршени од системот како одговор на настан инициран од некој надворешен објект (актер). Случај за употреба опишува типична интеракција помеѓу корисникот и системот. Во наједноставниот случај, случајот на употреба се одредува во процесот на разговор со корисникот за функциите што тој би сакал да ги имплементира во овој информациски систем. Во UML, случајот на употреба е прикажан на следниов начин:

Сл.2. Случај за употреба

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

Сл.3. Лик (актер)

Актерите се поделени во три главни типа:

· корисници;

· системи;

· други системи во интеракција со овој;

Времето станува актер ако од него зависи започнувањето на какви било настани во системот.

4.2.1. Односите помеѓу случаите на употреба и актерите

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

· комуникација

вклучување (вклучува),

· продолжување (проширување),

· генерализација.

комуникациска врскае односот помеѓу употребен случај и актер. Во UML, комуникациските односи се прикажани со користење на еднонасочна асоцијација (цврста линија).

Сл.4. Пример за врска за комуникација

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

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

Сл.5. Пример за однос на вклучување и проширување

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

Сл.6. Пример за врска со генерализација

4.3.

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

Поракае средство со кое објектот што испраќа бара од објектот на примачот да изврши една од неговите операции.

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

Порака за барање (прашална)е порака со која се бара објавување на некои информации за објектот на примачот.

Императивна поракае порака која бара од објектот на примачот да изврши некое дејство.

Постојат два типа на дијаграми за интеракција: дијаграми за низа и дијаграми за соработка.

4.3.1. Дијаграми за низа

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

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

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

Секоја порака е претставена како стрелка помеѓу животните линии на два објекти. Пораките се појавуваат по редоследот по кој се појавуваат на страницата од врвот до дното. Секоја порака е означена со барем име на пораката. Доколку сакате, можете исто така да додадете аргументи и некои контролни информации. Може да покажете самоделегирање - порака што објектот си ја испраќа, со стрелката на пораката која покажува на истата животна линија.

Ориз. 7. Пример за дијаграм на низа

4.3.2. Дијаграм за соработка

Дијаграми за соработкаприкажување на текот на настаните во рамките на одредено сценарио (случај на употреба). Пораките се подредени според времето, иако дијаграмите за соработка повеќе се фокусираат на врските помеѓу објектите. Дијаграмот за соработка ги прикажува сите информации што се присутни во секвенцискиот дијаграм, но дијаграмот за соработка различно го опишува текот на настаните. Тоа го олеснува разбирањето на врските што постојат помеѓу објектите.

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

Ориз. 8. Пример за дијаграм за соработка

4.4. Дијаграм за класа

4.4.1. Генерални информации

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

Класен дијаграм во јазикот UML е график, чии јазли се елементи на статичката структура на проектот (класи, интерфејси), а лаковите се односите помеѓу јазлите (асоцијации, наследство, зависности).

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

· Пакет - збир на елементи на моделот логично поврзани едни со други;

· Класа (класа) - опис на заедничките својства на група слични објекти;

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

4.4.2. Класа

Класае група на ентитети (објекти) кои имаат слични својства, имено, податоци и однесување. Поединечен претставник на класа се нарекува објект на класата или едноставно објект.

Однесувањето на објектот во UML се однесува на какви било правила за интеракција на објектот со надворешниот свет и со податоците на самиот објект.

На дијаграмите, класата е прикажана како правоаголник со цврста граница, поделена со хоризонтални линии на 3 дела:

Горниот дел (дел за име) го содржи името на класата и други општи својства (особено, стереотипот).

Средниот дел содржи листа на атрибути

На дното е листа на операции на класата кои го одразуваат нејзиното однесување (дејства извршени од класата).

Може да не се прикаже кој било од атрибутите и деловите за работа (или и двете одеднаш). За дел што недостасува, не треба да цртате линија на поделба или на кој било начин да означите присуство или отсуство на елементи во неа.

Дополнителни делови, како што се исклучоци, може да се воведат по дискреција на конкретната имплементација.

Ориз. 9. Пример за класен дијаграм

4.4.2.1.Класни стереотипи

Класните стереотипи се механизам за поделба на класите во категории.

UML дефинира три главни стереотипи за класа:

Граница (граница);

Субјект (ентитет);

Контрола.

4.4.2.2.Гранични класи

Гранични класи се оние класи кои се наоѓаат на границата на системот и целата околина. Тие вклучуваат дисплеи, извештаи, интерфејси со хардвер (како што се печатачи или скенери) и интерфејси со други системи.

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

4.4.2.3.Класи на ентитети

Класите на ентитети содржат зачувани информации. Тие имаат најголемо значење за корисникот, и затоа нивните имиња често користат термини од предметната област. Вообичаено, табела се креира во базата на податоци за секоја класа на ентитети.

4.4.2.4.Контролни часови

Контролните класи се одговорни за координирање на активностите на другите класи. Вообичаено, секој случај на употреба има една контролна класа која ја контролира низата на настани за тој случај на употреба. Класата менаџер е одговорна за координација, но самата не обезбедува никаква функционалност, бидејќи другите класи не испраќаат многу пораки до неа. Наместо тоа, тој самиот испраќа многу пораки. Класата менаџер едноставно делегира одговорност на други класи, поради што често се нарекува менаџерска класа.

Може да има други контролни класи во системот кои се вообичаени за случаите за повеќекратна употреба. На пример, може да има класа SecurityManager која е одговорна за следење на настани поврзани со безбедноста. Класата TransactionManager е одговорна за координирање на пораките поврзани со трансакциите со базата на податоци. Може да има и други менаџери за да се справат со други елементи од функционирањето на системот, како што се споделување ресурси, дистрибуирана обработка на податоци или справување со грешки.

Покрај стереотипите споменати погоре, можете да креирате свои.

4.4.2.5.Атрибути

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

Бидејќи атрибутите се содржани во класата, тие се скриени од другите класи. Поради ова, можеби ќе треба да одредите кои класи имаат право да читаат и менуваат атрибути. Ова својство се нарекува видливост на атрибутот.

Атрибутот може да има четири можни вредности за овој параметар:

Јавно (општо, отворено). Оваа вредност за видливост претпоставува дека атрибутот ќе биде видлив за сите други класи. Секоја класа може да ја гледа или менува вредноста на атрибутот. Според ознаката UML, на заедничкиот атрибут му претходи знакот „+“.

Приватен (затворен, таен). Соодветниот атрибут не е видлив за ниедна друга класа. Приватен атрибут се означува со знак „–“ според ознаката UML.

Заштитен (заштитен). Овој атрибут е достапен само за самата класа и нејзините потомци. Ознаката UML за заштитен атрибут е знакот „#“.

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

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

4.4.2.6.Операции

Операциите имплементираат однесување поврзано со класа. Операцијата има три дела: име, параметри и тип на враќање.

Параметрите се аргументи кои ги прима операцијата како влез. Типот на враќање се однесува на резултатот од операцијата.

Класниот дијаграм може да ги прикаже и имињата на операциите и имињата на операциите заедно со нивните параметри и типот на враќање. За да се намали оптоварувањето на дијаграмот, корисно е да се прикажат само имињата на операциите на некои од нив, а нивниот целосен потпис на други.

Во UML, операциите ја имаат следната нотација:

Име на операцијата (аргумент: тип на податок аргумент, аргумент2:тип на податок аргумент2,...): тип на враќање

Постојат четири различни типови на операции што треба да се земат предвид:

Операции за имплементација;

Менаџмент операции;

Операции за пристап;

Помошни операции.

Операции за имплементација

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

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

Контролни операции

Менаџерските операции го контролираат создавањето и уништувањето на објекти. Конструкторите и деструкторите на класи спаѓаат во оваа категорија.

Операции за пристап

Атрибутите обично се приватни или заштитени. Меѓутоа, другите класи понекогаш треба да ги видат или променат нивните вредности. Постојат операции за пристап за оваа намена. Овој пристап овозможува безбедно да се инкапсулираат атрибутите во класата, заштитувајќи ги од други класи, но сепак дозволувајќи контролиран пристап до нив. Стандардно е да се креираат операции Get и Set за секој атрибут на класа.

Помошни операции

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

За да ги идентификувате трансакциите, следете ги овие чекори:

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

2. Размислете за контролните операции. Можеби ќе треба да додадете конструктори и деструктори.

3. Размислете за операциите за пристап. За секој атрибут на класа со кој ќе треба да работат другите класи, треба да креирате операции Get and Set.

4.4.2.7.Врски

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

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

Здружение за комуникација

Асоцијацијата е семантичка врска помеѓу класите. На класниот дијаграм се нацртани како обична линија.

Ориз. 10. Здружение за комуникација

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

Насоката на асоцијација може да се одреди со испитување на дијаграми за секвенца и дијаграми за соработка. Ако сите пораки на нив се праќаат само од една класа и ги прима само друга класа, но не и обратно, постои еднонасочна комуникација помеѓу овие класи. Ако барем една порака е испратена во спротивна насока, асоцијацијата мора да биде двонасочна.

Асоцијациите можат да бидат рефлексивни. Рефлексивната асоцијација вклучува еден пример на класа во интеракција со други примероци од истата класа.

Зависност од комуникација

Односите на зависност исто така ги рефлектираат односите помеѓу класите, но тие се секогаш еднонасочни и покажуваат дека една класа зависи од дефинициите направени во друга. На пример, класата А користи методи од класата Б. Тогаш кога класата Б се менува, потребно е да се направат соодветни промени во класата А.

Зависноста е претставена со испрекината линија нацртана помеѓу два елементи на дијаграмот, а елементот закотвен на крајот од стрелката се вели дека зависи од елементот закотвен на почетокот на таа стрелка.

Ориз. 11. Зависност од комуникација

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

Комуникациска агрегација

Агрегациите се построга форма на здружување. Агрегацијата е врска помеѓу целината и нејзиниот дел. На пример, може да имате класа наречена Автомобил, како и класи како мотор, гуми и часови за други делови од автомобилот. Како резултат на тоа, објект од класата Car ќе се состои од објект од класата Engine, четири објекти Tyre итн. Агрегациите се визуелизираат како линија со дијамант во близина на класата, што е цел број:

Ориз. 11. Комуникациска агрегација

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

Ова каскадно бришење често се смета за дел од дефиницијата за агрегација, но секогаш се подразбира кога множеството на улоги е 1..1; на пример, ако е неопходно да се избрише клиент, тогаш ова бришење мора да важи и за нарачките (и, пак, за линиите за нарачки).

        Унифициран јазик за моделирање (UML) е јазик за специфицирање, визуелизирање, конструирање и документирање на софтверски системи, како и деловни модели и други несофтверски системи. UML е комбинација на инженерски техники кои претходно биле успешно користени за моделирање на големи и сложени системи

        Креаторите на UML го претставуваат како јазик за дефинирање, претставување, дизајнирање и документирање на софтверски системи, деловни системи и други системи од различна природа. UML дефинира нотација и метамодел. Нотација е збирка на графички објекти кои се користат во моделите; тоа е синтаксата на јазикот за моделирање.

        UML обезбедува експресивни алатки за создавање визуелни модели кои:

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

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

• не зависи од објектно-ориентирани (OO) програмски јазици;
• не зависи од користената методологија за развој на проектот;
• може да поддржува кој било програмски јазик ОО.

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

UML дијаграми

        Rational Rose ги обезбедува следниве видови дијаграми на располагање на дизајнерот на системот, чие последователно создавање ви овозможува да добиете целосна слика за целиот дизајниран систем и неговите поединечни компоненти:

• Користете дијаграм на случај;
• Дијаграм за распоредување (тополошки дијаграми);
• Дијаграм на државна шема;
• Дијаграм за интеракција; Дијаграм на активност;
• Дијаграм за низа;
• Дијаграм за соработка;
• Дијаграм за часови;
• Компонентен дијаграм (компонентни дијаграми);
• Дијаграми на однесување;
• Дијаграм на активност;
• Дијаграми за имплементација;

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

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

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

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

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

• секој дијаграм мора да биде комплетен приказ на некој фрагмент од моделираната предметна област;
• ентитетите на моделот прикажани на дијаграмот мора да бидат на исто концептуално ниво;
• сите информации за субјектите мора да бидат јасно претставени на дијаграмот;
• дијаграмите не треба да содржат конфликтни информации;
• дијаграмите не треба да се преоптоваруваат со текстуални информации;
• секој дијаграм мора да биде самодоволен за правилно толкување на сите негови елементи;
• бројот на типови дијаграми потребни за опишување на одреден систем не е строго фиксиран и го одредува развивачот;
• системските модели треба да ги содржат само оние елементи што се дефинирани во ознаката UML.

Ентитети во UML

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

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

        Ентитети на однесувањесе динамични компоненти на UML моделот. Тоа се глаголи кои го опишуваат однесувањето на моделот во времето и просторот. Постојат два главни типа на бихејвиорални ентитети:

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

        Групирање ентитетисе организационите делови на UML моделот. Тоа се блокови во кои моделот може да се разложи. Таков примарен ентитет постои во една копија - ова е пакет.

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

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

Врски во UML

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

        Зависност- ова е семантички однос помеѓу два ентитета, во кој промената на еден од нив, независен, може да влијае на семантиката на другиот, зависен.

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

        Генерализацијае однос во кој специјализиран елемент објект (потомок) може да се замени за генерички елемент објект (предок). Во исто време, во согласност со принципите на објектно-ориентираното програмирање, потомок (дете) ја наследува структурата и однесувањето на својот предок (родител).

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

• помеѓу интерфејсите и класите или компонентите што ги имплементираат;
• помеѓу преседани и соработки што ги спроведуваат.

Заеднички UML механизми

        За прецизно опишување на систем во UML, се користат таканаречените општи механизми:

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

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

        Речиси секој UML елемент има уникатна графичка претстава која дава визуелна претстава за неговите најважни карактеристики. Ознаката на ентитетот „класа“ го содржи неговото име, атрибути и операции. Спецификацијата на класата може да содржи други детали, како што се видливоста на атрибутите и операциите, коментари или индикација дека класата е апстрактна. Многу од овие детали може да се визуелизираат како графика или текст. дополнувањадо стандарден правоаголник што ја претставува класата.

        При моделирање објектно-ориентирани системи, постои одреден поделбазастапени субјекти.

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

        Второ, постои поделба на интерфејс и неговата имплементација. Интерфејсот ги декларира обврските, а имплементацијата претставува конкретна имплементација на тие заложби и осигурува дека декларираната семантика точно се следи. Поради ова, скоро сите UML конструкции се карактеризираат со двојност на интерфејс/имплементација. На пример, преседани се спроведуваат со соработки, а операциите се спроведуваат со методи.

        UML е отворен јазик, односно дозволува контролираните екстензии да ги рефлектираат карактеристиките на моделите на домени.

        механизмите за проширување на UML вклучуваат:

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

        Заедно, овие три механизми за проширување на јазиците ви овозможуваат да го менувате во согласност со потребите на проектот или карактеристиките на технологијата за развој.

Користете дијаграм на случај

        Овој тип на дијаграм ви овозможува да креирате листа на операции што ги извршува системот. Често овој тип на дијаграми се нарекува дијаграм на функции, бидејќи врз основа на множество од такви дијаграми се креира листа на барања за системот и се одредува множеството на функции што ги извршува системот.

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

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

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

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

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

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

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

класа дијаграм

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

        Иконите на дијаграмот ви дозволуваат да прикажете сложена хиерархија на системи, односи помеѓу класи (класи) и интерфејси (интерфејси). Овој тип на дијаграм е спротивен по содржина на дијаграмот за соработка, кој ги прикажува системските објекти. Rational Rose ви овозможува да креирате класи користејќи овој тип на дијаграми во различни ознаки. слично на облак. Така, класата е само шаблон според кој во иднина ќе се креира одреден објект.

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

        Класаво UML, се користи за означување на збир на објекти кои имаат иста структура, однесување и односи со објекти од други класи. Графички, класата е прикажана како правоаголник, кој дополнително може да се подели со хоризонтални линии на делови или делови. Овие делови може да вклучуваат име на класа, атрибути (променливи) и операции (методи).

дијаграм на државната шема

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

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

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

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

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

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

        Следниве задолжителни услови мора да бидат исполнети за машината:

• состојбата во која може да оди објектот е одредена само од неговата моментална состојба и не зависи од неговата претходна историја;
• Во секој момент од времето, автоматот може да биде само во една од неговите состојби. Во исто време, автоматот може да остане во посебна состојба онолку долго колку што сакате ако не се случат настани;
• времето кога машината е во една или друга состојба, како и времето потребно за да се постигне една или друга состојба, не се на кој било начин одредено;
• бројот на состојби на автоматот мора да биде конечен и сите тие да бидат експлицитно наведени. Индивидуалните псевдо-состојби може да немаат спецификации (почетни и крајни состојби). Во овој случај, нивната цел и семантика се целосно детерминирани од контекстот на моделот и дијаграмот на состојби што се разгледуваат;
• Графикот на автомати не треба да содржи изолирани состојби и транзиции. За секоја состојба, освен почетната, мора да се одреди претходна состојба и секоја транзиција мора да поврзе две состојби на машината;
• автоматот не треба да содржи конфликтни транзиции, кога објектот може истовремено да премине во две или повеќе последователни состојби (освен случајот на паралелни подавтомати). Во UML, елиминацијата на конфликтот е можно со воведување услови за заштита.

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

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

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

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

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

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

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

        Така, дијаграмите на активности може да се сметаат за посебен случај на дијаграми на состојби. Тие ви дозволуваат да ги имплементирате во јазикот UML карактеристиките на процедурална и синхрона контрола поради завршување на внатрешните активности и активности. Главната употреба на дијаграмите на активности е да се визуелизираат карактеристиките за имплементација на операциите на класата, кога е неопходно да се претстават алгоритми за нивна имплементација.

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

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

Дијаграм за низа

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

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

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

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

        Втората димензија на секвенцискиот дијаграм е вертикалната временска оска, насочена од врвот до дното. Најгорниот дел од дијаграмот одговара на почетниот момент на времето. Објектните интеракции се спроведуваат преку пораки испратени од еден објект до друг. Пораките се прикажани како хоризонтални стрелки со името на пораката, а нивниот редослед се одредува според времето на појавување. Односно, пораките лоцирани повисоко во дијаграмот за секвенца се иницирани пред оние лоцирани пониско. Скалата на временската оска не е означена, бидејќи секвенцискиот дијаграм го моделира само временскиот редослед на интеракциите „порано-подоцна“.

Дијаграм за соработка

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

        Овој тип на дијаграм ви овозможува да ги опишете интеракциите на објектите, апстрахирајќи од низата на пренос на пораката. Овој тип на дијаграм ги прикажува во компактна форма сите примени и пренесени пораки на одреден објект и видовите на овие пораки.

        Најпрво, дијаграмот за соработка ги прикажува објектите кои учествуваат во интеракцијата во форма на правоаголници, кои го содржат името на објектот, неговата класа и, можеби, вредностите на атрибутите. Понатаму, како и во класичниот дијаграм, асоцијациите помеѓу објектите се означени во форма на различни линии за поврзување. Во овој случај, можете експлицитно да ги наведете имињата на асоцијацијата и улогите што ги играат објектите во оваа асоцијација. Дополнително, може да се прикажат динамички врски - текови на пораки. Тие се претставени и како линии за поврзување помеѓу објекти, над кои има стрелка што ја покажува насоката, името на пораката и бројот на секвенцата во општата низа на иницијализација на пораката.

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

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

        Соработката може да биде претставена на две нивоа:

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

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

        Дијаграмот за соработка на ниво на пример е претставен со збир на објекти (инстанци на класи) и врски (примероци на асоцијации). Во овој случај, врските се надополнуваат со стрелки за пораки. На ова ниво се прикажани само објекти кои се директно поврзани со спроведувањето на операцијата или класификаторот. Во овој случај, воопшто не е неопходно да се прикажат сите својства или сите асоцијации, бидејќи дијаграмот за соработка ги содржи само улогите на класификаторите, но не и самите класификатори. Така, додека класификаторот бара целосен опис на сите негови примероци, улогата на класификаторот бара опис само на оние својства и асоцијации кои се неопходни за учество во одредена соработка.

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

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

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

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

        Дијаграм на компоненти, за разлика од претходно дискутираните дијаграми, ги опишува карактеристиките на физичката репрезентација на системот. Ви овозможува да ја одредите архитектурата на системот што се развива преку воспоставување зависности помеѓу софтверските компоненти, кои можат да бидат изворен и извршен код. Главните графички елементи на дијаграмот на компонентите се компоненти, интерфејси и зависности меѓу нив.

        Дијаграмот на компонентите е развиен за следните цели:

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

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

        За претставување физички ентитети во јазикот UML, се користи посебен термин - компонента. Компонентата имплементира одреден сет на интерфејси и служи за општо означување на елементите на физичката репрезентација на моделот. За графички приказ на компонента, се користи посебен симбол - правоаголник со два помали правоаголници вметнати лево. Внатре во големиот правоаголник е името на компонентата и, доколку е потребно, некои дополнителни информации. Изгледот на овој симбол може малку да се разликува во зависност од природата на информациите поврзани со компонентата.

Дијаграм за распоредување

        Овој тип на дијаграм е наменет за анализа на хардверот на системот, односно хардверот, а не програмите. Директно преведен од англиски, Deployment значи „распоредување“, но терминот „топологија“ попрецизно ја одразува суштината на овој тип на дијаграм.

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

        Дијаграмите за распоредување се користат за претставување на општата конфигурација и топологија на дистрибуиран софтверски систем во UML.

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

        Дијаграмот за распоредување содржи графички прикази на процесори, уреди, процеси и врски меѓу нив. За разлика од дијаграмите за логично претставување, дијаграмот за распоредување е униформен за системот како целина, бидејќи мора целосно да ги одразува карактеристиките на неговата имплементација. Развивањето на дијаграм за распоредување е обично последниот чекор во одредувањето на моделот на софтверски систем.

        Кога се развива дијаграм за распоредување, се следат следните цели:

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

        Дијаграмите за распоредување се развиваат заеднички од системски аналитичари, мрежни инженери и системски техничари.

Карактеристики на работниот интерфејс Rational Rose

        Алатката Rational Rose CASE имплементира општоприфатени стандарди за оперативниот интерфејс на програмата, слични на добро познатите средини за визуелно програмирање. По инсталирањето на Rational Rose на компјутерот на корисникот, што практично не предизвикува потешкотии дури и за почетниците, стартувањето на оваа програма во MS Windows 95/98 доведува до појава на работен интерфејс на екранот (сл. 6).

Слика - 6.Општ приказ на работниот интерфејс на програмата Rational Rose

        Оперативниот интерфејс Rational Rose се состои од различни елементи, а главните се:

• Главното мени на програмата
• Прозорец за дијаграм
• Прозорец за документација
• Прозорец на прелистувачот
• Прозорец за дневник

Дозволете ни накратко да ја разгледаме целта и главните функции на секој од овие елементи.

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

Главното мени на програмата е направено во општо прифатениот стандард и изгледа вака (сл. 7).

Поединечни ставки од менито, чија цел е јасна од нивните имиња, комбинираат слични операции поврзани со целиот проект како целина. Некои од ставките од менито содржат добро познати функции (отворање проект, печатење дијаграми, копирање и залепување на различни елементи на дијаграмот од таблата со исечоци). Други се толку специфични што може да бараат дополнителен напор за проучување (опции за генерирање кодови, проверка на конзистентноста на моделот, поврзување дополнителни модули).

Слика - 7.Изглед на главното мени на програмата

Стандардна лента со алатки

Стандардната лента со алатки се наоѓа под главното мени на програмата и изгледа вака (сл. 8). Некои од алатките не се достапни (новиот проект нема никакви елементи). Стандардната лента со алатки обезбедува брз пристап до командите од менито што програмерите најчесто ги користат.

Слика - 8.Изглед на стандардната лента со алатки

Корисникот може да го прилагоди изгледот на овој панел по сопствена дискреција. За да го направите ова, изберете ја ставката од менито Алатки -> Опции и отворете го табот Ленти со алатки. На овој начин можете да прикажете или скриете различни копчиња со алатки и да ја промените нивната големина.

Прозорец на прелистувачот

Стандардниот прозорец на прелистувачот се наоѓа на левата страна од работниот интерфејс под стандардната лента со алатки (сл. 9).

Прелистувачот организира прегледи на модели во хиерархиска структура што ја поедноставува навигацијата и ви овозможува да најдете кој било елемент на моделот во проектот. Во овој случај, секој елемент што развивачот го додава на моделот веднаш се прикажува во прозорецот на прелистувачот. Според тоа, со избирање на елемент во прозорецот на прелистувачот, можеме да го визуелизираме во прозорецот на дијаграмот или да ја промениме неговата спецификација. Прелистувачот исто така ви овозможува да ги организирате елементите на моделот во пакети и да преместувате елементи помеѓу различни прикази на моделот. Доколку сакате, прозорецот на прелистувачот може да се наоѓа на друго место во работниот интерфејс или целосно да се скрие со помош на ставката од менито View. Можете исто така да ја промените големината на прелистувачот со влечење на неговата надворешна рамка со глувчето.

Слика - 9.Изглед на прелистувачот

Специјална лента со алатки

Специјална лента со алатки се наоѓа помеѓу прозорецот на прелистувачот и прозорецот на графиконот во средниот дел на работниот интерфејс. Стандардно, лентата со алатки се нуди за конструирање на дијаграм за класа на модел (сл. 10).

Слика - 10.Изглед на специјална лента со алатки за дијаграм на класи

Локацијата на специјалната лента со алатки може да се смени со поместување на рамката на панелот до саканата локација. Можете исто така да го приспособите составот на панелот со додавање или отстранување поединечни копчиња што одговараат на одредени алатки. Доделувањето на копчињата може да се научи од советите за алатки што се појавуваат откако покажувачот на глувчето лебди над соодветното копче.

Прозорец за дијаграм

Прозорецот на дијаграмот е главната работна област на неговиот интерфејс, во која се визуелизираат различни погледи на проектниот модел. Стандардно, прозорецот на дијаграмот се наоѓа на десната страна на работниот интерфејс, но неговата локација и големина исто така може да се променат. При развивање на нов проект, ако Проект Волшебникот не е користен, прозорецот на дијаграмот е празна област која не содржи никакви елементи на моделот (сл. 11).

Името на дијаграмот што се наоѓа во овој прозорец е означено во насловната лента на програмата (најгорната линија на програмата) или, ако прозорецот не е максимизиран на цел екран, во насловната лента на прозорецот на графиконот. Неколку графикони можат да бидат присутни во прозорецот на графиконот истовремено, но само еден од нив може да биде активен. На пример, на сл. 11 активниот дијаграм е дијаграмот за распоредување, иако има и други дијаграми. Префрлањето помеѓу дијаграмите може да се направи со избирање на саканиот приказ на стандардната лента со алатки или преку ставката од менито Window. Кога ќе активирате посебен приказ на графиконот, се менува изгледот на специјалната лента со алатки, која е приспособена за конкретниот приказ на графиконот.

Слика - 11.Изглед на прозорецот на дијаграмот со различни типови на погледи на моделот

Прозорец за документација

Прозорецот за документација може стандардно да не е присутен на екранот. Во овој случај, може да се активира преку менито Поглед -> Документација, по што ќе се појави под прелистувачот (сл. 12).

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

Во прозорецот за документација се активираат информациите што се однесуваат на поединечниот избран елемент на дијаграмот. Во овој случај, можете да изберете елемент или во прозорецот на прелистувачот или во прозорецот на дијаграмот. Кога додавате нов елемент на дијаграмот (на пример, класа), документацијата за него автоматски се генерира, која е празна (Нема документација). Последователно, инвеститорот самостојно ги внесува потребните објаснувачки информации, кои се паметат и можат да се променат за време на работата на проектот.

Исто како и за другите прозорци на работниот интерфејс, можете да ја промените големината и положбата на прозорецот за документација.

Слика - 12.Изглед на прозорецот за документација

Прозорец за дневник

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

Прозорецот за дневник е секогаш присутен на работниот интерфејс во областа на прозорецот на дијаграмот (сл. 13). Сепак, може да биде скриен од други прозорци на графикони или минимизиран. Можете да го активирате прозорецот за дневник преку менито Window->Log. Во овој случај, тој се прикажува на врвот на другите прозорци во десната област на работниот интерфејс. Овој прозорец не може целосно да се отстрани, може само да се минимизира.

Слика - 13.Изглед на прозорецот на дневникот

Заклучок

        Со текот на времето, јазикот на UML ќе стане „есперанто“ во кој математичари, системски аналитичари, физичари, програмери, менаџери, економисти и специјалисти од други професии ќе можат да комуницираат, презентирајќи го своето професионално знаење во обединета форма. На крајот на краиштата, во суштина, секој од специјалистите работи со моделски претстави во своето поле на знаење. И токму овој аспект на моделот може да се специфицира со користење на јазикот UML.

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

Оваа статија ја опишува новата ера на развој на софтвер, нејзиното влијание врз новите UML барања и најдобрите практики за нивно исполнување.
  7. „Моделирање на податоци во рационална роза“ Сергеј Трофимов Го опишува моделирањето на физичката репрезентација на податоците со помош на Рационална роза
  8. UML јазик. Општо разбирање на јазикот UML: структури, графички елементи и дијаграми на јазикот.
  9. Практичен UML. Овој документ е превод на документот "Practical UML. A Hands-On Introduction for Developers". Практичен вовед за програмери
  10. „Стандарден објектно-ориентиран јазик за моделирање UML“ Вендров Александар Михајлович. Историја на UML
  11. UML – унифициран јазик за моделирање. Овој материјал содржи првични информации за методите за опишување на софтверски системи и нотации што се користат во UML
  12. UML јазик. Упатство за корисникот. Автори: Грејди Буч, Џејмс Рамбо, Ивар Џејкобсон
  13. „UML дијаграми во рационална роза“ Сергеј Трофимов
  14. "Анализа и дизајн. Визуелно моделирање (UML) Rational Rose" Константин Домолего
  15. Библиотека на Генадиј Верников. Целосни описи на стандардите за дизајн и моделирање.
  16. „Пример за опишување предметна област со користење на UML при развој на софтверски системи“ Е.Б. Золотухина, Р.В. Алфимов. Статијата користи специфичен пример за да демонстрира можен пристап кон моделирање на домен врз основа на употребата на Унифициран јазик за моделирање (UML)

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

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

· Геометриски фигури на рамнината, играјќи ја улогата на темиња на графиците на соодветните дијаграми. Во овој случај, самите геометриски фигури дејствуваат како графички примитиви на јазикот UML, а обликот на овие фигури (правоаголник, елипса) мора строго да одговара на сликата на поединечни елементи на јазикот UML (класа, случај на употреба, состојба, активност ). Графичките примитиви на UML имаат фиксна семантика што на корисниците не им е дозволено да ја отфрлат. Графичките примитиви мора да имаат свои имиња, а можеби и друг текст, кој е содржан во границите на соодветните геометриски форми или, по исклучок, во близина на овие форми.

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

· Специјални графички симболи прикажани блиску до одредени визуелни елементи на дијаграмите и имаат карактер на дополнителни спецификации (украси).

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

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

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

Дијаграм за соработка

Дијаграмите за соработка се дизајнирани да ги опишат динамичните аспекти на системот што се моделира. Тие обично се користат за:

· Прикажи збир на објекти кои се во интеракција во реална средина „од птичја перспектива“;

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

· да ја опише логиката за извршување на сложени операции, особено во случаи кога еден објект е во интеракција со неколку други објекти;

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

Кога се зборува за дијаграми за соработка, често се споменуваат две „нивоа“ на такви дијаграми:

· ниво на пример(примери, Instance-Level): прикажува интеракции помеѓу објекти (инстанци од класа); како ова Дијаграмобично создаден за истражување внатрешна организацијаобјектно-ориентиран систем.

· ниво на спецификација(Спецификација-ниво): се користи за проучување на улогите што ги извршуваат главните класи во системот.

Ја прикажува интеракцијата помеѓу објектите, што се врши со испраќање и примање пораки.

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

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

Зависноста покажува дека една компонента обезбедува услуга што ја бара друга компонента. Зависноста е претставена со стрелка од клиентскиот интерфејс или портата до увезениот интерфејс.

Главниот тип на ентитети во компонентен дијаграм се самите компоненти 1, како и интерфејсите 2, преку кои се означува односот помеѓу компонентите. Следниве односи се применуваат во дијаграмот на компонентите:

· имплементации помеѓу компоненти и интерфејси (компонентата го имплементира интерфејсот);

· зависности помеѓу компонентите и интерфејсите (компонентата го користи интерфејсот) 3.

Дијаграм за распоредување

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

Дијаграмот за распоредување содржи графички прикази на процесори, уреди, процеси и врски меѓу нив. За разлика од дијаграмите за логично претставување, дијаграмот за распоредување е униформен за системот како целина, бидејќи мора целосно да ги одразува карактеристиките на неговата имплементација. Развивањето на дијаграм за распоредување е обично последниот чекор во одредувањето на моделот на софтверски систем.

Кога се развива дијаграм за распоредување, се следат следните цели:

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

· покажуваат физички врски помеѓу сите јазли на имплементацијата на системот во фазата на неговото извршување;

· да ги идентификува тесните грла на системот и да ја реконфигурира неговата топологија за да ги постигне потребните перформанси.