Об'єктно-орієнтований підхід до проектування програмного забезпечення на прикладі роботи податкової інспекції

Введення

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

Проектування економічних інформаційних систем (ЕІС) - логічноскладна, трудомістка і тривала робота, що вимагає високої кваліфікаціїберуть участь у ній фахівців.

На початку 70-х рр.. в США був відзначений криза програмування (softwarecrisis). Це виражалося в тому, що великі проекти стали виконуватися звідставанням від графіка або з перевищенням кошторису витрат, розробленийпродукт не володів необхідними функціональними можливостями,продуктивність його була низька, якість отриманого програмногозабезпечення не влаштовувало споживачів.

Аналітичні дослідження та огляди, що виконуються протягом рядуостанніх років провідними закордонними аналітиками, показували не дужеобнадійливі результати. Так, наприклад, в 1995р. компанія StandishGroupпроаналізувала роботу 364 американських корпорацій та підсумки виконаннябільше 23 тис. проектів, пов'язаних з розробкою ПЗ, і зробили наступнівисновки:

Тільки 16% проектів завершилися в строк, 52,7% завершилися з запізненням,витрати перевищили запланований бюджет.

У числі причин невдач фігурують: нечітка і не повна формулюваннявимог до ПЗ, недостатнє залучення користувачів до роботи надпроектом, незадовільне планування і т.п.

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

Глава I Структура об'єктно-орієнтованого програмування.

1.1 СУТНІСТЬ Об'єктно-орієнтований підхід

Принципова відмінність між структурними та об'єктно-орієнтованимпідходом полягає в способі декомпозиції системи. Об'єктно -орієнтований підхід використовує об'єктну декомпозицію, при цьомустатична структура системи описується в термінах об'єктів та зв'язківміж ними, а поведінка системи описується в термінах обміну повідомленнямиміж об'єктами. Кожен об'єкт системи має свій власнийповедінкою, моделюючим поведінку об'єкта реального світу. Поняття "об'єкт"вперше було використано близько 30 років тому в технічних засобах приспробах відійти від традиційної архітектури фон Неймана і подолати бар'єрміж високим рівнем програмних абстракцій і низьким рівнемабстрагування на рівні комп'ютерів. З об'єктно-орієнтованоїархітектурою також тісно пов'язані об'єктно-орієнтовані операційнісистеми. Однак найбільш значний внесок у об'єктний підхід був внесенийоб'єктними і об'єктно-орієнтованими мовами програмування: Simula,
Smalltalk, C + +, Object Pascal. На об'єктний підхід вплинули такожрозвивалися досить незалежно методи моделювання баз даних, уособливості підхід "сутність-зв'язок".

Концептуальною основою об'єктно-орієнтованого підходу єоб'єктна модель. Основними се елементами є:

• абстрагування (abstraction);

• інкапсуляція (encapsulation);

• модульність (modularity);

• ієрархія (hierarchy).

Крім основних є ще три додаткові елементи, які не є ввідміну від основних суворо обов'язковими:

• типізація (typing )',

• паралелізм (concurrency )',

• стійкість (persistence).

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

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

Об'єктно-орієнтований підхід

Модульність - це властивість системи, пов'язане з можливістю їїдекомпозиції на ряд внутрішньо зв'язкових, але слабко пов'язаних між собоюмодулів. Інкапсуляція і модульність створюють бар'єри між абстракціями.

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

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

Паралелізм - властивість об'єктів знаходитися в активному або пасивномустані і розрізняти активні і пасивні об'єкти між собою.

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

Основні поняття об'єктно-орієнтованого підходу - об'єкт і клас.

Об'єкт визначається як реальність (tangible entity) --предмет або явище, що мають чітко визначається поведінка. Об'єкт маєстаном, поведінкою і індивідуальністю; структура і поведінка схожихоб'єктів визначають загальний для них клас. Терміни "екземпляр класу" і
"об'єкт''є еквівалентними. Стан об'єкта характеризуєтьсяпереліком усіх можливих (статичних) властивостей даного об'єкту і поточнимизначеннями (динамічними) кожного з цих властивостей. Поведінка характеризуєвплив об'єкта на інші об'єкти і навпаки щодо змінистану цих об'єктів і передачі повідомлень. Інакше кажучи, поведінкаоб'єкта повністю визначається його діями. Індивідуальність - цевластивості об'єкта, що відрізняють його від усіх інших об'єктів.

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

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

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

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

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

1.2 уніфікованої мови моделювання UML

Більшість існуючих методів об'єктно-орієнтованого аналізу іпроектування (ООАП) включають як мова моделювання, так і описпроцесу моделювання. Мова моделювання - це нотація (в основномуграфічна), яка використовується методом для опису проектів. Нотаціяявляє собою сукупність графічних об'єктів, які використовуютьсяв моделях; вона є синтаксисом мови моделювання. Наприклад, нотаціядіаграми класів визначає, яким чином подаються такі елементи іпоняття, як клас, асоціація і множинність. Процес - це опискроків, які необхідно виконати при розробці проекту.

Уніфікований мова моделювання UML (Unified Modeling Language) --це наступник того покоління методів ООАП, які з'явилися наприкінці 80-х іпочатку 90-х рр.. Створення UML фактично почалося в кінці 1994 р., коли
Граді Буч і Джеймс Рамбо почали роботу з об'єднання методів Booch і ОМТ
(Object Modeling Technique) під егідою компанії Rational Software. До кінця
1995 р. вони створили першу специфікацію об'єднаного методу, названогоними Unified Method, версія 0.8. Тоді ж, у 1995 р., до них приєднавсятворець методу OOSE (Object-oriented Software Engineering) Івар Якобсон.
Таким чином, UML є прямим об'єднанням і уніфікацією методів Буча,
Рамбо і Якобсона, однак доповнює їх новими можливостями. Головними врозробці UML були наступні цілі:

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

• передбачити механізми розширюваності та спеціалізації для розширеннябазових концепцій;

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

• забезпечити формальну основу для розуміння цієї мови моделювання
(мова повинна бути одночасно точним і доступним для розуміння, беззайвого формалізму);

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

1.3 ВАРІАНТИ ВИКОРИСТАННЯ

Протягом досить тривалого періоду часу в процесі якоб'єктно-орієнтованого, так і традиційного структурного проектуваннярозробники використовували типові сценарії, які допомагають краще зрозумітивимоги до системи. Ці сценарії трактувалися дуже неформально - вонимайже завжди використовувалися і вкрай рідко документувалися. І вар Якобсонвперше ввів поняття "варіант використання" (use case) і надав йому такузначимість, що він перетворився в основний елемент розробки і плануванняпроекту.

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

Коли Якобсон в 1994 р. запропонував варіанти використання в якостіосновних елементів процесу розробки ПЗ, він також запропонував застосовувати дляїх наочного подання діаграми варіантів використання. На рис.1показані деякі варіанти використання для системи організації торгівлі;людські фігурки тут позначають дійових осіб, овали - варіантивикористання, а лінії і стрілки - різні зв'язку між діючимиособами і варіантами використання.

Рис.1 Діаграма варіантів використання

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

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

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

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

На додаток до зв'язків між діючими особами і варіантамивикористання існують два інших типи зв'язків (див. рис.1):
"використання" (uses) і "розширення" (extends) між варіантамивикористання. Зв'язок типу "розширення" застосовується тоді, коли однаваріант використання подібний до іншого, але несе кілька велике навантаження

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

Вибір застосовуваної зв'язку визначається наступними правилами:

• зв'язок "розширення" слід застосовувати при описі змін донормальному поведінці системи;

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

Різні розробники підходять до опису варіантів використання зрізним ступенем деталізації. Наприклад, Івар Якобсон стверджує, що дляпроекту з трудомісткістю в 10 людино-років кількість варіантіввикористання може становити близько 20 (не рахуючи зв'язків "використання" і
"розширення"). Слід віддавати перевагу невеликі та деталізовані варіантивикористання, оскільки вони полегшують складання і реалізаціюузгодженого плану проекту.

Глава II ДІАГРАМИ

2.1 Діаграми класів

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

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

• підтипи (приватний клієнт є різновидом клієнта).

Рис. 2 Діаграма класів

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

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

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

• аспект специфікації - модель спускається на рівень ПЗ, алерозглядаються тільки інтерфейси, а не програмна реалізація класів (підінтерфейсом тут розуміється набір операцій класу, видимих ззовні);

• аспект реалізації - модель дійсно визначає реалізаціюкласів ПЗ. Цей аспект найбільш важливий для програмістів.

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

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

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

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

Асоціації представляють собою зв'язки між екземплярами класів
(особа працює в компанії, компанія має ряд офісів).

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

Кожна асоціація володіє двома ролями; кожна роль являє собоюнапрямок асоціації. Таким чином, асоціація між Клієнтом і Замовленняммістить дві ролі: один від Клієнта до Замовлення, інша - від замовлення до Клієнта.

Роль може бути явно пойменована за допомогою позначки. Наприклад, рольасоціації в напрямку від Замовлення до лінії замовлень називається «позиціязамовлення ». Якщо ця позначка відсутня, ролі присвоюється ім'я клас - цілі
- Таким чином, роль асоціації від Замовлення до Клієнту може бути названа
Клієнт (терміни «початок» (source) і «мета» (target) вживаються дляпозначення класів, які є відповідно початковим і кінцевим дляасоціації).

2.2 ДІАГРАМИ Взаємодія з

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

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

Проілюструємо цей підхід на прикладі досить простого варіантувикористання, що описує поведінку наступне:

• Вікно Введення Замовлення посилає Замовленню повідомлення "приготуватися".

• Замовлення посилає дане повідомлення кожної Строке замовлення в даному Замовленні.

• Кожна Рядок замовлення перевіряє стан певного Запасу товару:

Якщо дана перевірка задовольняється (результат - true), то Рядокзамовлення видаляє відповідну кількість товару з Запасу.

В іншому випадку кількість Запасу знижується до рівня повторногозамовлення, і Запас запитує нову поставку товару.

Існують два види діаграм взаємодії: діаграмипослідовності (sequence diagrams) і кооперативні діаграми
(collaboration diagrams).

На діаграмі послідовності об'єкт зображується у виглядіпрямокутника на вершині пунктирною вертикальної лінії (рис.3).

Ця вертикальна лінія називається лінією життя (lifeline) об'єкта. Вонаявляє собою фрагмент життєвого циклу об'єкта в процесівзаємодії. Таку форму подання вперше ввів Івар Якобсон.

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

Рис. 3 Діаграма послідовності

(self-delegation) - повідомлення, що об'єкт посилає самому собі, прицьому стрілка повідомлення вказує на ту ж саму лінію життя.

З усією можливою керуючої інформації два її виду мають істотнезначення. По-перше, це умова, що показує, коли надсилається повідомлення
(наприклад, [нуженПовторнийЗаказ = "true"]). Повідомлення надсилається тільки привиконання цієї умови. Інший корисний керуючий маркер - це маркерітерації, що показує, що повідомлення посилається багато разів для безлічіоб'єктів-адресатів (наприклад, * приготуватися).

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

Діаграма (див. рис. 3) містить повернення, що означає не нове повідомлення,а повернення з повідомлення. На діаграмі повернення відрізняється від звичайнихповідомлень тим, що його стрілка не суцільне, а має вигляд пари ліній.

Діаграми послідовності можна також використовувати для представленняпаралельних процесів.

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

рис.4 Паралельні процеси та активізації

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

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

• створювати нову гілку процесу (в цьому випадку воно пов'язане із самоюверхньою частиною активізації);

• створювати новий об'єкт;

• встановлювати зв'язок з уже виконується гілкою процесу.

Видалення об'єкта показано за допомогою великого знаку "X" . Об'єкти можутьвиконати самознищення або можуть бути знищені за допомогою ще одногоповідомлення.

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

Глава III ПРИКЛАД ВИКОРИСТАННЯ Об'єктно-орієнтований підхід

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

На початковій стадії (або стадії формування вимог) будуєтьсяпочаткова діаграма варіантів використання (мал. 5).

Рис.5 Початкова діаграма варіантів використання

При побудові діаграми варіантів використання в першу Чергаскладається список всіх основних дійових осіб (фізичних осіб абозовнішніх систем, які будуть взаємодіяти з створюваної системою). Їхможна ідентифікувати, задаючи такі питання:

• Хто використовує систему безпосередньо?

• Хто відповідає за експлуатацію системи?

• Яке зовнішнє обладнання використовується системою?

• Які інші системи взаємодіють з даною системою?

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

На стадії проектування уточнюється діаграма варіантів використання ібудується архітектура системи, основою якої є діаграми класів. Уданому прикладі обмежимося побудовою діаграми класів і діаграмивзаємодії. Діаграми взаємодії будуються для уточнення діаграмиваріантів використання і переходу до діаграм класів. Так, діаграмапослідовності (мал. 6) ілюструє один з можливих сценаріїврозвитку подій в рамках варіанти використання "Зареєструватиплатника податків ". Передбачається, що платник податків ставиться на обліквперше і всі його документи в повному порядку.

Структура програмної системи описується за допомогою декількох діаграмкласів, головна з яких являє собою діаграму пакетів (подібнудіаграм, представлених в додатку рис. 8 і 9), а інші діаграмирозкривають зміст кожного з пакетів. При побудові діаграми класівпредметної області виділення цих класів (класів-сутностей) може бутианалогічно виділенню сутностей в процесі моделювання даних. Данікласи повинні мати концептуальний характер і відповідати на запитання "що?", ане "як?". Початковий список може бути складений таким чином:

• в описі вихідних даних виділяються кандидати в класи -іменники, які потенційно можуть відповідати класах (прицьому слід пам'ятати, що іменники можуть також ставитися дооб'єктам, асоціаціям або атрибутів класів);

Рис. 6 Діаграма послідовності для варіанту використання

"Зареєструвати платника податків"

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

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

Рис. 7 Діаграма класів предметної області

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

• кожна операція повинна виконувати одну просту функцію;

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

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

Отримана в результаті діаграма класів предметної області показанана рис. 7

Висновок.

Я хоте лоби відзначити, що на прикладі податкової інспекції ми на власні очіпереконалися в доцільності використання об'єктно - орієнтованогопідхід. Але це не межа і перспектива розвитку об'єктно - орієнтованогометоду проектування велика. Його відрізняє наступне: «об'єктно -орієнтовані системи більш відкриті і легше піддаються внесенню змін,оскільки їх конструкція базується на стійких формах. Це даєможливість системі розвиватися поступово і не призводить до повної їїпереробки навіть у випадку істотних змін вихідних вимог. »Донедоліків відносяться: деяке зниження продуктивностіфункціонування ПЗ і високі початкові витрати, ці недоліки не настількиістотні у цілому і на чаші ваг перевага буде у бік плюсів.

Список використаної літератури.
1. А. М. Вендров// Проектування програмного забезпечення економічних інформаційних систем// Москва 2000
2. О. Єфімова// Курс комп'ютерних технологій// Москва1998г.
3. Всесвітня мережа Інтернет

Додаток.

Рис. 8 Діаграма пакетів

Рис 9. Удосконалена діаграма пакетів

-----------------------< br>Вікно
Введення
Замовлення

замовлення

Рядок замовлення

запас

Приготуватися ()

Об'єкт

Повідомлення

Приготуватися ()

інтерація < p> Перевірка ()

[Перевірка = "true"] видалити ()

Потрібен повторне замовлення ()

умова

самоделігірованіе

[Потрібен повторне замовлення = "true"]

новий

Повторне замовлення

Повернення

Постачання

[перевірка = "true"] новий

Створення