Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Открытый международный университет развития человека Украина

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Інформаційні ресурси_ навчальний посібник_ В. Я...doc

Скачиваний:

Добавлен:

01.05.2025

Размер:

1.55 Mб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1920 / 2220 21 22 > Следующая >>>

7.2.UmLіоб'єктно-оріентованемоделювання

Уніфікованамовамоделювання(UML-UnifiedModelingLanguage)^стандартнимінструментомдлястворення"креслень"програмногозабезпечення.ЗадопомогоюUMLможнанамалювати,специфікувати,сконструюватиідокументуватиконтактипрограмнихсистем.

UMLпридатнадлямоделюваннябудь-якихсистем:відінформаційнихсистеммасштабупідприємствадорозподіленихWeb-додатківінавітьвбудованихпрограмреальногочасу.

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

СловникмовиUMLвключаєтривидибудівельнихблоків[2,4,32,57,75]:сутності,відносини,діаграми.

Сутності-цеабстракції,щоєосновнимиелементамимоделі.Відносинизв'язуютьрізнісутності;діаграмигрупуютьсукупністьсутностей.

ВUMLєчотиритиписутностей:структурні,поведінкові,групуючи,анотаційні.

Сутностієосновнимиоб'єктно-орієнтованимиблокамимови.Зїхдопомогоюможнастворюватикоректнімоделі.

Структурнісутності-цеіменаіменникивмоделяхнамовіUML.Якправило,вониєстатистичнимичастинамимоделі,відповідаючимиконцептуальнимабофізичнимелементамсистеми.Існуєсімрізновидівструктурнихсутностей.

169

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).

170

EvenManager

suspend()flush()

Рис.7.9.

Активні

класи

Триіншісутності-активнікласи,компонентиівузли-подібнідокласів:вониописуютьсукупністьоб'єктівіззагальнимиатрибутами,операціями,відносинамиісемантикою.Протевонидоситьчітковідрізняютьсяодинвідодногоівідкласіві,враховуючиїхважливістьпримоделюванніпевнихаспектівоб'єктно-орієнтованихсистем,заслуговуютьспеціальногорозгляду.Активнимкласом(Activeclass)називаєтьсяклас,об'єктиякогозалученідоодногоабодекількохпроцесів,абониток(Threads),ітомуможутьініціюватиуправляючудію.Активнийкласувсьомуподібнийдозвичайногокласу,завиняткомтого,щойогооб'єктамиєелементи,діяльністьякихздійснюєтьсяодночасноздіяльністюіншихелементів.Графічноактивнийкласзображуєтьсятаксамо,якпростийклас,алеобмежуючийпрямокутникмалюєтьсяжирноюлінієюізвичайновключаєім'я,атрибутиіоперації(рис.7.9).Дваелементи,щозалишилися,-компонентиівузли-такожмаютьособливості.Вонивідповідаютьфізичнимсутностямсистеми,тодіякп'ятьпопередніх-концептуальнимілогічнимсутностям.

overform.java

Компонент(Component)-цефізичназамінюваначастинасистеми,якавідповідаєдеякому

Рис.7.10.Компоненти^набоРУінтерфейсівізабезпечуєйогореалізацію.У

Рис.7.11.Вузли

системізустрічаютьсярізнівидивстановлюванихкомпонентів,такіякСОМ+абоJavaBeans,атакожкомпоненти,щоєартефактамипроцесурозробки,наприклад,файлипочатковогокоду.Компонент,якправило,єфізичноюупаковкоюлогічнихелементів,такихяккласи,інтерфейсиікооперації.Графічнокомпонентзображаєтьсяувиглядіпрямокутниказвкладками,щомістятьтількиім'я(рис.7.10).Вузол(Node)-цеелементреальної(фізичної)системи,якийіснуєпід

часфункціонуванняпрограмногокомплексуієобчислювальнимресурсом,

171

щоволодіє,якмінімумдеякийобсягомпам'яті,ачастощеіздатністюоброблятицюпам'ять.Сукупністькомпонентівможерозміщуватисяувузлі,атакожмігруватизодноговузлавінший.Графічновузолзображаєтьсяувиглядікуба,щоміститьтількиім'я(рис.7.11).

Цісімбазовихелементів-класи,інтерфейси,кооперації,прецеденти,активнікласи,компоненти,вузли-єосновнимиструктурнимисутностями,якіможутьбутивключенівмоделіUML.Існуютьтакожрізновидицихсутностей:актори,сигнали,утиліти(видикласів),процесиінитки(видиактивнихкласів),додатки,документи,файли,бібліотеки,сторінкиітаблиці(видикомпонентів).

Поведінковісутності(Behavioralthings)єдинамічнимискладовимимоделіUML.Цедієсловамови:вониописуютьповедінкумоделівчасііпросторі.Існуєвсьогодваосновнихтипиповедінковихсутностей-взаємодіяіавтомат.

Взаємодія(Interaction)-цеповедінка,сутьякоїполягаєвобмініповідомленнями(Messages)міжоб'єісгамивмежахконкретногоконтекстудлядосягненняпевноїмети.Задопомогоювзаємодіїможнаописатиякокремуоперацію,такіповедінкусукупностіоб'єктів.Взаємодіяприпускаєрядіншихелементів,такихякповідомлення,послідовностідій(поведінка,ініційованаповідомленням)ізв'язкиміжоб'єктами.Графічноповідомленнязображаютьсяувиглядістрілки,надякоюмайжезавждивказуєтьсявідповіднаоперація(рис.7.12).

„._Автомат(Statemachine)-цеалгоритмповедін-

Відобразити

ки,щовизначаєпослідовністьстанів,черезякіоб'єкт Рис.7.12. Повідомлення^а^°^взаєм°Д'^япроходятьпротягомциклуувідповідь

нарізніподії,атакожреакціїнаціподії.Задопомо гоюавтоматаможнаописатиповедінкуокремого класуабокоопераціїкласів.Завтоматомпов'язаний рядіншихелементів:стани,переходи(зодногоста- I.)нувінший),події(сутності,щоініціюютьпереходи)і

видидій(реакційнаперехід).Графічностанзображу-Рис.7.13.Стани

єтьсяувиглядіпрямокутникаіззакругленимикутами,щоміститьім'яі,можливо,підстани(рис.7.13.).

172

Цідваелементи-взаємодіяіавтомат-єосновнимиповедінковимисутнос-тями,щовходятьумодельUML.Семантикоювоничастопов'язанізрізнимиструктурнимиелементами,упершучергу-класами,коопераціямиіоб'єктами.

ГрупуючисутностієорганізуючимичастинамимоделіUML.Цеблоки,наякіможнарозкластимодель.Єтількиоднапервиннагрупуючасутність-пакет.

Бізнес—правила

Пакети(Packages)—єуніверсальниммеханізмоморганізаціїелементівугрупі.Упакетможнапоміститиструктурні,поведінковіі,навіть,іншігрупуючисутності.Навідмінувідкомпонентів,іс-Рис.7.14.Пакетинуючихпідчасроботипрограми,пакетимаютьчистоконцептуальнийхарактер,тобтоіснуютьтількипідчасрозробки.Пакетзображуєтьсяувиглядітекиіззакладкою,щомістить,якправило,тількиім'я,аіноді-вміст(рис.7.14).

Пакети-цеосновнігрупуючисутності,задопомогоюякихможнаорганізуватимодельUML.Існуютьтакожваріаціїпакетів,наприкладкаркаси(Frameworks),моделітапідсистеми.

Анотаційнісутності-частинипоясненьмоделіUML.Цекоментарідлядодатковогоопису,поясненняабозауваженнядобудь-якогоелемента

моделі.Єтількиодинбазовийтипанотаційних

Рис.7.15.Примітки

елементів-примітка(Note).

Примітка—цепростосимволдлязображеннякоментарівіобмежень,приєднанихдоелементаабогрупиелементів.Графічнопримітказображуєтьсяувиглядіпрямокутникаіззаломленимверхнімкраєм,щоміститьтекстовийабографічнийкоментар(рис.7.15).Цейелементєосновноюанотацій-ноюсутністю,якаможевключатисядомоделіUMLНайчастішеприміткувикористовуютьдлязабезпеченнядіаграмикоментарямиабообмеженнями,якіможнавиразитиувиглядітексту.Існуютьваріаціїприміток,наприклад,вимоги,деописуютьякусьбажануповедінкузпоглядузовнішньоїповід-

173

ношеннюдомоделі.

УмовіUMLвизначеночотиритипивідносин:залежність,асоціація,узагальнення,реалізація.

Цівідносиниєосновнимизв'язуючимибудівельнимиблокамивUMLізастосовуютьсядляствореннякоректнихмоделей.

Залежність(Dependency)—цесемантичне

р.відношенняміждвомасутностями,приякомузмі наоднієїзних,незалежної,можевплинутинасе- Рис.7.16.

Залежністьмантикуіншої,залежної.Графічнозалежністьзо-

бражуєтьсяувиглядіпрямоїпунктирноїлінії,частоізстрілкою(рис.7.16).

Асоціація(Association)-структурневідношення,щоописуєсукупністьзв'язків;зв'язок-цез'єднанняміжоб'єктами.

Різновидомасоціаціїєагрегація(Aggregation).Такназиваютьструктурневідношенняміжцілимійогочастинами.Графічноасоціаціязображуєтьсяувиглядіпрямоїлінії(стрілкою,щоінодізавершуєтьсяабощоміститьмітку),порядзякоюможутьбутиприсутнідодатковіпризначення,наприклад,кратністьііменаролей.Нарис.7.18показаноприкладвідносинцьоготипу.

Узагальнення(Generalisation)-цевідношення"спеціалізація/узагальнення",приякомуоб'єкт

спеціалізованогоелементу(нащадок)можебути Рис.7.17.Уза гальненняпідставленийзамістьоб'єктаузагальненогоелеме нта(батькаабопредка).Такимчином,нащадок (Child)успадковуєструктуруіповедінкусвогоба тька(Parent).Графічновідношенняузагальнення 0...1*

зображуєтьсяувигляділініїзнезамальованою

роботодавецьробітникстрілкою,якавказуєнабатька(рис.7.17).

__..Нарешті,Реалізація(Realization)-цесеман-

Рис.7.18.Асоціації

тичневідношенняміжкласифікаторами,приякомуодинкласифікаторвизначає"контракт",аінший

174

гарантуєйоговиконання.Відносиниреалізаціїзустрічаютьсяудвохвипадках:по-перше,міжінтерфейсамиіреалізуючимиїхкласамиабокомпонен-Рис.7.19.

Реалізаціїтами,апо-друге,міжпрецедентамиіреалізовую-

чимиїхкоопераціями.

Відношенняреалізаціїзображуєтьсяувиглядіпунктирноїрисизнезафарбованоюстрілкою,якщосьсереднєміжвідносинамиузагальненняізалежності(рис.7.19).

Чотириописаніелементи(залежність,асоціація,узагальненняіреалізація)єосновнимитипамивідносин,щоможнавключатидомоделіUML.Існуютьтакожіхваріації,наприклад,уточнення(Refinement),трасування(Trace),включенняіпоширення(длязалежності).

ДіаграмавUML-цеграфічнепредставленнянаборуелементів,щонайчастішезображуєтьсяувиглядізв'язаногографазвершинами(сутностя-ми)іребрами(відносинами).

Діаграмистворюютьдлявізуалізаціїсистемизрізнихточокзору.Діаграма,удеякомурозумінні,-одназпроекційсистеми.Якправило,завиняткомнайтривіальнішихвипадків,діаграмидаютьзгорнутеуявленняелементів,зякихскладаєтьсясистема.Одинітойжеелементможебутиприсутнійувсіхдіаграмах,аботількивдекількох(найпоширенішийваріант),абонебутиприсутнійніводній(дужерідко).Теоретичнодіаграмиможутьміститибудь-якікомбінаціїсутностейівідносин.Протенапрактицізастосовуєтьсяпорівняноневеликакількістьтиповихкомбінацій,яківідповідаютьдев'ятьомнайпоширенішимтипамдіаграм:класів,об'єктів,прецедентів,послідовностей,кооперації,станів,взаємодій,компонентів,розгортання.

Надіаграмікласівпоказуютькласи,інтерфейси,об'єктиікооперації,атакожїхвідносини.Примоделюванніоб'єктно-орієнтованихсистемцейтипдіаграмвикористовуютьнайчастіше.Вінвідповідаєстатичномувидусистемизпоглядупроектування.Діаграмикласів,яківключаютьактивнікласи,відповідаютьстатичномувидусистемизпоглядупроцесів.

175

Надіаграміоб'єктівпредставляютьоб'єктиівідносиниміжними.Вониєстатичними"фотографіями"екземплярівсутностей,показанихнадіаграмахкласів.Діаграмиоб'єктів,якідіаграмикласів,відносятьсядостатичноговидусистемизпоглядупроектуванняабопроцесів,алезрозрахункомнасправжнюабомакетнуреалізацію.

Надіаграміпрецедентівпредставленіпрецедентиіактори(окремийвипадоккласів),атакожвідносиниміжними.Діаграмипрецедентіввідносятьсядостатичноговидусистемизпоглядупрецедентіввикористовування.Вониособливоважливіприорганізаціїімоделюванняповедінкисистеми.

Діаграмипослідовностейікоопераціїєокремимвипадкомдіаграмвзаємодії.Надіаграмахвзаємодійпредставленізв'язкиміжоб'єктами;показані,зокрема,повідомлення,якимиоб'єктиможутьобмінюватися.Діаграмивзаємодіївідносятьсядодинамічноговидусистеми.Діаграмипослідовностівідображаютьтимчасовувпорядкованістьповідомлень,адіаграмикооперації-структурнуорганізаціюоб'єктів,щообмінюютьсяповідомленнями.Цідіаграмиєізоморфними,тобтоможутьбутиперетвореніоднанаодну.

Надіаграмахстану(Statechartdiagrams)представляєтьсяавтомат,щовключаєстани,переходи,подіїівидидій.Діаграмистанувідносятьсядодинамічноговидусистеми,вониважливіпримоделюванніповедінкиінтерфейсу,класуабокооперації;акцентуютьувагунаповедінціоб'єкту,залежнійвідпослідовностіподій,щодужекориснодлямоделюванняреактивнихсистем.

Діаграмавзаємодії-цеокремийвипадокдіаграмистанів;нанійзображуютьсяпереходипотокууправліннявідоднієїдіяльностідоіншоїусерединісистеми.Діаграмивзаємодіївідносятьсядодинамічноговидусистеми;вонинайбільшважливіпримоделюванніїїфункціонуванняівідображаютьпотікуправлінняміжоб'єктами.

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

176

декількакласів,інтерфейсівабокооперацій.

Надіаграмірозгортаннязображуютьконфігураціюоброблюванихвузлівсистемиірозміщенихвнихкомпонентів.Діаграмирозгортаннявідносятьсядостатичноговидуархітектурисистемизпоглядурозгортання.Вонипов'язаніздіаграмамикомпонентів,оскількиувузлі"оглядовий"розміщуютьсяодинабодекількакомпонентів.

Тутприведенонеповнийсписокдіаграм,вживанихвUML.Інструментальнізасобидозволяютьгенеруватийіншідіаграми,аледев'ятьперерахованихзустрічаютьсянапрактицінайчастіше.

БудівельніблокиUMLнеможнадовільнооб'єднуватиодинзодним.Якібудь-якаіншамова,UMLхарактеризуєтьсянаборомправил,щовизначають,якийповиннамативигляддобреоформленамодель:семантичносамо-узгодженаізнаходитисявгармоніїзівсімамоделями,якізнеюпов'язані.

УмовіLJMLєсемантичніправила,щодозволяютькоректноіоднозначновизначити:

імена,якіможнадаватисутностям,відносинамідіаграмам;
сферудії(контекст,уякомуім'ямаєдеякезначення);

видимість(колиіменавидимііможутьвикористовуватисяіншими елементами);
цілісність(якелементиповинніправильноіпогодженоспіввідноси тисяодинзодним);

виконання(щозначитьвиконатиабоімітуватидеякудинамічнумодель).

РоботузмовоюUMLістотнополегшуєпослідовневикористаннянаступнихзагальнихмеханізмів:специфікації'(Specifications),доповнення(Adornment),ухваленнярозподілу(Commondivisions),механізмирозширення(Extensibilitymechanisms).

UML-ценепростографічнамова.Закожноючастиноюїїсистемноїграфічноїнотаціїстоїтьспецифікація,щоміститьтекстовепредставленнясинтаксисуісемантикивідповідногобудівельногоблоку.

Наприклад,діаграмікласувідповідаєспецифікація,щоповністюописує

177

операціїцьогокласу(включаючиповнісигнатури)іповедінку,хочавізуальнодіаграмадеколивідображаєтількичастиницієїсукупності.Більштого,можеіснуватиіншепредставленняцьогокласу,щовідображаєвчиненііншійогоаспекти,протевідповіднітійжеспецифікації.Задопомогоюграфічноїнотації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-цестандартнамовадлярозробки«крес-

179

лень»програмногозабезпечення.Алежодназамкнутамованеможеохопитинюансивсіхможливихмоделейвнаочнихсферах.Тому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.

Системнаархітектурає,мабуть,найважливішимартефактом,якийвикористовуєтьсядляуправліннябудь-якимиточкамизоруітимсамимсприяєінтерак-

180

тивнійіінкрементнійрозробцісистеминавсьомупротязіїїжиттєвогоциклу.Архітектура-цесукупністьістотнихрішеньстосовно:

організаціїпрограмноїсистеми;
виборуструктурнихелементів,щостановлятьсистему,іїхінтерфейсів;
поведінкицихелементів,специфікованоїувзаємодіїзіншимиелементами;
складаннязцихструктурнихіповедінковихелементіввсебільші більшкрупнихпідсистем;
архітектурногонаправляючогостилю,щовизначаєвсюорганізацію системи:статичніідинамічніелементи,їхінтерфейси,коопераціїіспосібїх об'єднання.

Архітектурапрограмноїсистемиохоплюєнетількиїїструктурнііпове-дінковіаспекти,алеівикористання,функціональність,продуктивність,гнучкість,можливістьповторноговживання,повноту,економічніітехнологічніобмеженняікомпроміси,атакожестетичніпитання.Архітектурупрограмноїсистемиможнаописатизадопомогоюп'ятивзаємопов'язанихвидівабоуявлень,кожнийзякихєоднієюзможливихпроекційорганізаціїіструктурисистемиізагострюєувагунапевномуаспектіїїфункціонування.

/.Виглядзпоглядупрецедентів(Usecaseview)охоплюютьпрецеденти,якіописуютьповедінкусистеми,якуспостерігаютькінцевікористувачі,аналітикиітестувальники.УмовіUMLстатичніаспектицьоговиглядупередаютьдіаграмамипрецедентів,адинамічні-діаграмамивзаємодіїістанів.

Виглядзпоглядупроектування(Designview)охоплюєкласи,інтер фейсиікооперації,щоформуютьсловникзадачііїїрішення.Задопомогою мовиUMLстатичніаспектицьоговиглядуможнапередаватидіаграмами класівіоб'єктів,адинамічні-діаграмамистануівзаємодії.
Виглядзпоглядупроцесів(Processview)охоплюєниткиіпроцеси,що формуютьмеханізмипаралелізмуісинхронізаціївсистемі.ВUMLйогоста тичніідинамічніаспективізуалізуютьсятимиждіаграмами,щоідлявигля дузпоглядупроектування,алеособливаувагаприцьомунадаєтьсяактивним класам,якіпредставляютьвідповідніниткиіпроцеси.

181

Виглядзпоглядуреалізації(Implementationview)охоплюєкомпоненти іфайли,щовикористовуютьсядлязбиранняівипускукінцевогопрограмного продукту.УмовіUMLстатичніаспектицьоговиглядупередаютьзадопомогою діаграмкомпонентів,адинамічні-задопомогоюдіаграмстанівівзаємодії.
Виглядзпоглядурозгортання(Deploymentview)охоплюєвузли,що формуютьтопологіюапаратнихзасобівсистеми,наякійвонавиконана.Йо гостатичніаспектиописуютьсяпрограмамирозгортання,адинамічні-діаг рамамивзаємодіїістанів.

Моваскладаєтьсязбезлічітекстовихіграфічнихмоделей,необхіднихдляпроектуваннятакихсистем.Цімоделівизначаютьможливостісистеми,їїкомпоненти,способивзаємодіїсистемизкористувачемікомпонентівсистемиодинзодним.ВUMLвикористовуютьсянаступніосновніелементи:

-специфікаціявимогдопрограмногозабезпечення(Software RequirementSpecification,SRS),щорозробляється,-визначенняіопис(доку ментування)загальнихфункційімежсистеми;

прецеденти(елементиUseCase)-графічніаботекстовіописипослі довностідійсистемизпоглядукористувачів(користувачемможебутилюди наабоіншасистема);
діаграмакласів(ClassDiagram)—графічнезображенняпроцесіввза ємодіїоб'єктівпідчасвиконанняпрограми;цядіаграмавизначаєтимчасове упорядкуванняповідомленьміжоб'єктами;
діаграмакооперації(CollaborationDiagram)—графічнезображення потоківвиконанняпроцесівабоопераційусерединісистеми.

Першимкрокомпроектуванняєвиробленнявимогдопрограми.Специфікаціявимогдостворюваногопрограмногопродукту(SoftwareRequirementSpecification,SRS)розробляєтьсядлявирішеннянаступнихзавдань:

формулюванняфункціональнихвимогдосистеми;
установитимежісистеми; визначитикористувачівсистеми;
описатипроцесивзаємодіїміжсистемоюізовнішнімикористувачами;

182

установитиєдинумовуописусистеми,щовикористовуєтьсязамов никомігрупоюпрограмістів;
створитиосновидлямоделюванняпрецедентів.

Припустимо,наприклад,щонаданиймоменткомпаніянезнаєцентралізованогоспособузамовленняканцелярськогообладнаннядлявідділів.Кожнийвідділздійснюєтакізамовленнясамостійно.Томупрактичнонеможливоустановитизагальнівитратинаканцелярськітоваривмасштабахкомпанії,що,усвоючергу,недаєможливостівизначитивитратинацюстаттюіуникнутизловживань[3.2].

Крімтого,завідсутностісистемицентралізованогопостачаннянеможливозабезпечитипошукіукладеннянайвигіднішихконтрактівнапостачаннятоварів.Отже,необхіднорозробитидодаток,нацентралізованезамовленняканцелярськихтоварів.З'ясувавшивсіпитаннязпотенційнимикористувачами,необхіднорозробитиспецифікаціювимог,якавизначатимефункціональністьсистеми,їїмежііможливихкористувачів.

Об'єкти,щовзаємодіютьзсистемою:

користувач(співробітниквідділу)-маєправоподаватизапитина отриманняканцтоварів;
менеджервідділу-контролюєізатверджуєзапитинапридбання канцтоварів,поданіспівробітниками;

•додатокпостачальникатоварів-приймаєфайлизамовленьуформатіXML,створюванісистемою;

•менеджерпоставок-обновляєкаталогтоварів,відстежуєзапитина придбанняканцтоварівіреєструєпостачання.

Функції,виконуванісистемою:

привходівсистемукористувачповиненуказатисвоєім'яіпароль;
користувачмаєнагодупроглянутисписокусіхтоварів,якіможутьбу тизамовлені;
користувачможевиділятивспискутоваризаданоїкатегорії(фільтру ватидані);

183

водномузапитікористувачможевказатидекількавидівтоварів;
менеджервідділумаєправоподаватизагальнийзапитнатоваридля відділу;

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

привідхиленнізапитуменеджервідділузобов'язанийкороткопоясни типричинувідмови;
менеджервідділуповиненстежитизавитратоютоварівувідділітаза безпечуватифінансуваннясхваленихзамовленьнапридбання;

•менеджерпоставокведекаталогтоварівістежитьзайогосвоєчаснимоновленням;

•приотриманнітоварівменеджерпоставокперевіряєїхкомплектністьіякістьізабезпечуєїхрозподілміжвідділами;

•запитинапридбаннятоварів,якінебулизатверджені,позначаютьсяяктакі,щопоступилинарозгляд;

затвердженізапитинапридбаннятоварівпозначаютьсяяктакі,заяки мипотімздійснюєтьсязамовленнятоварів;
яктількизамовленнязроблено,документуформатіXML,дедеталізу ютьсязамовлення,поміщаєтьсявчергузамовлень,азамовлення,щопотра пиловтакучергу,позначаєтьсяякрозміщене;
окремийдодатокпостачальникатоваріввитягуєXML-файл іззамовленнямзчерги,аналізуєдокументиінаправляєперелікзамовлених товаріввідповіднимпостачальникам;
післянадходженняіреєстраціївсіхнеобхіднихтоварівзамовлення одержуєстатусвиконаного,акористувачупередаєтьсяінформація,щовін можеїходержати.

Післярозробкиспецифікаціївимогможнапереходитидопроектуванняпрецедентів,яківизначаютьфункціонуваннясистемизпоглядукористувача.ДляцьогонеобхідноспочаткувизначитиакторівсистемиАктор-цезовніш-

184

нійсуб'єкт(людинаабоіншапрограмнасистема),якийбудевзаємодіятиізстворюванимдодатком.Наосновірозробленоїспецифікаціївимогможнавказатинаступнихакторів:Користувач,Менеджервідділу,Менеджер-постачальник,Додатокпостачальникатоварів.

Тепербезпосередньовизначимопрецеденти,виконуванідодаткомнакористькожногозвказанихакторів.Прецедентиможнавизначитизаокремимипропозиціямиспецифікаціївимог.Наприклад,нанеобхідністьзадатипрецедентВхідвсистемувказуєтьсяпропозиція«Привходівсистемукористувачіповинніуказуватисвоєім'яіпароль».Прецедентипроектованогододаткузведенівтабл.7.3.

Післяпідготовкиспецифікаціївимогможнаприступатидоствореннядіаграмипрецедентів.Нарис.7.24показанийпроекттакоїдіаграми.Зобразившинадіаграміпрецеденти,визначимовідношенняміжними,якіможутьбутидвохтипів:відношеннявключення,щоідентифікуютьсяключовимсловомincludes,івідношеннярозширення,визначуваніключовимсловомextends.Відношеннявключенняозначає,щопрецедент,якийявновключаєповедінкуіншого,повиненвиконуватисяякпередумова.Наприклад,прецедентВхідусистемуможебутивключенийвпрецедентПереглядкаталогутоварів(рис.7.25).Протепершийзнихвизначаєтьсяякокремий,оскількиможевикористовуватисяйіншимипрецедентами.Зокрема,вінбудетакожвключенийвпрецедентКонтрользавитрачаннямтоварів.

Таблиця7.3.Прецеденти

НАЗВА	АКТОРИ	ОПИС
Вхідусистему	Користувач,менеджервідділу,менеджер-постачальник	Користувачудоступневікновходувсистему,девінвводитьім'яіпароль,апотімтисненакнопкуОКабоВідміна.Діставшидоступдододатка,користувачможепроглянутиінформаціюпротовари
Переглядкаталогутоварів	Користувач,менеджервідділу,менеджер-постачальник	Передкористувачемвідображаєтьсятаблиця-каталогізперелікомтоварів.Утаблиціуказуєтьсяназватовару,категорія,описівартість.Користувачможепроглянутитоварипевноїгрупи
Запитнапридбання	Користувач,менеджервідділу	Користувачвибираєпотрібнітовариінатискаючинакнопкиможедоповнюватисвійсписокзамовлення.Вокремійтаблицізазначаютьсятовари,вибранікористувачем,їхкількістьівартість,атакожзагальнавартістьзамовлень.
Запитнапридбання	Менеджервідділу	Менеджервідділувідзначаєпотрібнітоваривтаблиціінатискаєнакнопку,щобдодатиїхдосвогосписку.В

185

відвідділу		окремійтаблицівідображаєтьсяінформаціяпротовари,вибраніменеджером,їхкількістьівартість,атакожвартістьвсьогозамовлення
Прогляданнязамовлень	Менеджервідділу	Менеджервідділупроглядаєвсізамовлення,щопоступилинарозглядвідспівробітниківвідділу.Потімзатверджуєабовідміняєїх,прощоробитьвідповідніпомітки.Привідхиленнізамовленняменеджерстислоуказуєпричинувідмови
Контрольвитратитоварів	Менеджервідділу	Менеджервідділупроглядаєданіпровикористовуванняканцтоварівкожнимспівробітникомвідділузазвітнийперіодівизначаєсумудлявсьоговідділу
Веденнякатало-	Менеджер-постачальник	Менеджер-постачальникможеобновлятиінформаціюпротовари,додаючидоспискуданіпроновінадходженняівідзначаючивипадкиприпиненняпостачаннядеякихзтоварів
Реєстраціятоварів	Менеджер-постачальник	Менеджер-постачальниквикликаєвікнодлявведенняномеразамовлення,потімвідкриваєсписокзназвамизамовленихтоварівівідзначаєодержані.Коливсівказанівзамовленнітовариодержані,замовленняреєструєтьсяяквиконане
Розміщеннязамовлень	Додатокпостачальникатоварів	ДодатокпостачальникаперевіряєзагальнийсписокXML-файлівіззамовленнями.Файливитягуються,аналізуютьсяізаносятьсядоспискузамовленьвідповідногопостачальника

Переглядкаталогутоварів

Менеджер-постачальник

Менеджервідділу

Контрольвитраченнятоваоів

Додатокпостачальникатоварів

186

Рис.7.24.Проектдіаграмипрецедентів

Прецедентдіаграмипрецедентів

Контроль

витрачення

товарів

Рис.7.25.ДодаванняпрецедентуВхідусистемувпрецедентПереглядкаталогутоварів

зних(залежновідумови)доповнюєповедінкаіншого,щоєпочатковим.Оформляючизапитнапридбання,менеджерможевказати,щотовариотримуютьсядлявсьоговідділу.ВцьомувипадкупрецедентЗапитнапридбаннявідвідділустаєрозширеннямпрецедентуЗапитнапридбання.Нарис.7.26наведенадіаграма,уякійпоказановідношеннярозширення.

Запитнапридбаннятоварів

_т

"extend^

Запитнапридбаннятоваріввідвішип\

Рис.7.26.Відношеннярозширенняпрецеденту"Запитнапридбаннятоварів"

187

Аналізсистемнихвимогіпрецедентів,щовикористовуються,дозволяєспроститипроектуваннясистемишляхомвиділеннявнійокремихфункціональнихчастин.Аце,усвоючергу,забезпечуєможливістьрозбитипроцеспроектуваннянадекількаетапів.Спочаткуприступимодопроектуваннятієїчастинидодатка,наякійформуютьсязапити.Знеювзаємодіятимутьспівробітникиіменеджеривідділів.Розробленанацьомуетапідіаграмапрецедентівпоказананарис.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показує,щояквластивостікласуповиннібутизаданізареєстрованеім'якористувача,пароль,кодабоназвавідділуіознака,вказуюча,чиєкористувачменеджером.

190

Крімтого,потрібноввестиідентифікаторспівробітника,атакожім'яіпрізвище,заякимименеджерзможеконтролювативитратуканцтоварівцимспівробітником.Властивостікласівпроектованогододаткаперерахованівтабл.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(Каталог	.
товарів)

191

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

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представленодіаграмукласівіззаданимвідношеннямспадкоємства.

192

Employee

D epartmentManager

Р ис.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
1	1_ь	DepartmentManager
		DepartmentManager

Orderltem

Рис.7.32.Діаграмакласівізвідношеннямиасоціаційчастинидодатка,щовідносятьсядовиконаннязапитів

193

Розробившиескізмоделікласів,можнаприступатидомоделюванняїхвзаємодії.Дляцьогонеобхіднодетальнопроаналізуватиописпрецедентівістворитибільшдокладнийсценарійїхвиконання.Наступнийсценарійописуєоднузможливихпослідовностейвиконанняпрецеденту.Вхідвсистему.

Наекраніз'являєтьсядіалоговевікнодлявходувсистему.
Користувачвводитьсвоєім'яіпароль.
Користувачпідтверджуєвведенуінформацію.
Виконуєтьсяперевіркаіменііпароля,встановлюєтьсяїхавтен тичність.
З'являєтьсявікнодляоформленнязапиту.

Перерахованіосновнідії1-5,вироблюваніпривиконанніпрецедентуВхідвсистему.Уіншомувипадкуможезнадобитисяуказуватидекількарізнихваріантіввиконаннядій.НаступнийсценарійописуєальтернативнийваріантпрецедентуВхідвсистему.

1.З'являєтьсядіалоговевікновходувсистему.

Користувачвводитьім'яіпароль.
Користувачпідтверджуєвведенуінформацію.

Виконуєтьсяперевіркаіменііпароля,протевонивиявляються неправильними.
Користувачодержуєповідомленняпронедостовірністьпароля абоімені(аботоготаіншого).

Наекранізновуз'являєтьсядіалоговевікновхідусистему.
Користувачабовводитьновідані,абозакриваєвікно.

Наданомуетапістворенийсценарійкращевсьогопредставитиувиглядідіаграмидіяльності.ТакадіаграмадлясценаріюпрецедентуВхідвсистемузображенанарис.7.33.

Проаналізувавшипроцеси,пов'язанізсценаріямипрецедентів,слідвизначитиповедінкукласівсистеми.Дляцьогозастосовуютьсядіаграмидвохвидів:діаграмипослідовностей(щовідображаютьупершучергупо-194

рядоквзаємодіїоб'єктів)ідіаграмикооперації(приїхстворенніосновнуувагузвертаютьназв'язкиміжоб'єктами).Нарис.7.34показанодіаграмупослідовностейобохсценаріївпрецедентуВхідусистему.СпочаткуекземпляркласуPurchaser(UI)викликаєметодLoqin(Вхідвсистему)класуEmployee,апотімпередаєтьсяповідомленняпроавтентичністьіменііпаролякористувача.ТеперрозглянемопрецедентПереглядкаталогутоварів.Даліприведенойогосценарій.

Користувачпідтверджуєдані,введеніїмпривходівсистему.
Користувачпроглядаєтаблицюзінформацієюпротовари,їхкатего рії,характеристикиівартість.
Користувачвибираєкатегоріюіобновляєтаблицю.

В хідусистему

(Повторнаспроба)

Перевіркакористувача

^ДКористувачнепішовнаперевірку]

[ Користувачпішовнаперевірку]

Вивіднаекранповідомленняпропомилку

[ЗакриттявікнаВхідусистему]Рис.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.ДіаграмапослідовностейдлясценаріюПереглядкаталогутоварів

196

Закінчившивибіртоварів,користувачподаєзамовлення.

Інформаціяпрозамовленняобновляється,замовленнюпривласню єтьсяномер,якийвідображаєтьсянаекрані.

Згіднозописанимсценарієм,потрібностворитиметодAddltemкласуOrder.Цейметодприйматимеідентифікатортовару(ProductNO)ійогокількість(Quantity),аповертати-проміжнупідсумковувартістьтоварів(SubTotai).КласOrder,усвоючергу,викликатимеметодкласуOrderItem,задопомогоюякогостворюєтьсяекземпляркласуOrderltem.Длязамовленняіповерненняідентифікаторазамовлення(OrderlD),оформленоговзапиті,знадобитьсяметодSubmitOrderкласуOrder.Діаграмупослідовностейдляцьогосценаріюнаведенонарис.7.36.

Крімтого,необхіднорозробитисценаріїдлявидаленнязаписупротоварізспискукористувача,зміникількостітовару,щозамовляєтьсяівідмінитипроцедуризамовлення.ТакіжсценаріїіметодизнадоблятьсядляпрецедентуЗапитнапридбаннявідвідділу.Післяаналізусценаріївдлячастинидодатка,щовідноситьсядозапитів,можнапобудуватидіаграмукласів(рис.7.37).

CreateOrderltem_AddItem(ProductNO,Quantity)(ProductID,Quantity)^

S ubTotai

SubmitOrder

*r-ⁱ

Orderl

Р ис.7.36.ДіаграмапослідовностейдлясценаріюЗапитнапридбання

197

Employee

E mployeelD:!integerLoginName:StringDepartament.StringFirstName:StringLastName:String

		Product
ProductCataJog		FroductNo.Stnng
ListProducts()		Category:DiscriptioUnilPriceVendorCc		Stringn:String
				Stringde:Slring
Order

OrderNo:IntegerOrderDate.DateTime	OrderltemPart			1
Addltem()			Orderltem
Removeitem()SubmitOrder()	<JV► *		ProductNo:StringQuantily:Inteqer
			UmtPrice.Real

Puchaser(UI)

DepartmentManager

L ogin()

Р ис.7.37.Діаграмакласівдлячастинидодатка,щопов'язанііззапитаминапридбання

198

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1920 / 2220 21 22 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

#
27.10.2018180.32 Кб13ідпзк іспит.docx
#
01.05.20252.46 Mб0ІДПЗК.doc
#
01.05.20252.2 Mб0ІДПУ.doc
#
11.02.201664.51 Кб2ІНДЗ методичні рекомендації.doc
#
07.11.2018896.51 Кб11Інформаційні ресурси 2 ДД.doc
#
01.05.20251.55 Mб0Інформаційні ресурси_ навчальний посібник_ В. Я...doc
#
16.11.2018244.22 Кб14інформаційне забезпечення рекламної діяльності.doc
#
01.05.202575.95 Кб0Історія д. і п. України.docx
#
18.11.20194.26 Mб49ІТД лекції-58-75.doc
#
27.09.201927.09 Кб1аааа.docx
#
11.02.2016194.05 Кб26Агапов 1.doc