Удакладняем апісанне функцый сістэмы з дапамогай дыяграмы Sequence (працяг "Белкі")
У дадзеным артыкуле разгледзім, як можна дэталізаваць (удакладніць) апісанне аўтаматызаванай функцыі з дапамогай UML Sequence Diagram - дыяграмы паслядоўнасці.
У дадзеным прыкладзе я выкарыстоўваю асяроддзе Enterprise Architect ад аўстралійскай кампаніі [1].
Поўную спецыфікацыю UML гл. [2].
Для пачатку растлумачу, што мы будзем дэталізаваць.
В мы мадэлявалі працэсы «казачнай» прадметнай вобласці — радкі пра вавёрку са «Казкі пра цара Салтана» А.С.Пушкіна. І пачалі мы з дыяграмы Activity. Потым ва мы распрацавалі функцыянальную мадэль з дапамогай дыяграмы Use-case, на малюнку 1 прадстаўлены фрагмент.
Малюнак 1. Сувязь патрабаванні і функцыі
Цяпер мы хочам удакладніць інфармацыю аб выкананні дадзенай аўтаматызаванай функцыі:
- з якімі кампанентамі інтэрфейсу будзе ўзаемадзейнічаць наш карыстач;
- якія кіравальныя кампаненты нам спатрэбяцца;
- што мы будзем захоўваць;
- якімі паведамленнямі будуць абменьвацца карыстач і кампаненты сістэмы для выканання функцыі.
Асноўнымі элементамі дыяграмы Sequence з'яўляюцца якія ўзаемадзейнічаюць аб'екты з рознымі стэрэатыпамі і сувязі паміж імі - якія ўзаемадзейнічаюць аб'екты абменьваюцца паміж сабой некаторай інфармацыяй (Малюнак 2).
Малюнак 2. Асноўныя элементы Sequence дыяграмы
Аб'екты размешчаны ў гарызантальнай паслядоўнасці, паміж імі перадаюцца паведамленні. Вось часу арыентавана зверху ўніз.
Элемент Actor можа выкарыстоўвацца для прадстаўлення карыстальніка, які ініцыюе паток падзей.
Кожны аб'ект мае пункцірную лінію, званую "лініяй жыцця", дзе гэты элемент існуе і патэнцыйна прымае ўдзел ва ўзаемадзеяннях. Фокус кіравання пазначаецца прастакутнікам на лініі жыцця аб'екта.
Паведамленні, якімі абменьваюцца аб'екты, могуць быць некалькіх тыпаў, паведамленні таксама могуць быць настроены для адлюстравання аперацый і ўласцівасцяў зыходнага і мэтавага элементаў.
Стэрэатыпныя элементы, такія як межы (Boundary), элементы кіравання (Control) і сутнасці (Entity), могуць выкарыстоўвацца для мадэлявання карыстацкага інтэрфейсу (GUI), кантролераў і элементаў базы дадзеных, адпаведна.
Паўтаральны струмень абмену паведамленнямі можа быць пазначаны як фрагмент з тыпам "loop".
Такім чынам, мы плануем удакладніць апісанне функцыі "Дадаць у ведамасць інфармацыю аб новым арэху".
Дамовімся аб наступных дадатковых абагульненнях і дапушчэннях.
- Арэх, ядро і шкарлупіны - гэта ўсё матэрыяльныя каштоўнасці адпаведных тыпаў (Малюнак 3).
Малюнак 3. Удакладненне дыяграмы класаў - У ведамасць наш карыстач будзе ўносіць інфармацыю аб любых матэрыяльных каштоўнасцях.
- Удакладнім назву ведамасці - "Ведамасць уліку мат.каштоўнасцяў".
- Дапушчальны, што наш карыстач, працуючы з GUI «Ведамасць уліку мат.каштоўнасцяў», можа дадаць новую мат.каштоўнасць праз GUI «Картачка ўліку мат.каштоўнасці».
- У залежнасці ад тыпу мат.каштоўнасці змяняецца структура дадзеных і GUI.
- Пры запаўненні палёў карткі ўліку мат.каштоўнасці адбываецца праверка карэктнасці ўведзеных дадзеных.
Дыяграма, пабудаваная з улікам гэтых дапушчэнняў, прыведзена на Малюнку 4.
Малюнак 4. Удакладненне апісання функцыі "Дадаць у ведамасць інфармацыю аб новым арэху"
Аб прымяненні іншых відаў дыяграм UML можна пачытаць тут:
Спіс крыніц
- Сайт Sparx Systems. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Электронны рэсурс] Рэжым доступу: Інтэрнэт:
Крыніца: habr.com