Уніфікованамовамоделювання (UML - UnifiedModelingLanguage)^ стандартнимінструментомдлястворення"креслень"програмногозабезпечення.ЗадопомогоюUMLможнанамалювати,специфікувати,сконструюватиідокументуватиконтактипрограмнихсистем.
UMLпридатнадлямоделюваннябудь-якихсистем:відінформаційнихсистеммасштабупідприємствадорозподіленихWeb-додатківінавітьвбудованихпрограмреальногочасу.
ДлярозумінняUMLнеобхіднозасвоїтиїїконцептуальнумодель,якавключаєтрискладовічастини:основнібудівельніблокимови,правилаїхпоєднанняідеякізагальнідлявсієїмовимеханізми.ЗасвоївшиціелементиможначитатимоделінаUMLісамостійностворюватиїх-спочатку,звичайно,недужескладні.Зпридбаннямдосвітувроботізмовоюможнанавчитисякористуватисяібільшрозвиненимийогоможливостями.
СловникмовиUMLвключаєтривидибудівельнихблоків[2,4,32,57,75]:сутності,відносини,діаграми.
Сутності- цеабстракції,щоєосновнимиелементамимоделі.Відносинизв'язуютьрізнісутності;діаграмигрупуютьсукупністьсутностей.
ВUMLєчотиритиписутностей:структурні,поведінкові,групуючи,анотаційні.
Сутностієосновнимиоб'єктно-орієнтованимиблокамимови.Зїхдопомогоюможнастворюватикоректнімоделі.
Структурнісутності -цеіменаіменникивмоделяхнамовіUML. Як правило,вониєстатистичнимичастинамимоделі,відповідаючимиконцептуальнимабофізичнимелементамсистеми.Існуєсімрізновидівструктурнихсутностей.
 | ||||
 | ||||
 |
| Window |
| originsize |
| open0 close() move() display() |
Клас(Class)- описсукупностейоб'єктівіззагальнимиатрибутами,операціями,відносинамиісемантикою.Класреалізуєодинабодекількаінтерфейсів.Графічнокласзображуєтьсяувиглядіпрямокутника,вякомузаписанійогоім'я,атрибутиіоперації(рис.7.5).
| Рис.7.5. Класи |
|
| Spelling Рис.7.6. Інтерфей- •""~~-- Ланцюг відповідальності / Рис.7.7. Коо-пепаиія |
Інтерфейс(Interface) -сукупністьопераційяківизначаютьсервіс(набірпослуг),якийнадаєтьсякласомабокомпонентам.Такимчином,інтерфейсописуєвидимуззовні поведінку елемента.Інтерфейсможепредставлятиповедінкуікласуабокомпонентаповністюабочастково;вінвизначаєтількиспецифікаціїоперацій(сигнатури),аленіколи-їхреалізації.Графічноінтерфейсзображуєтьсяувиглядікола,підякимвказуєтьсяйогоім'я(рис.7.6).Інтерфейсрідкоіснуєсампособі.Звичайновінприєднуєтьсядокласуабокомпонента,щойогореалізує.
|
| Рис.7.8. Прецеденти |
Кооперація(Collaboration) визначаєвзаємодію,вонаєсукупністюролейтаіншихелементів,якіпрацюючиспільно,справляютькооперативнийефект.Отже,коопераціямаєякструктурний,такіповедінковийаспект.Одинітойжекласможебратиучастьвдекількохкоопераціях;такимчином,коопераціяєреалізацієюзразківповедінки,щоформуютьсистему.Графічнокоопераціязображуєтьсяувиглядіеліпса,обмеженогопунктирноюлінією,вякійзвичайноукладенотількиім'я(рис.7.7).
Прецедент(Usecase) -описпослідовностівиконуванихсистемоюдій,якаодержуєрезультат,значущийдляякогосьпевногоактора(Actor).Прецедентзастосовуєтьсядляструктуризаціїповедінковихсутностеймоделі.Прецедентиреалізуютьсязадопомогоюкооперації.Графічнопрецедентзображуєтьсяувиглядіобмеженогобезперервноюлінієюеліпса,щоміститьтількийогоім'я(рис.7.8).
 |
| EvenManager |
| suspend()flush() |
| Рис.7.9. Активні класи |
Триіншісутності-активнікласи,компонентиівузли-подібнідокласів:вониописуютьсукупністьоб'єктівіззагальнимиатрибутами,операціями,відносинамиісемантикою.Протевонидоситьчітковідрізняютьсяодинвідодногоівідкласіві,враховуючиїхважливістьпримоделюванніпевнихаспектівоб'єктно-орієнтованихсистем,заслуговуютьспеціальногорозгляду. Активнимкласом(Activeclass) називаєтьсяклас,об'єктиякогозалученідоодногоабодекількохпроцесів,абониток(Threads),ітомуможутьініціюватиуправляючудію.Активнийкласувсьомуподібнийдозвичайногокласу,завиняткомтого,щойогооб'єктамиєелементи,діяльністьякихздійснюєтьсяодночасноздіяльністюіншихелементів.Графічноактивнийкласзображуєтьсятаксамо,якпростийклас,алеобмежуючийпрямокутникмалюєтьсяжирноюлінієюізвичайновключаєім'я,атрибутиіоперації(рис.7.9).Дваелементи,щозалишилися,- компонентиівузли- такожмаютьособливості.Вонивідповідаютьфізичнимсутностямсистеми,тодіякп'ятьпопередніх-концептуальнимілогічнимсутностям.
| overform.java |
Компонент(Component) -цефізичназамінюваначастинасистеми,якавідповідаєдеякому
Рис.7.10. Компоненти набоРУінтерфейсівізабезпечуєйогореалізацію.У
| Рис.7.11. Вузли |
системізустрічаютьсярізнівидивстановлюванихкомпонентів,такіякСОМ+абоJavaBeans,атакожкомпоненти,щоєартефактамипроцесурозробки,наприклад,файлипочатковогокоду.Компонент,якправило,єфізичноюупаковкоюлогічнихелементів,такихяккласи,інтерфейсиікооперації.Графічнокомпонентзображаєтьсяувиглядіпрямокутниказвкладками,щомістятьтількиім'я(рис.7.10). Вузол(Node) -цеелементреальної(фізичної)системи,якийіснуєпід
часфункціонуванняпрограмногокомплексуієобчислювальнимресурсом,
щоволодіє,якмінімумдеякийобсягомпам'яті,ачастощеіздатністюоброблятицюпам'ять.Сукупністькомпонентівможерозміщуватисяувузлі,атакожмігруватизодноговузлавінший.Графічновузолзображаєтьсяувиглядікуба,щоміститьтількиім'я(рис.7.11).
Цісімбазовихелементів-класи,інтерфейси,кооперації,прецеденти,активнікласи,компоненти,вузли-єосновнимиструктурнимисутностями,якіможутьбутивключенівмоделіUML.Існуютьтакожрізновидицихсутностей: актори,сигнали,утиліти (видикласів), процесиінитки (видиактивнихкласів), додатки,документи,файли,бібліотеки,сторінкиітаблиці (видикомпонентів).
Поведінковісутності(Behavioralthings) єдинамічнимискладовимимоделіUML.Цедієсловамови:вониописуютьповедінкумоделівчасііпросторі.Існуєвсьогодваосновнихтипиповедінковихсутностей- взаємодіяіавтомат.
Взаємодія(Interaction)- цеповедінка,сутьякоїполягаєвобмініповідомленнями(Messages)міжоб'єісгамивмежахконкретногоконтекстудлядосягненняпевноїмети.Задопомогоювзаємодіїможнаописатиякокремуоперацію,такіповедінкусукупностіоб'єктів.Взаємодіяприпускаєрядіншихелементів,такихяк повідомлення,послідовностідій (поведінка,ініційованаповідомленням)ізв'язкиміжоб'єктами.Графічноповідомленнязображаютьсяувиглядістрілки,надякоюмайжезавждивказуєтьсявідповіднаоперація(рис.7.12).
„._ Автомат(Statemachine) -цеалгоритмповедін-
Відобразити
ки,щовизначаєпослідовністьстанів,черезякіоб'єкт
Рис.7.12.
Повідомлення а^°взаєм°Д'япроходятьпротягомциклуувідповідь
нарізніподії,атакожреакціїнаціподії.Задопомо
гоюавтоматаможнаописатиповедінкуокремого
класуабокоопераціїкласів.Завтоматомпов'язаний
рядіншихелементів: стани,переходи (зодногоста-
I. ) нувінший), події (сутності,щоініціюютьпереходи)і
видидій(реакційнаперехід).Графічностанзображу-Рис.7.13. Стани
єтьсяувиглядіпрямокутникаіззакругленимикутами,щоміститьім'яі,можливо,підстани(рис.7.13.).
Цідваелементи-взаємодіяіавтомат-єосновнимиповедінковимисутнос-тями,щовходятьумодельUML.Семантикоювоничастопов'язанізрізнимиструктурнимиелементами,упершучергу-класами,коопераціямиіоб'єктами.
Групуючисутності єорганізуючимичастинамимоделіUML.Цеблоки,наякіможнарозкластимодель.Єтількиоднапервиннагрупуючасутність- пакет.
| Бізнес—правила |
Пакети(Packages)— єуніверсальниммеханізмоморганізаціїелементівугрупі.Упакетможнапоміститиструктурні,поведінковіі,навіть,іншігрупуючисутності.Навідмінувідкомпонентів,іс-Рис.7.14. Пакети нуючихпідчасроботипрограми,пакетимаютьчистоконцептуальнийхарактер,тобтоіснуютьтількипідчасрозробки.Пакетзображуєтьсяувиглядітекиіззакладкою,щомістить,якправило,тількиім'я,аіноді -вміст (рис.7.14).
Пакети-цеосновнігрупуючисутності,задопомогоюякихможнаорганізуватимодельUML.Існуютьтакожваріаціїпакетів,наприклад каркаси (Frameworks), моделі та підсистеми.
|
Анотаційнісутності -частинипоясненьмоделіUML.Цекоментарідлядодатковогоопису,поясненняабозауваженнядобудь-якогоелемента
моделі.Єтількиодинбазовийтипанотаційних
Рис.7.15. Примітки
елементів- примітка(Note).
Примітка— цепростосимволдлязображеннякоментарівіобмежень,приєднанихдоелементаабогрупиелементів.Графічнопримітказображуєтьсяувиглядіпрямокутникаіззаломленимверхнімкраєм,щоміститьтекстовийабографічнийкоментар(рис.7.15).Цейелементєосновноюанотацій-ноюсутністю,якаможевключатисядомоделіUMLНайчастішеприміткувикористовуютьдлязабезпеченнядіаграмикоментарямиабообмеженнями,якіможнавиразитиувиглядітексту.Існуютьваріаціїприміток,наприклад,вимоги,деописуютьякусьбажануповедінкузпоглядузовнішньоїповід-
ношеннюдомоделі.
УмовіUMLвизначеночотиритипи відносин: залежність,асоціація,узагальнення,реалізація.
Цівідносиниєосновнимизв'язуючимибудівельнимиблокамивUMLізастосовуютьсядляствореннякоректнихмоделей.
Залежність(Dependency)— цесемантичне
р. відношенняміждвомасутностями,приякомузмі
наоднієїзних,незалежної,можевплинутинасе-
Рис.7.16.
Залежність мантикуіншої,залежної.Графічнозалежністьзо-
бражуєтьсяувиглядіпрямоїпунктирноїлінії,частоізстрілкою(рис.7.16).
Асоціація(Association) -структурневідношення,щоописуєсукупністьзв'язків;зв'язок-цез'єднанняміжоб'єктами.
Різновидомасоціаціїє агрегація(Aggregation). Такназиваютьструктурневідношенняміжцілимійогочастинами.Графічноасоціаціязображуєтьсяувиглядіпрямоїлінії(стрілкою,щоінодізавершуєтьсяабощоміститьмітку),порядзякоюможутьбутиприсутнідодатковіпризначення,наприклад,кратністьііменаролей.Нарис.7.18показаноприкладвідносинцьоготипу.
Узагальнення(Generalisation) -цевідношення"спеціалізація/узагальнення",приякомуоб'єкт
спеціалізованогоелементу(нащадок)можебути
Рис.7.17. Уза
гальнення підставленийзамістьоб'єктаузагальненогоелеме
нта(батькаабопредка).Такимчином,нащадок
(Child)успадковуєструктуруіповедінкусвогоба
тька(Parent).Графічновідношенняузагальнення
0...1*
зображуєтьсяувигляділініїзнезамальованою
роботодавецьробітникстрілкою,якавказуєнабатька(рис.7.17).
__..Нарешті, Реалізація(Realization)- цесеман-
Рис.7.18. Асоціації
тичневідношенняміжкласифікаторами,приякомуодинкласифікаторвизначає"контракт",аінший
гарантуєйоговиконання.Відносиниреалізаціїзустрічаютьсяудвохвипадках:по-перше,міжінтерфейсамиіреалізуючимиїхкласамиабокомпонен-Рис.7.19.
Реалізації тами,апо-друге,міжпрецедентамиіреалізовую-
чимиїхкоопераціями.
Відношенняреалізаціїзображуєтьсяувиглядіпунктирноїрисизнезафарбованоюстрілкою,якщосьсереднєміжвідносинамиузагальненняізалежності(рис.7.19).
Чотириописаніелементи(залежність,асоціація,узагальненняіреалізація)єосновнимитипамивідносин,щоможнавключатидомоделіUML.Існуютьтакожіхваріації,наприклад, уточнення (Refinement), трасування (Trace), включення і поширення (длязалежності).
ДіаграмавUML -цеграфічнепредставленнянаборуелементів,щонайчастішезображуєтьсяувиглядізв'язаногографаз вершинами (сутностя-ми)і ребрами (відносинами).
Діаграмистворюютьдлявізуалізаціїсистемизрізнихточокзору.Діаграма,удеякомурозумінні,-одназпроекційсистеми.Якправило,завиняткомнайтривіальнішихвипадків,діаграмидаютьзгорнутеуявленняелементів,зякихскладаєтьсясистема.Одинітойжеелементможебутиприсутнійувсіхдіаграмах,аботількивдекількох(найпоширенішийваріант),абонебутиприсутнійніводній(дужерідко).Теоретичнодіаграмиможутьміститибудь-якікомбінаціїсутностейівідносин.Протенапрактицізастосовуєтьсяпорівняноневеликакількістьтиповихкомбінацій,яківідповідаютьдев'ятьомнайпоширенішимтипамдіаграм:класів,об'єктів,прецедентів,послідовностей,кооперації,станів,взаємодій,компонентів,розгортання.
На діаграмікласів показуютькласи,інтерфейси,об'єктиікооперації,атакожїхвідносини.Примоделюванніоб'єктно-орієнтованихсистемцейтипдіаграмвикористовуютьнайчастіше.Вінвідповідаєстатичномувидусистемизпоглядупроектування.Діаграмикласів,яківключаютьактивнікласи,відповідаютьстатичномувидусистемизпоглядупроцесів.
На діаграміоб'єктів представляютьоб'єктиівідносиниміжними.Вониєстатичними"фотографіями"екземплярівсутностей,показанихнадіаграмахкласів.Діаграмиоб'єктів,якідіаграмикласів,відносятьсядостатичноговидусистемизпоглядупроектуванняабопроцесів,алезрозрахункомнасправжнюабомакетнуреалізацію.
На діаграміпрецедентів представленіпрецедентиіактори(окремийвипадоккласів),атакожвідносиниміжними.Діаграмипрецедентіввідносятьсядостатичноговидусистемизпоглядупрецедентіввикористовування.Вониособливоважливіприорганізаціїімоделюванняповедінкисистеми.
Діаграмипослідовностейікооперації єокремимвипадкомдіаграм взаємодії. На діаграмахвзаємодій представленізв'язкиміжоб'єктами;показані,зокрема,повідомлення,якимиоб'єктиможутьобмінюватися.Діаграмивзаємодіївідносятьсядодинамічноговидусистеми. Діаграмипослідовності відображаютьтимчасовувпорядкованістьповідомлень,а діаграмикооперації- структурнуорганізаціюоб'єктів,щообмінюютьсяповідомленнями.Цідіаграмиєізоморфними,тобтоможутьбутиперетвореніоднанаодну.
На діаграмахстану(Statechartdiagrams) представляєтьсяавтомат,щовключаєстани,переходи,подіїівидидій.Діаграмистанувідносятьсядодинамічноговидусистеми,вониважливіпримоделюванніповедінкиінтерфейсу,класуабокооперації;акцентуютьувагунаповедінціоб'єкту,залежнійвідпослідовностіподій,щодужекориснодлямоделюванняреактивнихсистем.
Діаграмавзаємодії- цеокремийвипадокдіаграмистанів;нанійзображуютьсяпереходипотокууправліннявідоднієїдіяльностідоіншоїусерединісистеми.Діаграмивзаємодіївідносятьсядодинамічноговидусистеми;вонинайбільшважливіпримоделюванніїїфункціонуванняівідображаютьпотікуправлінняміжоб'єктами.
На діаграмікомпонентів представляютьорганізаціюсукупностікомпонентівтаіснуючуміжнимизалежність.Такідіаграмивідносятьсядостатичноговидусистемизпоглядуреалізації.Вониможутьбутиспіввіднесеніздіаграмамикласів,оскількикомпонент,звичайно,відображаєтьсянаодинабо
декількакласів,інтерфейсівабокооперацій.
На діаграмірозгортання зображуютьконфігураціюоброблюванихвузлівсистемиірозміщенихвнихкомпонентів.Діаграмирозгортаннявідносятьсядостатичноговидуархітектурисистемизпоглядурозгортання.Вонипов'язаніздіаграмамикомпонентів,оскількиувузлі"оглядовий"розміщуютьсяодинабодекількакомпонентів.
Тутприведенонеповнийсписокдіаграм,вживанихвUML.Інструментальнізасобидозволяютьгенеруватийіншідіаграми,аледев'ятьперерахованихзустрічаютьсянапрактицінайчастіше.
БудівельніблокиUMLнеможнадовільнооб'єднуватиодинзодним.Якібудь-якаіншамова,UMLхарактеризуєтьсянаборомправил,щовизначають,якийповиннамативигляд добреоформленамодель: семантичносамо-узгодженаізнаходитисявгармоніїзівсімамоделями,якізнеюпов'язані.
УмовіLJMLєсемантичніправила,щодозволяютькоректноіоднозначновизначити:
• імена, якіможнадаватисутностям,відносинамідіаграмам;
• сферудії (контекст,уякомуім'ямаєдеякезначення);
• видимість (колиіменавидимііможутьвикористовуватисяіншими
елементами);
• цілісність (якелементиповинніправильноіпогодженоспіввідноси
тисяодинзодним);
• виконання (щозначитьвиконатиабоімітуватидеякудинамічнумодель).
РоботузмовоюUMLістотнополегшуєпослідовневикористаннянаступних загальнихмеханізмів: специфікації'(Specifications),доповнення(Adornment),ухваленнярозподілу(Commondivisions),механізмирозширення(Extensibilitymechanisms).
UML-ценепростографічнамова.Закожноючастиноюїїсистемноїграфічноїнотаціїстоїть специфікація, щоміститьтекстовепредставленнясинтаксисуісемантикивідповідногобудівельногоблоку.
Наприклад,діаграмікласувідповідаєспецифікація,щоповністюописує
операціїцьогокласу(включаючиповнісигнатури)іповедінку,хочавізуальнодіаграмадеколивідображаєтількичастиницієїсукупності.Більштого,можеіснуватиіншепредставленняцьогокласу,щовідображаєвчиненііншійогоаспекти,протевідповіднітійжеспецифікації.ЗадопомогоюграфічноїнотаціїUMLможнавізуалізуватисистему,задопомогоюспецифікаціїUML-описатиїїдеталі.СпецифікаціїUMLстворюютьсемантичнийзаднійплан,якийповністювключаєскладовічастинивсіхмоделейсистеми,злагодженіміжсобою.Такимчином,діаграмиUMLможнавважативізуальнимипроекціяминацейзаднійплан,прицьомукожназнихрозкриваєодиніззначущихелементівсистеми.
МайжекожнийзелементівUMLмаєвідповіднейомуунікальнеграфічнепозначення,якедаєвізуальнеуявленняпронайважливішіаспектитогочиіншогоелемента.Наприклад,позначеннякласуспеціальноприймаєтьсятак,щобйогобулолегкозобразити,оскількикласи-елементи,щовживаютьсяпримоделюванняоб'єктно-орієнтованихсистем.Нотаціякласуміститьнайважливішійогохарактеристики:ім'я,атрибутиіоперації.
|
Специфікаціякласуможеміститийіншідеталі,наприклад,видимістьатрибутівіопераційабовказівканате,щокласєабстрактним.Багатотакихдеталейможнавізуалізуватиувиглядіграфічнихаботекстовихдоповненьдостандартногопрямокутника,щослужитьзображеннямкласу.
Так,нарис.7.20показаноклас,дляпозначенняякоговключенівідомостіпроте,щовінабстрактнийіміститьдвівідкриті,однузахищенуіоднузакритуоперацію.КожнийелементнотаціїLJMLміститьбазовийдляньогосимвол,доякогоможнадодаватирі-
__„_зноманітніспецифічнідляньогодоповнення.
Рис.7.20. Допов
нення Примоделюванніоб'єктно-орієнтованихкласів
реальністьчленуєтьсязурахуванням,принаймні,двох
підходів.Першзавсе,існуєподілнакласиіоб'єкти. Клас -абстракція, обєкт -конкретнаматеріалізаціяцієїабстракції.УмовіUMLможнамоде-178
люватиікласи,іоб'єкти(рис.7.21).
| БудівельніблокиUMLхарактеризуютьсядихотомією«клас/об'єкт».Так,єпрецедентиіекземплярипрецедентів,компонентиіекземплярикомпонентів,вузлиіекземпляривузлівіт.ін.Уграфічномупредставленнідляоб'єктаприйнятовикористовуватитоййсамийсимвол,щоідляйогокласу,аназвуоб'єкта-підкреслювати. |
| Customer | Jan: |
| NameAdressPhone | |
| :Customer | |
| Elyse |
Рис.7.21. Класиіоб'єкти
Нарис.7.21показаноодинкласCustomer(Клієнт)ітриоб'єкти:Jan:(явновизначенийякоб'єктподаногокласу),:Customer(анонімнийоб'єкткласуCustomer)іElyse(специфікаціяякоговідноситьйогодокласуCustomer,хочацеіневираженоявно).
 |
|
| ІUnknown |
Spellingwizard.dll
1Spelling
Рис.7.22. Інтерфейсиіреалізації
Щеоднимваріантомєрозподілнаінтерфейсійогореалізацію.Інтерфейсдекларуєконтракт,ареалізаціяпредставляєконкретневтіленняцьогоконтрактуізобов'язуєточнобутиоголошенимсемантиціінтерфейсу.UMLдозволяємоделюватиобидвіцікатегорії,інтерфейсиіїхреалізації(рис.7.22.),вданомувипадкуодинкомпонентSpellingwizard.dllреалізуєдваінтерфейсиІUnknownі1Spelling.
МайжевсібудівельніблокиUMLхарактеризуютьсядихотомією«інтерфейс/реалізація».Наприклад,прецедентиреалізуютьсякоопераціями,аоперації-методами.
Механізмирозширення. UML-цестандартнамовадлярозробки«крес-
лень»програмногозабезпечення.Алежодназамкнутамованеможеохопитинюансивсіхможливихмоделейвнаочнихсферах.ТомуUMLєвідкритоюмовою,тобтодопускаєконтрольованірозширення.МеханізмирозширенняUMLвключають:
-стереотипи;
-поміченізначення;
-обмеження.
Стереотип(Stereotype) -розширюєсловникUML,дозволяючинаосновііснуючихблоківмовистворюватинові,специфічнідлявирішенняконкретноїпроблеми.Зпомітнимивиняткамивідповідногостереотипуможнаповодитисьякіззвичайнимибудівельнимиблокамимови.Нарис.7.23цепродемонстрованонаприкладікласуOverflow.
Помічнезначення(Taggedvalue) розширюєвластивостібудівельнихблоківUML,дозволяючивключатиновуінформаціювспецифікаціюелемента.Нарис.7.23.показано,якцеможназробитинаприкладікласуEvenQueue.
| EventQueue{version=3.2author=egb} | |||
| "exception" | |||
| Overflow | |||
| Add()---.Remove() |
{попорядку}
Рис.7.23. Механізмирозширення
Обмеження(Constraints)- розширюютьсемантикубудівельнихблоківUML,дозволяючивизначатиновіабозмінюватиіснуючіправила.Можна,наприклад,обмежитикласEvenQueueтак,щобусіподіїдодавалисявчергу.Нарис.7.23показано,якможнавизначитиобмеження,якеявнопостулювалоцеправилодляопераціїAdd.
Системнаархітектурає,мабуть,найважливішимартефактом,якийвикористовуєтьсядляуправліннябудь-якимиточкамизоруітимсамимсприяєінтерак-
тивнійіінкрементнійрозробцісистеминавсьомупротязіїїжиттєвогоциклу.Архітектура-цесукупністьістотнихрішеньстосовно:
- організаціїпрограмноїсистеми;
- виборуструктурнихелементів,щостановлятьсистему,іїхінтерфейсів;
- поведінкицихелементів,специфікованоїувзаємодіїзіншимиелементами;
- складаннязцихструктурнихіповедінковихелементіввсебільші
більшкрупнихпідсистем;
- архітектурногонаправляючогостилю,щовизначаєвсюорганізацію
системи:статичніідинамічніелементи,їхінтерфейси,коопераціїіспосібїх
об'єднання.
Архітектурапрограмноїсистемиохоплюєнетількиїїструктурнііпове-дінковіаспекти,алеівикористання,функціональність,продуктивність,гнучкість,можливістьповторноговживання,повноту,економічніітехнологічніобмеженняікомпроміси,атакожестетичніпитання.Архітектурупрограмноїсистемиможнаописатизадопомогоюп'ятивзаємопов'язанихвидівабоуявлень,кожнийзякихєоднієюзможливихпроекційорганізаціїіструктурисистемиізагострюєувагунапевномуаспектіїїфункціонування.
/. Виглядзпоглядупрецедентів(Usecaseview) охоплюютьпрецеденти,якіописуютьповедінкусистеми,якуспостерігаютькінцевікористувачі,аналітикиітестувальники.УмовіUMLстатичніаспектицьоговиглядупередаютьдіаграмамипрецедентів,адинамічні-діаграмамивзаємодіїістанів.
2. Виглядзпоглядупроектування(Designview) охоплюєкласи,інтер
фейсиікооперації,щоформуютьсловникзадачііїїрішення.Задопомогою
мовиUMLстатичніаспектицьоговиглядуможнапередаватидіаграмами
класівіоб'єктів,адинамічні-діаграмамистануівзаємодії.
3. Виглядзпоглядупроцесів(Processview) охоплюєниткиіпроцеси,що
формуютьмеханізмипаралелізмуісинхронізаціївсистемі.ВUMLйогоста
тичніідинамічніаспективізуалізуютьсятимиждіаграмами,щоідлявигля
дузпоглядупроектування,алеособливаувагаприцьомунадаєтьсяактивним
класам,якіпредставляютьвідповідніниткиіпроцеси.
J
4. 
Виглядзпоглядуреалізації(Implementationview) охоплюєкомпоненти
іфайли,щовикористовуютьсядлязбиранняівипускукінцевогопрограмного
продукту.УмовіUMLстатичніаспектицьоговиглядупередаютьзадопомогою
діаграмкомпонентів,адинамічні-задопомогоюдіаграмстанівівзаємодії.
5. Виглядзпоглядурозгортання(Deploymentview) охоплюєвузли,що
формуютьтопологіюапаратнихзасобівсистеми,наякійвонавиконана.Йо
гостатичніаспектиописуютьсяпрограмамирозгортання,адинамічні-діаг
рамамивзаємодіїістанів.
Моваскладаєтьсязбезлічітекстовихіграфічнихмоделей,необхіднихдляпроектуваннятакихсистем.Цімоделівизначаютьможливостісистеми,їїкомпоненти,способивзаємодіїсистемизкористувачемікомпонентівсистемиодинзодним.ВUMLвикористовуютьсянаступні основніелементи:
-специфікаціявимогдопрограмногозабезпечення(Software
RequirementSpecification,SRS), щорозробляється,-визначенняіопис(доку
ментування)загальнихфункційімежсистеми;
- прецеденти(елементиUseCase) -графічніаботекстовіописипослі
довностідійсистемизпоглядукористувачів(користувачемможебутилюди
наабоіншасистема);
- діаграмакласів(ClassDiagram)— графічнезображенняпроцесіввза
ємодіїоб'єктівпідчасвиконанняпрограми;цядіаграмавизначаєтимчасове
упорядкуванняповідомленьміжоб'єктами;
- діаграмакооперації(CollaborationDiagram)— графічнезображення
потоківвиконанняпроцесівабоопераційусерединісистеми.
Першимкрокомпроектуванняєвиробленнявимогдопрограми. Специфікаціявимогдостворюваногопрограмногопродукту(SoftwareRequirementSpecification,SRS) розробляєтьсядлявирішеннянаступнихзавдань:
- формулюванняфункціональнихвимогдосистеми;
- установитимежісистеми;
визначитикористувачівсистеми;
- описатипроцесивзаємодіїміжсистемоюізовнішнімикористувачами;
- установитиєдинумовуописусистеми,щовикористовуєтьсязамов
никомігрупоюпрограмістів;
- створитиосновидлямоделюванняпрецедентів.
Припустимо,наприклад,щонаданиймоменткомпаніянезнаєцентралізованогоспособузамовленняканцелярськогообладнаннядлявідділів.Кожнийвідділздійснюєтакізамовленнясамостійно.Томупрактичнонеможливоустановитизагальнівитратинаканцелярськітоваривмасштабахкомпанії,що,усвоючергу,недаєможливостівизначитивитратинацюстаттюіуникнутизловживань[3.2].
Крімтого,завідсутностісистемицентралізованогопостачаннянеможливозабезпечитипошукіукладеннянайвигіднішихконтрактівнапостачаннятоварів.Отже,необхіднорозробитидодаток,нацентралізованезамовленняканцелярськихтоварів.З'ясувавшивсіпитаннязпотенційнимикористувачами,необхіднорозробити специфікаціювимог, якавизначатимефункціональністьсистеми,їїмежііможливихкористувачів.
Об'єкти,щовзаємодіютьзсистемою:
• користувач(співробітниквідділу)-маєправоподаватизапитина
отриманняканцтоварів;
• менеджервідділу-контролюєізатверджуєзапитинапридбання
канцтоварів,поданіспівробітниками;
•додатокпостачальникатоварів-приймаєфайлизамовленьуформатіXML,створюванісистемою;
•менеджерпоставок-обновляєкаталогтоварів,відстежуєзапитина
придбанняканцтоварівіреєструєпостачання.
Функції,виконуванісистемою:
• привходівсистемукористувачповиненуказатисвоєім'яіпароль;
• користувачмаєнагодупроглянутисписокусіхтоварів,якіможутьбу
тизамовлені;
• користувачможевиділятивспискутоваризаданоїкатегорії(фільтру
ватидані);
• 
водномузапитікористувачможевказатидекількавидівтоварів;
•менеджервідділумаєправоподаватизагальнийзапитнатоваридля
відділу;
•укінцікожноготижняменеджервідділуповинензатвердитиабовідхилитизапити,щопоступили,напридбаннятоварів;
•привідхиленнізапитуменеджервідділузобов'язанийкороткопоясни
типричинувідмови;
•менеджервідділуповиненстежитизавитратоютоварівувідділітаза
безпечуватифінансуваннясхваленихзамовленьнапридбання;
•менеджерпоставокведекаталогтоварівістежитьзайогосвоєчаснимоновленням;
•приотриманнітоварівменеджерпоставокперевіряєїхкомплектністьіякістьізабезпечуєїхрозподілміжвідділами;
•запитинапридбаннятоварів,якінебулизатверджені,позначаютьсяяктакі,щопоступилинарозгляд;
• затвердженізапитинапридбаннятоварівпозначаютьсяяктакі,заяки
мипотімздійснюєтьсязамовленнятоварів;
• яктількизамовленнязроблено,документуформатіXML,дедеталізу
ютьсязамовлення,поміщаєтьсявчергузамовлень,азамовлення,щопотра
пиловтакучергу,позначаєтьсяякрозміщене;
• окремийдодатокпостачальникатоваріввитягуєXML-файл
іззамовленнямзчерги,аналізуєдокументиінаправляєперелікзамовлених
товаріввідповіднимпостачальникам;
• післянадходженняіреєстраціївсіхнеобхіднихтоварівзамовлення
одержуєстатусвиконаного,акористувачупередаєтьсяінформація,щовін
можеїходержати.
Післярозробкиспецифікаціївимогможнапереходитидо проектуванняпрецедентів, яківизначаютьфункціонуваннясистемизпоглядукористувача.ДляцьогонеобхідноспочаткувизначитиакторівсистемиАктор-цезовніш-
нійсуб'єкт(людинаабоіншапрограмнасистема),якийбудевзаємодіятиізстворюванимдодатком.Наосновірозробленоїспецифікаціївимогможнавказатинаступнихакторів:Користувач,Менеджервідділу,Менеджер-постачальник,Додатокпостачальникатоварів.
Тепербезпосередньовизначимопрецеденти,виконуванідодаткомнакористькожногозвказанихакторів.Прецедентиможнавизначитизаокремимипропозиціямиспецифікаціївимог.Наприклад,нанеобхідністьзадатипрецедентВхідвсистемувказуєтьсяпропозиція«Привходівсистемукористувачіповинніуказуватисвоєім'яіпароль».Прецедентипроектованогододаткузведенівтабл.7.3.
Післяпідготовкиспецифікаціївимогможнаприступатидоствореннядіаграмипрецедентів.Нарис.7.24показанийпроекттакоїдіаграми.Зобразившинадіаграміпрецеденти,визначимовідношенняміжними,якіможутьбутидвохтипів: відношеннявключення, щоідентифікуютьсяключовимсловомincludes,і відношеннярозширення, визначуваніключовимсловомextends. Відношеннявключення означає,щопрецедент,якийявновключаєповедінкуіншого,повиненвиконуватисяякпередумова.Наприклад,прецедентВхідусистемуможебутивключенийвпрецедентПереглядкаталогутоварів(рис.7.25).Протепершийзнихвизначаєтьсяякокремий,оскількиможевикористовуватисяйіншимипрецедентами.Зокрема,вінбудетакожвключенийвпрецедентКонтрользавитрачаннямтоварів.
Таблиця7.3. Прецеденти
| НАЗВА | АКТОРИ | ОПИС |
| Вхідусистему | Користувач,менеджервідділу,менеджер-постачальник | Користувачудоступневікновходувсистему,девінвводитьім'яіпароль,апотімтисненакнопкуОКабоВідміна.Діставшидоступдододатка,користувачможепроглянутиінформаціюпротовари |
| Переглядкаталогутоварів | Користувач,менеджервідділу,менеджер-постачальник | Передкористувачемвідображаєтьсятаблиця-каталогізперелікомтоварів.Утаблиціуказуєтьсяназватовару,категорія,описівартість.Користувачможепроглянутитоварипевноїгрупи |
| Запитнапридбання | Користувач,менеджервідділу | Користувачвибираєпотрібнітовариінатискаючинакнопкиможедоповнюватисвійсписокзамовлення.Вокремійтаблицізазначаютьсятовари,вибранікористувачем,їхкількістьівартість,атакожзагальнавартістьзамовлень. |
| Запитнапридбання | Менеджервідділу | Менеджервідділувідзначаєпотрібнітоваривтаблиціінатискаєнакнопку,щобдодатиїхдосвогосписку.В |
| відвідділу | окремійтаблицівідображаєтьсяінформаціяпротовари,вибраніменеджером,їхкількістьівартість,атакожвартістьвсьогозамовлення | |
| Прогляданнязамовлень | Менеджервідділу | Менеджервідділупроглядаєвсізамовлення,щопоступилинарозглядвідспівробітниківвідділу.Потімзатверджуєабовідміняєїх,прощоробитьвідповідніпомітки.Привідхиленнізамовленняменеджерстислоуказуєпричинувідмови |
| Контрольвитратитоварів | Менеджервідділу | Менеджервідділупроглядаєданіпровикористовуванняканцтоварівкожнимспівробітникомвідділузазвітнийперіодівизначаєсумудлявсьоговідділу |
| Веденнякатало- | Менеджер-постачальник | Менеджер-постачальникможеобновлятиінформаціюпротовари,додаючидоспискуданіпроновінадходженняівідзначаючивипадкиприпиненняпостачаннядеякихзтоварів |
| Реєстраціятоварів | Менеджер-постачальник | Менеджер-постачальниквикликаєвікнодлявведенняномеразамовлення,потімвідкриваєсписокзназвамизамовленихтоварівівідзначаєодержані.Коливсівказанівзамовленнітовариодержані,замовленняреєструєтьсяяквиконане |
| Розміщеннязамовлень | Додатокпостачальникатоварів | ДодатокпостачальникаперевіряєзагальнийсписокXML-файлівіззамовленнями.Файливитягуються,аналізуютьсяізаносятьсядоспискузамовленьвідповідногопостачальника |
| Переглядкаталогутоварів |
| Менеджер-постачальник |
| Менеджервідділу |
| Контрольвитраченнятоваоів |
Додатокпостачальникатоварів
Рис.7.24. Проектдіаграмипрецедентів
Прецедентдіаграмипрецедентів
|
| Контроль витрачення товарів |
Рис.7.25. ДодаванняпрецедентуВхідусистемувпрецедентПереглядкаталогутоварів
зних(залежновідумови)доповнюєповедінкаіншого,щоєпочатковим.Оформляючизапитнапридбання,менеджерможевказати,щотовариотримуютьсядлявсьоговідділу.ВцьомувипадкупрецедентЗапитнапридбаннявідвідділустаєрозширеннямпрецедентуЗапитнапридбання.Нарис.7.26наведенадіаграма,уякійпоказановідношеннярозширення.
Запитнапридбаннятоварів
Т
"extend^
Запитнапридбаннятоваріввід вішип\
Рис.7.26. Відношеннярозширенняпрецеденту"Запитнапридбаннятоварів"
Аналізсистемнихвимогіпрецедентів,щовикористовуються,дозволяєспроститипроектуваннясистемишляхомвиділеннявнійокремихфункціональнихчастин.Аце,усвоючергу,забезпечуєможливістьрозбитипроцеспроектуваннянадекількаетапів.Спочаткуприступимодопроектуваннятієїчастинидодатка,наякійформуютьсязапити.Знеювзаємодіятимутьспівробітникиіменеджеривідділів.Розробленанацьомуетапідіаграмапрецедентівпоказананарис.7.27. Прецедент додатка назамовленнятоварів
|
| Переглядкаталогутоварів |
| Менеджервідділу |
| Запитнапридбаннявідвідділу |
Рис.7.27.ДіаграмапрецедентуЗапитнапридбання
Задаючирізніпрецеденти,можна визначитикласи, необхіднідляреалізаціїтієїфункціональностісистеми,якаописанавпрецедентах.Щобзадатикласи,спочаткуслідрозібратисязкожнимокремимпрецедентом,визначитипослідовністькроківдляйогореалізації.Тутможутьдопомогтиіменаіменниківігрупиіменіменників,щозустрічаютьсявописахпрецедентів.Наприклад,нижчеописанийпрецедентПереглядкаталогутоварів.
• Передумова. Користувачреєструєтьсявсистемі,указуючисвоєім'яіпароль,ідістаєдоступдододатка.188
• 
Опис. Наекранівідображаєтьсякаталогізспискомпропонованихто
варів.Утаблиціуказуютьсяназватоварів,їхкатегорії,короткийописівар
тість.Користувачможепроглядатиінформаціютількипротовари,щонале
жатьдопевноїкатегорії.
• Постумова. Користувачмаєнагодуоформитизапитнапридбанняабо
вийтизсистеми.
Відповіднодоцьогоописуможнавизначитиклас,щовідповідаєзавитяганняінформаціїпротоваризбазиданихізавідбірназвтоварів,щовиводятьсянаекран.НазвемоцейкласProductCatalog(Каталогтоварів).
Проаналізувавшиіменаіменникиігрупиіменвописахпрецедентів,щовідносятьсядооформленнязапитів,встановимо можливікласидодатка (табл.7.4).
Перерахувавшивсіможливікласидодатка,усунемозцьогоспискузайві.Наприклад,посиланнянатоварізаписуспискузназвоюзамовленоготовару-однейтесамо.Крімтого,слідусунутикласи,щоозначаютьнеоб'єкти,аїхвластивості.
Таблиця7.4. Класи,якіможутьвикористовуватисяприоформленнізапитів
напридбання
| ПРЕЦЕДЕНТ | МОЖЛИВІКЛАСИ |
| Вхідусистему | Користувач(співробітниквідділу,менеджер),ім'якористувача,пароль,вхідусистему,відмовавреєстрації |
| Переглядкаталогу | Користувач(співробітниквідділу,менеджер),кагалогтоварів,товари,інформаціяпротовари,назватовару,категорія,опис,вартість |
| Запитнапридбання | Користувач(співробітниквідділу,менеджер),товар,список,номер,записзназвоюпотрібноготовару,вартість,загальнавартість |
| Запитнапридбання відвідділу | Менеджер,товари,замовлення,номер,записзназвоюпотрібноготовару,вартість,загальнавартість,запитнапридбаннявідвідділу |
|
Дотакихвідносятьсяім'яіпаролькористувача,атакожвартістьтовару.Деякікласивизначенінеоднозначно,абоєузагальненнямякихосьоб'єктів,припустимо,користувачаіменеджера.
Класиможутьтакожвідноситисядоодногоітогожоб'єкта,указуватинайогорізністани.Так,запитнатоварізамовленняєоднеітежпоняття,алеоднаназвазастосовуєтьсядозатвердженняйогоменеджером,аінша-після.Необхідноусунутиітікласи,якіпредставляютьструктурніелементи
189
системи.Донихвідносятьсятаблицяісписок.Наприклад,списокскладаєтьсязбезлічізаписівізназвамитоварівуконкретномузамовленні.
Використовуючизгаданікритерії,списоккласівможнаскоротити,івінбудематитакийвигляд:Employee(Співробітниквідділу),Manager(Менеджер),Order(Замовлення),Orderltem(Елементспискузамовлення),ProductCatalog(Каталогтоварів),Product(Товар).
Можнатакождодатикласи,щопредставляютьакторів,яківзаємодіятимутьізсистемою.Цеспеціальнікласи,такзванікласи акторів. Надіаграмікласіввонизастосовуютьсядлямоделюванняінтерфейсу,щозабезпечуєвзаємодіюміжсистемоюіактором.
Наприклад,класактораPurchaser(UI)(Користувач)описуєграфічнийінтерфейс,якийкористувач(співробітниквідділу,менеджер)використовуватимеприоформленнізапиту.Оскількитакікласинасправдінеєчастиноюсистеми,їхвнутрішнійвміствідокремленийвідсистеми,івонавзаємодієзними,якз«чорнимиящиками».
Теперможнаформувати діаграмукласів (рис.7.28)длячастинидодатка,щовідноситьсядозапитунапридбання.
Puchaser(UI)
Employee
ProductCatalog
Product
DepartmentManager
Order
Orderltem
Рис.7.28. Ескіздіаграмикласів
Нанаступномуетапіпроектуваннянеобхідновизначити рівеньабстрагування длякожногореалізованогокласу.Цедозволитьвиділитинеобхідніхарактеристикиоб'єктів,невникаючиприцьомувспособиїхреалізації.Такимчиномдлякожногокласуможнабудезадатийоговластивості.
АналізвимогкласуEmployeeпоказує,щояквластивостікласуповиннібутизаданізареєстрованеім'якористувача,пароль,кодабоназвавідділуіознака,вказуюча,чиєкористувачменеджером.
Крімтого,потрібноввестиідентифікаторспівробітника,атакожім'яіпрізвище,заякимименеджерзможеконтролювативитратуканцтоварівцимспівробітником.Властивостікласівпроектованогододаткаперерахованівтабл.7.5.
Нарис.7.29показано діаграмукласівіїхвластивостей. МиопустиливластивостікласуDepartmentManager,оскількивінуспадковуєвластивостікласуEmployee.
Наступнийетаппроцесупроектування -моделюванняасоціаційкласів, якіописуютьструктурнівідносиниміжекземплярамикласів.Асоціаціївключаютьсявмоделькласівнаосновірезультатіваналізузаданихпрецедентівіспецифікаціївимог.
Оскількикожнезамовленняформуєтьсяоднимспівробітником,міжнимтазамовленняміснуєвідношенняпевноготипу(визначенаасоціація).
Таблиця7.5. Властивостікласівдодатканазамовленняканцтоварів
| Клас | Властивості | Типзна- |
| чення | ||
| Employee(Співробітник | EmployeelD(Ідентифікаторспівробітника) | Integer |
| відділу) | LoginName(Зареєстрованеім'я) | String |
| Password(Пароль) | String | |
| Department(Відділ) | String | |
| FirstName(Ім'я) | String | |
| LastName(Прізвище) | String | |
| Manager(Менеджер) | EmployeelD(Ідентифікаторспівробітника) | Integer |
| LoginName(Зареєстрованеім'я) | String | |
| Password(Пароль) | String | |
| Department(Відділ) | String | |
| Order(Замовлення) | String | |
| FirstName(Ім'я) | String | |
| LastName(Прізвище) | Long | |
| Order(замовлення) | OrderNumber(Номерзамовлення) | Date |
| Orderltem | OrderDate(Датазамовлення) | String |
| (Елементспискузамов- | Status.(CTaTyc) | String |
| лення) | ProductNumber(Номертовару) | Short |
| Quantity(Кількість) | Decimal | |
| Product(Товар) | UnitPrice(Цінаодиницітовару) | String |
| ProductNumber(Номертовару) | String | |
| ProductName(Найменуваннятовару)Description | String | |
| (Опис) | Decimal | |
| UnitPrice(Цінаодиницітовару) | String | |
| VendorCode(Кодпостачальника) | ||
| ProductCatalog(Каталог | . | |
| товарів) |
Причомукожнийспівробітникможесформуватибезлічзамовлень,алеокремезамовленняможебутиасоційованотількизоднимспівробітником.
Puchaser(Ul)
ProductCataloq
Employee
Order
Product
EmployeelDilnteger
LoginName.String
Departament.String
FirstName:String
LastName.String
OrderNoilntegerOrderDateiDateTime
OrderNumber
ProductNo:StringProductName:String
DepartmentManager
ProductNo-.String
Quantity:lnteger
UnitPrice:Real
Рис.7.29. Діаграмакласівіїхвластивостейдлячастинидодатка,щовиконує
оформленнязамовлень
Асоціаціятакоготилупроілюстровананарис.7.30.Зірочка порт ізстрілкоюуказує,щозкожнимспівробітникомможебутиасоційовананескінченнабезлічзамовлень.
Employee
Order
Рис.7.30.АсоціаціяміжкласамиEmployeeіOrder
Порівнявшисписоквластивостейкласів,випобачили,щокласиEmployeeіDepartment—»Managerмаютьодніітіжвластивості,оскількименеджертакожєспівробітником.УданомудодаткукласDepartmentManagerпредставляєспівробітникавідділу,якийвиконуєспецифічніфункції,томуданийкласуспадковуєструюуруіповедінкукласуEmployee,тобтоміжцимикласамиіснуєвідношенняспадкоємства.Нарис.7.31представленодіаграмукласівіззаданимвідношеннямспадкоємства.
Employee
DepartmentManager
Рис.7.31. КласDepartmentManagerуспадковуєвластивостікласуEmployee
Длявсіхкласівдодаткавизначенінаступніасоціації:
• екземпляркласуEmployee-декількаекземплярівкласуOrder;
• екземпляркласуOrder-одинекземпляркласуEmployee;
• екземпляркласуProductCatalog-декількаекземплярівкласу
Product;
• екземпляркласуProduct-одинекземпляркласуProductCatalog;
• екземпляркласуOrderltem-одинекземпляркласуProduct;
•екземпляркласуProduct-декількаекземплярівкласуOrderltem.
МіжкласамиOrderіOrderltemвизначеновідношенняагрегації.Крім
того,класDepartmentManager-цекласEmployee,щореалізовуєрядспецифічнихдодатковихфункцій.Нарис.7.32всіцікласипоказанііззаданимивідношеннямиасоціації.
ProductCatalog
Product
 | |||||||
 | |||||||
 |  |
| \/Urderltemh'arf |
| Employee | ""•jOrder | ||
| Puchaser(Ul) | |||
| 1ь | DepartmentManager | ||
Orderltem
Рис.7.32. Діаграмакласівізвідношеннямиасоціаційчастинидодатка,щовідносятьсядовиконаннязапитів
Розробившиескізмоделікласів,можнаприступатидо моделюванняїхвзаємодії. Дляцьогонеобхіднодетальнопроаналізуватиописпрецедентівістворитибільшдокладнийсценарійїхвиконання.Наступнийсценарійописуєоднузможливихпослідовностейвиконанняпрецеденту. Вхідвсистему.
1. Наекраніз'являєтьсядіалоговевікнодлявходувсистему.
2. Користувачвводитьсвоєім'яіпароль.
3. Користувачпідтверджуєвведенуінформацію.
4. Виконуєтьсяперевіркаіменііпароля,встановлюєтьсяїхавтен
тичність.
5. З'являєтьсявікнодляоформленнязапиту.
Перерахованіосновнідії1-5,вироблюваніпривиконанніпрецедентуВхідвсистему.Уіншомувипадкуможезнадобитисяуказуватидекількарізнихваріантіввиконаннядій.НаступнийсценарійописуєальтернативнийваріантпрецедентуВхідвсистему.
1.З'являєтьсядіалоговевікновходувсистему.
2. Користувачвводитьім'яіпароль.
3. Користувачпідтверджуєвведенуінформацію.
4. Виконуєтьсяперевіркаіменііпароля,протевонивиявляються
неправильними.
5. Користувачодержуєповідомленняпронедостовірністьпароля
абоімені(аботоготаіншого).
6. Наекранізновуз'являєтьсядіалоговевікновхідусистему.
7. Користувачабовводитьновідані,абозакриваєвікно.
Наданомуетапістворенийсценарійкращевсьогопредставитиувиглядідіаграмидіяльності.ТакадіаграмадлясценаріюпрецедентуВхідвсистемузображенанарис.7.33.
Проаналізувавшипроцеси,пов'язанізсценаріямипрецедентів,слідвизначитиповедінкукласівсистеми.Дляцьогозастосовуютьсядіаграмидвохвидів: діаграмипослідовностей (щовідображаютьупершучергупо-194
рядоквзаємодіїоб'єктів)і діаграмикооперації (приїхстворенніосновнуувагузвертаютьназв'язкиміжоб'єктами).Нарис.7.34показанодіаграмупослідовностейобохсценаріївпрецедентуВхідусистему.СпочаткуекземпляркласуPurchaser(UI)викликаєметодLoqin(Вхідвсистему)класуEmployee,апотімпередаєтьсяповідомленняпроавтентичністьіменііпаролякористувача.ТеперрозглянемопрецедентПереглядкаталогутоварів.Даліприведенойогосценарій.
1. Користувачпідтверджуєдані,введеніїмпривходівсистему.
2. Користувачпроглядаєтаблицюзінформацієюпротовари,їхкатего
рії,характеристикиівартість.
3. Користувачвибираєкатегоріюіобновляєтаблицю.
Вхідусистему
(Повторнаспроба)
Перевіркакористувача
^ДКористувачнепішовнаперевірку]
[Користувачпішовнаперевірку]
Вивіднаекранповідомленняпропомилку
[ЗакриттявікнаВхідусистему]Рис.7.33. ДіаграмадіяльностідлясценаріюпрецедентуВхідусистему
Затекстомцьогосценаріюможнавизначити,щодляотриманняспискукатегорійтоварів(CategoryList)потрібенметодкласуProductCatalog.
PuchaserСІЛ):
Employee:
МетодLoqin
"ВГдїїов1д1ь"на"в"йк^ик"методуUoqTnjРис.7.34. ДіаграмапослідовностейпроцесуВхідусистему
ЦейметодвикликатиметьсяекземпляромкласуPurchaser(UI).ІншийметодкласуProductCatalogповертатимесписоктоварівобраноїкатегорії.Діаграмапослідовностей,зображенанарис.7.35,відображаєвзаємодіюміжкласамиPurchaser(Ul)іProductCatalog
НаступнийсценарійрозробленийдляпрецедентуЗапитнапридбання.
1,Користувачввівданідлявходувсистемуібувідентифікований
якспівробітник.
2.Користувачвибираєзкаталогуназвипотрібнихтоварівідодає
їхдосвогозамовлення(списку),указуючинеобхіднукількість.
Puchaser(UP:
ProductCatalog:
спискукатегорійтоварш
СписоккатегорійтоварівЗапитспискутоварів
П
Списоктоварів
Рис.7.35. ДіаграмапослідовностейдлясценаріюПереглядкаталогутоварів
3. Закінчившивибіртоварів,користувачподаєзамовлення.
4. Інформаціяпрозамовленняобновляється,замовленнюпривласню
єтьсяномер,якийвідображаєтьсянаекрані.
Згіднозописанимсценарієм,потрібностворитиметодAddltemкласуOrder.Цейметодприйматимеідентифікатортовару(ProductNO)ійогокількість(Quantity),аповертати-проміжнупідсумковувартістьтоварів(SubTotai).КласOrder,усвоючергу,викликатимеметодкласуOrderItem,задопомогоюякогостворюєтьсяекземпляркласуOrderltem.Длязамовленняіповерненняідентифікаторазамовлення(OrderlD),оформленоговзапиті,знадобитьсяметодSubmit Order класуOrder.Діаграмупослідовностейдляцьогосценаріюнаведенонарис.7.36.
Крімтого,необхіднорозробитисценаріїдлявидаленнязаписупротоварізспискукористувача,зміникількостітовару,щозамовляєтьсяівідмінитипроцедуризамовлення.ТакіжсценаріїіметодизнадоблятьсядляпрецедентуЗапитнапридбаннявідвідділу.Післяаналізусценаріївдлячастинидодатка,щовідноситьсядозапитів,можнапобудувати діаграмукласів (рис.7.37).
CreateOrderltem_AddItem(ProductNO,Quantity)(ProductID,Quantity)^
SubTotai
SubmitOrder
*r-i
Orderl
Рис.7.36. ДіаграмапослідовностейдлясценаріюЗапитнапридбання
Employee
EmployeelD:!integerLoginName:StringDepartament.StringFirstName:StringLastName:String
| Product | |||||
| ProductCataJog | FroductNo.Stnng | ||||
| ListProducts() | Category:DiscriptioUnilPriceVendorCc | Stringn:String | |||
| Stringde:Slring | |||||
| Order | |||||
| OrderNo:IntegerOrderDate.DateTime | OrderltemPart | ||||
| Addltem() | Orderltem | ||||
| Removeitem()SubmitOrder() | <JV► * | ProductNo:StringQuantily:Inteqer | |||
| UmtPrice.Real | |||||
Дата добавления: 2016-11-18; Мы поможем в написании ваших работ!; просмотров: 440 | Нарушение авторских прав Лучшие изречения:
| 2107 - 