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

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

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

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

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

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

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

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

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

Клас(Class)-описсукупностейоб'єктівіззагальнимиатрибутами,операціями,відносинамиісемантикою.Класре­алізуєодинабодекількаінтерфейсів.Графічнокласзобра­жуєтьсяувиглядіпрямокутника,вякомузаписанійогоім'я,атрибутиіоперації(рис.7.5).

Інтерфейс(Interface)-сукупністьопераційяківизначаютьсервіс(набірпослуг),якийнадаєтьсякласомабокомпонентам.Такимчином,інтерфейсописуєвидимуззовніповедінкуелемента.Інтерфейсможепредставлятиповедінкуікласуабокомпонентаповністюабочастково;вінвизначаєтількиспецифікаціїоперацій(сигнатури),аленіколи-їхре­алізації.Графічноінтерфейсзображуєтьсяувиглядікола,підякимвказуєтьсяйогоім'я(рис.7.6).Інтерфейсрідкоіснуєсампособі.Звичайновінприєднуєтьсядокласуабокомпонента,щойогореалізує.

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

Прецедент(Usecase)-описпослідовностівиконуванихсистемоюдій,якаодержуєрезультат,значущийдляякогосьпевногоактора(Actor).Преце­дентзастосовуєтьсядляструктуризаціїповедінковихсутностеймоделі.Пре­цедентиреалізуютьсязадопомогоюкооперації.Графічнопрецедентзобра­жуєтьсяувиглядіобмеженогобезперервноюлінієюеліпса,щоміститьтількийогоім'я(рис.7.8).

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

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

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

системізустрічаютьсярізнівидивстановлюванихкомпонентів,такіякСОМ+або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).

Рис.7.21.Класиіоб'єкти

Нарис.7.21показаноодинкласCustomer(Клієнт)ітриоб'єкти:Jan:(явновизначенийякоб'єктподаногокласу),:Customer(анонімнийоб'єкткласуCustomer)іElyse(специфікаціяякоговідноситьйогодокласуCustomer,хочацеіневираженоявно).

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.

{попорядку}

Рис.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.Прецеденти

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

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

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

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

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

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

Т

"extend^

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

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

Аналізсистемнихвимогіпрецедентів,щовикористовуються,дозволяєспро­ститипроектуваннясистемишляхомвиділеннявнійокремихфункціональнихча­стин.Аце,усвоючергу,забезпечуєможливістьрозбитипроцеспроектуваннянадекількаетапів.Спочаткуприступимодопроектуваннятієїчастинидодатка,наякійформуютьсязапити.Знеювзаємодіятимутьспівробітникиіменеджеривідді­лів.Розробленанацьомуетапідіаграмапрецедентівпоказананарис.7.27.Прецедентдодатканазамовленнятоварів

Рис.7.27.ДіаграмапрецедентуЗапитнапридбання

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

•Передумова.Користувачреєструєтьсявсистемі,указуючисвоєім'яіпароль,ідістаєдоступдододатка.188

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

• Постумова.Користувачмаєнагодуоформитизапитнапридбанняабо
вийтизсистеми.

Відповіднодоцьогоописуможнавизначитиклас,щовідповідаєзави­тяганняінформаціїпротоваризбазиданихізавідбірназвтоварів,щовиво­дятьсянаекран.НазвемоцейкласProductCatalog(Каталогтоварів).

Проаналізувавшиіменаіменникиігрупиіменвописахпрецедентів,щовід­носятьсядооформленнязапитів,встановимоможливікласидодатка(табл.7.4).

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

Таблиця7.4.Класи,якіможутьвикористовуватисяприоформленнізапитів

напридбання

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

Класиможутьтакожвідноситисядоодногоітогожоб'єкта,указуватинайогорізністани.Так,запитнатоварізамовленняєоднеітежпоняття,алеоднаназвазастосовуєтьсядозатвердженняйогоменеджером,аінша-після.Необхідноусунутиітікласи,якіпредставляютьструктурніелементи

189

системи.Донихвідносятьсятаблицяісписок.Наприклад,списокскладаєть­сязбезлічізаписівізназвамитоварівуконкретномузамовленні.

Використовуючизгаданікритерії,списоккласівможнаскоротити,івінбудематитакийвигляд:Employee(Співробітниквідділу),Manager(Мене­джер),Order(Замовлення),Orderltem(Елементспискузамовлення),Pro­ductCatalog(Каталогтоварів),Product(Товар).

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

Наприклад,класактораPurchaser(UI)(Користувач)описуєграфічнийінтерфейс,якийкористувач(співробітниквідділу,менеджер)використовува­тимеприоформленнізапиту.Оскількитакікласинасправдінеєчастиноюсистеми,їхвнутрішнійвміствідокремленийвідсистеми,івонавзаємодієзними,якз«чорнимиящиками».

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

Puchaser(UI)

Employee

ProductCatalog

Product

DepartmentManager

Order

Orderltem

Рис.7.28.Ескіздіаграмикласів

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

АналізвимогкласуEmployeeпоказує,щояквластивостікласуповиннібутизаданізареєстрованеім'якористувача,пароль,кодабоназвавідділуіознака,вказуюча,чиєкористувачменеджером.

Крімтого,потрібноввестиідентифікаторспівробітника,атакожім'яіпрі­звище,заякимименеджерзможеконтролювативитратуканцтоварівцимспів­робітником.Властивостікласівпроектованогододаткаперерахованівтабл.7.5.

Нарис.7.29показанодіаграмукласівіїхвластивостей.Миопустиливла­стивостікласуDepartmentManager,оскількивінуспадковуєвластивостікласуEmployee.

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

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

Таблиця7.5.Властивостікласівдодатканазамовленняканцтоварів

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

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

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),оформленоговзапиті,зна­добитьсяметодSubmitOrderкласуOrder.Діаграмупослідовностейдляцьогосценаріюнаведенонарис.7.36.

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

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

SubTotai

SubmitOrder

*r-ⁱ

Orderl

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

Employee

EmployeelD:!integerLoginName:StringDepartament.StringFirstName:StringLastName:String

• ⇐ Назад
• -1
• 0
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 1314