1.1 Поняття терміна – «CASE-засоби»

Спочатку під терміном CASE-технологія (Computer - Aided Software Engineering) розумілося буквально - "автоматизована розробка ПЗ ІС за допомогою комп'ютерних технологій".

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

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

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

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

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

1.2 Типова структура CASE-засобів

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

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

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

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

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

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

2. Широке використання базових програмних засобів, що набули масового поширення в інших додатках (БД та СУБД, компілятори з різних мов програмування, налагоджувачі, документатори, видавничі системи, оболонки експертних систем та бази знань, мови четвертого покоління та ін.).

3. Автоматизована або автоматична кодогенерація, різних платформта різного виду коду: перетворення для отримання документації; формування структури БД, введення/модифікації даних; отримання машинних кодів, що виконуються, зі специфікацій ПЗ; складання модулів зі словників та моделей даних та повторно використовуваних програм.

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

5. Доступність для різних категорій користувачів.

6. Рентабельність.

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

До складу практично всіх сучасних CASE-засобів входять такі елементи:

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

засоби розробки додатків з використанням мов 4GL і генераторів кодів;

засоби тестування;

засоби документування;

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

засоби реінжинірингу;

засоби конфігураційного управління;

засоби управління проектом.

1.3 Еволюція розвитку CASE-технологій

З самого початку CASE-технології розвивалися з метою подолання обмежень «ручного» застосування методології структурного аналізу та проектування 60-70-х років за рахунок її автоматизації та інтеграції у підтримуючі засоби. Таким чином, CASE-технології не можуть вважатися самостійними методологіями моделювання, вони роблять більш ефективними їх застосування, з точки зору часу розробки.

Традиційно виділяють шість періодів, що якісно відрізняються застосовуваною технікою та методами розробки ПЗ, які характеризуються використанням як інструментальні засоби:

1. асемблерів, дампів пам'яті, аналізаторів;

2. компіляторів, інтерпретаторів, трасувальників;

3. Символьних налагоджувачів, пакетів програм;

4. Систем аналізу та управління вихідними текстами;

5. CASE-засобів аналізу вимог, проектування специфікацій та структури, редагування інтерфейсів (перша генерація CASE-I);

6. CASE-засобів генерації вихідних текстівта реалізації інтегрованого оточення підтримки повного життєвого циклу розробки ПЗ (друга генерація CASE-II)

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

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

1.4 Методології проектування, що використовуються в CASE-засобах

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

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

Основними стандартами методологій, реалізованих у CASE-засобах, є:

SADT (Structured Analysis and Design Technique) – методологія структурного аналізу та проектування. Заснована на поняттях функціонального моделювання. Відображає такі системні характеристики, як управління, зворотний зв'язок та виконавець;

IDEF0 (Integrated Definition Function Modeling) – методологія функціонального моделювання. Використовується для створення функціональної моделі, що відображатиме структуру та функції системи, а також потоки інформації та матеріальних об'єктів, що перетворюються цими функціями. Є підмножиною методології SADT;

DFD (DataFlow Diagram) – методологія моделювання потоків даних.

Рисунок 1.1 – Порівняння традиційної розробки та розробки з використанням CASE-технологій

Наступні стандарти методологій застосовуються для опису обміну даними між робочими процесами:

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

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

IDEF3-методологія моделювання потоків робіт. Є більш детальною стосовно IDEF0 та DFD. Дозволяє розглянути конкретний процес з урахуванням послідовності операцій, що виконуються. За допомогою IDEF3 описуються сценарій та послідовність операцій для кожного процесу;

IDEF1X (IDEF1 Extended) – методологія опису даних. Застосовується для побудови бази даних. Відноситься до типу методологій «Сутність-зв'язок» (ER - Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до системи, що розглядається;

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

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

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

UML - (Unified Modeling Language) уніфікована мова моделювання, заснована на об'єктно-орієнтованому підході. UML дозволяють описати статичну структуру системи та її динамічну поведінку у відповідних нотаціях.

У CASE-засобах широко використовуються методології структурного та об'єктно-орієнтованого проектування. Структурне проектування ґрунтується на алгоритмічній декомпозиції, а об'єктно-орієнтоване проектування – на об'єктно-орієнтованій декомпозиції. Алгоритмічна декомпозиція дозволяє визначити порядок подій, що відбуваються. Об'єктно-орієнтована декомпозиція дозволяє визначити ієрархію класів об'єктів, їх методи та властивості. CASE-засоби, що підтримують об'єктно-орієнтоване проектування, використовують методологію RUP (Rational Unified Process) та нотації мови UML.

1.5 Методологія CASE-засобів об'єктно-орієнтованого проектування

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

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

Буч зазначає також низку наступних переваг об'єктно-орієнтованого підходу.

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

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

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

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

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

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

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

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

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

Іншою формою прояву взаємозв'язку вважатимуться інтеграцію об'єктної та реляційної технологій. Реляційні СУБД є на сьогоднішній день основним засобом реалізації великомасштабних баз даних та сховищ даних. Причини цього очевидні: реляційна технологія використовується досить довго, освоєна величезною кількістю користувачів і розробників, стала промисловим стандартом, в неї вкладено значні кошти та створено безліч корпоративних БД у різних галузях, реляційна модель проста і має строгу математичну основу; існує велика різноманітність промислових засобів проектування, реалізації та експлуатації реляційних БД. Внаслідок цього реляційні БД переважно використовуються для зберігання та пошуку об'єктів у так званих об'єктно-реляційних системах. Об'єктно-орієнтоване проектування має точки зіткнення з реляційним проектуванням. Наприклад, як було зазначено вище, класи в об'єктній моделі можуть певним чином відповідати сутностям (як вправу можна запропонувати детально проаналізувати всі подібності та відмінності діаграм «сутність-зв'язок» та діаграм класів). Як правило, така відповідність має місце лише на ранній стадії розробки системи – стадії формування вимог. Надалі, зрозуміло, цілі об'єктно-орієнтованого проектування (адекватне моделювання предметної області у термінах взаємодії об'єктів) та розробки реляційної БД (нормалізація даних) розходяться. Таким чином, єдино можливим засобом подолання даної прогалини є визначення відповідності між об'єктно-орієнтованою та реляційною технологіями, яка в основному зводиться до відображення діаграм класів та діаграм «сутність – зв'язок» реляційної моделі. Одним із прикладів практичної реалізації взаємозв'язку між структурним та об'єктно-орієнтованим підходом є програмний інтерфейс(Міст) між структурним CASE-засобом Silverrun та об'єктно-орієнтованим CASE-засобом Rational Rose, розроблений російською компанією "Аргуссофт". Це ПЗ створює діаграми класів Rational Rose на основі RDM-моделі (Relational Data Model - реляційна модель даних) Silverrun . Аналогічні інтерфейси існують також між CASE-засобами ERwin (з одного боку), Rational Rose та Paradigm Plus (з іншого боку).

1.6 Методологія CASE-засобів структурного проектування

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

Усі найпоширеніші методології структурного підходу базуються на низці загальних принципів. Як основні принципи використовуються:

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

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

принцип абстрагування - полягає у виділенні суттєвих аспектів системи та відволікання від несуттєвих;

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

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

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

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

Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними є такі :

SADT (Structured Analysis and Design Technique) моделі та відповідні функціональні діаграми;

DFD (Data Flow Diagrams) діаграми потоків даних;

ERD (Entity-Relationship Diagrams) діаграми «сутність-зв'язок».

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

2.2 Розробка концептуальної моделіінформаційної системи

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

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

Щоб побудувати необхідну нам модель, ми привели всі наявні дані до третьої нормальної форми, внаслідок чого отримали такі сутності:

· Види страв.

· Персонал.

· Посади.

· Постійні клієнти.

· Замовлення.

Модель будуємо логічно (див. рис. 2). З малюнка 2 видно, що моделі проставлені зв'язку. Розглянемо їх докладніше:

Таблиця «Види страв» та таблиця «Страви» - встановлений зв'язок «один-багатьом» за допомогою первинного ключа"Код виду";

Таблиця «Посади» та таблиця «Персонал» - встановлений зв'язок «один-багатьом» за допомогою первинного ключа «Код посади»;

Таблиця «Страви» та таблиця «Замовлення» - встановлений зв'язок «один-багатьом» за допомогою первинного ключа «Код страви»;

Таблиця «Персонал» та таблиця «Замовлення» - встановлений зв'язок «один-багатьом» за допомогою первинного ключа «Код працівника»;

Таблиця «Постійні клієнти» та таблиця «Замовлення» - встановлений зв'язок «один-багатьом» за допомогою первинного ключа «Код клієнта».

Мал. 2. Концептуальна модель даних

2.3 Розробка логічної моделі інформаційної системи

Бази даних та програмні засоби їх створення та ведення (СУБД) мають багаторівневу архітектуру, уявлення про яку можна отримати з малюнку 1.

Схема 1 - Багаторівневе представлення даних БД під

управлінням СУБД

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

Концептуальний рівень відповідає логічному аспекту представлення даних предметної галузі в інтегрованому вигляді. Концептуальна модель складається з багатьох екземплярів різних типів даних, структурованих відповідно до вимог СУБД до логічної структури бази даних.

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

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

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

Схема 2 – Етапи процесу проектування бази даних

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

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

При зв'язку один до багатьох (1:М) одному екземпляру інформації А відповідає 0, 1 або більше екземплярів об'єкта, але кожен екземпляр об'єкта В пов'язаний не більше ніж з одним екземпляром об'єкта А.

Прикладом зв'язку 1:М є зв'язок між інформаційними об'єктами Прізвище – Оклад:

Прізвище Оклад

У базі даних інформація зберігається як двомірних таблиць. Можна також імпортувати та зв'язувати таблиці з інших СУБД або систем керування електронними таблицями. Одночасно можуть бути відкриті 1024 таблиці.

При визначенні необхідних таблиць бази даних потрібно забезпечити перші три нормальні форми, тобто. провести нормалізацію.

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

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

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

Е.Коддом виділено три нормальні форми відносин і запропоновано механізм, що дозволяє будь-яке відношення перетворити до третьої (найдосконалішої) нормальної форми.

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

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

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

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

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

Малюнок 1 - Графічне зображення функціональної залежності реквізитів

У разі складеного ключа вводиться поняття функціонально повної залежності.

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

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

Третя нормальна форма. Поняття третьої нормальної форми ґрунтується на понятті не транзитивної залежності.

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

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

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

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

Метою роботи є створення бази даних, що забезпечує:

швидке введення нових даних;

зберігання та пошук уже введених даних;

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

Даними є:

Прізвище ім'я по батькові;

Дата народження;

Займана посада;

Посадовий оклад;

Кількість фактичних днів відпрацьованих протягом місяця.

Розглянувши певні завдання можна спроектувати основні таблиці бази даних.

Для цього користуватимемося засобами Database Desktop

У цьому середовищі створимо всі необхідні таблиці для бази даних, що розробляється. Атрибутами у цій таблиці буде:

Прізвище, Ім'я, По-батькові, Дата прийняття, Адреса, Телефон, Зміни, Не виходи на роботу, Ставка, зарплата.

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

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

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

відсутність прямих аналогів, що обмежує можливість використання будь-яких типових проектних рішень та прикладних систем;

необхідність інтеграції існуючих та новостворених додатків;

функціонування у неоднорідному середовищі на кількох апаратних платформах;

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

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

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

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

неадекватна специфікація вимог;

нездатність виявляти помилки в проектних рішеннях;

низька якість документації, що знижує експлуатаційні якості;

затяжний цикл та незадовільні результати тестування.

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

Перелічені фактори сприяли появі програмно-технологічних засобів спеціального класу – CASE-засобів, що реалізують CASE-технологію створення та супроводу ІВ. Термін CASE (Computer Aided Software Engineering) використовується в даний час у широкому сенсі. Початкове значення терміна CASE, обмежене питаннями автоматизації розробки тільки програмного забезпечення (ПЗ), в даний час набуло нового сенсу, що охоплює процес розробки складних ІС в цілому. Тепер під терміном CASE-засоби розуміються програмні засоби, що підтримують процеси створення та супроводу ІВ, включаючи аналіз та формулювання вимог, проектування прикладного ПЗ (додатків) та баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління та управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ та технічними засобами утворюють повне середовище розробки ІВ.

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

підготовка аналітиків та програмістів, сприйнятливих до концепцій модульного та структурного програмування;

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

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

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

CASE-кошти. Загальна характеристика та класифікація

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

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

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

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

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

інтеграція окремих компонентів CASE-засобів, що забезпечує керованість процесом розробки ІВ;

використання спеціальним чином організованого сховища проектних метаданих (репозиторія).

Інтегрований CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ) містить наступні компоненти;

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

графічні засоби аналізу та проектування, що забезпечують створення та редагування ієрархічно пов'язаних діаграм (DFD, ERD та ін), що утворюють моделі ІВ;

засоби розробки додатків, включаючи мови 4GL та генератори кодів;

засоби конфігураційного управління;

засоби документування;

засоби тестування;

засоби управління проектом;

засоби реінжинірингу.

Всі сучасні CASE-кошти можуть бути класифіковані в основному за типами та категоріями. Класифікація за типами відбиває функціональну орієнтацію CASE-засобів ті чи інші процеси ЖЦ. Класифікація за категоріями визначає ступінь інтегрованості за виконуваними функціями та включає окремі локальні засоби, Вирішують невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІС і пов'язані загальним репозиторієм. Крім цього, CASE-кошти можна класифікувати за такими ознаками:

застосовуваним методологіям та моделям систем та БД;

ступеня інтегрованості із СУБД;

доступним платформам.

Класифікація за типами переважно збігається з компонентним складом CASE-засобів і включає такі основні типи:

засоби аналізу (Upper CASE), призначені для побудови та аналізу моделей предметної галузі (Design/IDEF (Meta Software), BPwin (Logic Works));

засоби аналізу та проектування (Middle CASE), що підтримують найбільш поширені методології проектування та використовуються для створення проектних специфікацій (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE). Аналітик (Макропроджект)). Виходом таких засобів є специфікації компонентів та інтерфейсів системи, архітектури системи, алгоритмів та структур даних;

засоби проектування баз даних, що забезпечують моделювання даних та генерацію схем баз даних (як правило, на мові SQL) для найпоширеніших СУБД. Доним відносяться ERwin (Logic Works), S-Designor (SDP)та DataBase Designer (ORACLE). Кошти проектування баз даних є також у складі CASE-засобів Vantage Team Builder, Designer/2000, Silverrun та PRO-IV;

засоби розробки додатків. До них відносяться кошти 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) та ін.) та генератори кодів, що входять до складу Vantage Team Builder, PRO-IV та частково - у Silverrun;

засоби реінжинірингу, що забезпечують аналіз програмних кодів та схем баз даних та формування на їх основі різних моделейта проектних специфікацій. Засоби аналізу схем БД та формування ERD входять до складу Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin та S-Designor. В області аналізу програмних кодів найбільшого поширення набувають об'єктно-орієнтовані CASE-засоби, що забезпечують реінжиніринг програм мовою С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Допоміжні типи включають:

засоби планування та управління проектом (SE Companion, Microsoft Projectта ін.);

засоби конфігураційного управління (PVCS (Intersolv));

засоби тестування (Quality Works (Segue Software));

засоби документування (SoDA (Rational Software)).

На сьогоднішній день Російський ринок програмного забезпечення має такі найбільш розвинені CASE-засоби:

Vantage Team Builder (Westmount I-CASE);

Designer/2000;

Silverrun;

ERwin+BPwin;

S-Designor;

CASE.Аналітик.

Крім того, на ринку постійно з'являються нові для вітчизняних користувачів системи (наприклад, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так і нові версії та модифікації перерахованих систем.

1. Основи методології проектування ІВ

1.1. Життєвий цикл ІС

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Міжнародна організація зі стандартизації, IEC – International Electrotechnical Commission – Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії та завдання, які мають бути виконані під час створення ПЗ.

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);

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

організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та покращення самого ЖЦ, навчання).

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

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

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

Управління конфігурацією одна із допоміжних процесів, підтримують основні процеси життєвого циклу ПО, передусім процеси розробки та супроводу ПО. p align="justify"> При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди або версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати та контролювати внесення змін до ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені у проекті стандарту ISO 12207-2.

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

2. Структурний підхід до проектування ІВ CASE засобами

2.1. Сутність структурного підходу

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

Усі найпоширеніші методології структурного підходу базуються на ряді загальних принципів. Як два базових принципіввикористовуються такі:

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

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

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

принцип абстрагування - полягає у виділенні суттєвих аспектів системи та відволікання від несуттєвих;

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

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

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

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

SADT (Structured Analysis and Design Technique) моделі та відповідні функціональні діаграми (підрозділ 2.2);

DFD (Data Flow Diagrams) діаграми потоків даних (підрозділ 2.3);

ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок" (підрозділ 2.4).

На стадії проектування ІС моделі розширюються, уточнюються та доповнюються діаграмами, що відображають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм та діаграми екранних форм.

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

2.2. Методологія функціонального моделювання SADT ( IDEF 0)

Методологія SADT розроблена Дугласом Россом. На її основі розроблено, зокрема, відому методологію IDEF0 (Icam DEFinition), яка є основною частиною програми ICAM (Інтеграція комп'ютерних та промислових технологій), що проводиться за ініціативою ВПС США.

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

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

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

обмеження кількості блоків кожному рівні декомпозиції (правило 3-6 блоків);

зв'язність діаграм (номери блоків);

унікальність міток та найменувань (відсутність повторюваних імен);

синтаксичні правила для графіки (блоків та дуг);

поділ входів та управлінь (правило визначення ролі даних).

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

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

2.2.1. Склад функціональної моделі

Результатом застосування методології SADT є модель, що складається з діаграм, фрагментів текстів та глосарію, які мають посилання один на одного. Діаграми - головні компоненти моделі, всі функції ІВ та інтерфейси на них представлені як блоки та дуги. Місце з'єднання дуги із блоком визначає тип інтерфейсу. Керуюча інформація входить у блок зверху, у той час як інформація, що піддається обробці, показана з лівого боку блоку, а результати виходу показані з правого боку. Механізм (людина або автоматизована система), який здійснює операцію, представляється дугою, що входить до блоку знизу (рисунок 2.1).

Однією з найважливіших особливостей методології SADT є поступове запровадження дедалі більших рівнів деталізації у міру створення діаграм, що відображають модель.

Мал. 2.1. Функціональний блок та інтерфейсні дуги

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

2.2.2. Ієрархія діаграм

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

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

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

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

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

Мал. 2.2. Структура SADT моделі. Декомпозиція діаграм

На рисунках 2.3 - 2.5 представлені різні варіанти виконання функцій та з'єднання дуг із блоками.

Мал. 2.3. Одночасне виконання

Мал. 2.4. Відповідність має бути повною і несуперечливою

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

На SADT-діаграмах не зазначено ні послідовність, ні час. Зворотні зв'язки, ітерації, процеси, що продовжуються, і перекриваються (за часом) функції можуть бути зображені за допомогою дуг. Зворотні зв'язки можуть бути як коментарів, зауважень, виправлень тощо. (Рисунок 2.5).

Мал. 2.5. Приклад зворотного зв'язку

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

Мал. 2.6. Приклад механізму

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

Щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є верхньою діаграмою моделі. На малюнку 2.7 показано типове дерево діаграм.

Мал. 2.7. Ієрархія діаграм

2.2.3. Типи зв'язків між функціями

Одним із важливих моментів під час проектування ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють за Крайній мірісім типів зв'язування:

Тип зв'язку	Відносна значимість
Випадкова
Логічна
Тимчасова
Процедурна
Комунікаційна
Послідовна
Функціональна

Нижче кожен тип зв'язку коротко визначено та проілюстровано за допомогою типового прикладу з SADT.

(0) Тип випадкової зв'язності: найменш бажаний.

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

Мал. 2.8. Випадковий зв'язок

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

(2) Тип тимчасової зв'язності.Пов'язані часові елементи виникають внаслідок того, що вони представляють функції, пов'язані в часі, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.

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

Мал. 2.9. Процедурна зв'язність

(4) Тип комунікаційної зв'язності.Діаграми демонструють комунікаційні зв'язки, коли блоки групуються внаслідок того, що вони використовують ті самі вхідні дані та/або виробляють ті самі вихідні дані (рисунок 2.10).

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

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

Мал. 2.10. Комунікаційна зв'язність

Мал. 2.11. Послідовна зв'язність

Рис.13. Функціональна діаграма створення та модифікації проекту виробу (другий рівень)

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

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

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

Якщо використовувати термін «бізнес-процес», можна сказати, що метод IDEF 0 дозволяє ідентифікуватибізнес-процеси, розглянути функціонування підприємства «як є» та на основі їх аналізу дати пропозиції «як має бути», тобто по-новому поглянути на роботу підприємства, уточнити обов'язки працівників, оцінити ефективність використання ресурсів, побачити недоліки, майстерно приховані у звичайній організаційну структуру. Отже, виявлення, аналіз та внесення змін до бізнес-процесів може бути використане для підвищення ефективності роботи підприємства.

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

Збір інформації про підприємство;

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

Для аналізу розподілу витратзастосовується метод ABC, що базується на IDEF0. Метод ABC ґрунтується на тому, що виконання кожної функції в процесі функціонування підприємства має певну вартість, тобто робить свій внесок у появу витрат. АВС аналогічно поняттю ФСА – функціонально-вартісного аналізу. За допомогою методу АВС розраховуються витрати на виконання всього процесу чи окремої функції, вартість продукції на виході процесу, виявляються джерела основних витрат. Витрати виконання декомпозируемой функції визначаються як сума витрат за виконання всіх складових елементіву цій функції.

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

Для побудови функціональної моделі пропонується вибрати CASE-пакет Design/IDEF , оскільки крім можливостей створення функціональної моделі цей пакет містить вбудований механізм АВС підрахунку витрат за виконання функцій, що дозволяє аналізувати бізнес-процеси та його складові. Кожен вид ресурсу, споживаний (оброблюваний) функцією, і навіть механізми, виконують функцію, додають вартість цієї функції, у своїй враховуються елементи витрат, ігноровані при звичайному поданні підприємства як сукупності організаційних структур. Отже, кожній функції h моделі IDEF0 можна поставити у відповідність значення витрат виконання цієї функції Ex(h).

Рис.14. Загальна схема методики аналізу та реінжинірингу бізнес-процесів підприємства

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

Приклад побудови функціональної моделі процесу створення САПР наведено малюнки 15…18.

Рис.15. Функціональна модель процесу створення САПР (початок).
IDEF 0-діаграма першого рівня.

Рис.16. IDEF 0-діаграма обстеження підприємства.

Рис.17. IDEF 0-діаграма проектування САПР.

Рис.18. IDEF 0-діаграма реалізації проекту САПР.

2.3. Моделювання потоків даних (процесів-моделі DFD, стандарт IDEF 1)

У основі даної методології (методології Gane/Sarson) лежить побудова моделі аналізованої ІВ - проектованої чи реально існуючої. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС із зовнішніми входами та виходами. Вони деталізуються з допомогою діаграм нижнього рівня. Така декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм, доки не буде досягнуто такого рівня декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.

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

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

зовнішні сутності;

системи/підсистеми;

процеси;

накопичувачі даних;

потоки даних.

2.3.1. Зовнішні сутності

Зовнішня сутність є матеріальним предметом або фізична особа, що є джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад. Визначення деякого об'єкта чи системи як зовнішньої сутності свідчить про те, що вона перебуває поза межами аналізованої ИС. У процесі аналізу деякі зовнішні сутності можуть бути перенесені всередину діаграми аналізованої ІВ, якщо це необхідно, або, навпаки, частина процесів ІС може бути винесена за межі діаграми та представлена ​​як зовнішня сутність.

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

Мал. 2.13. Зовнішня сутність

2.3.2. Системи та підсистеми

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

Підсистема (або система) на контекстній діаграмі зображується так (рисунок 2.14).

Мал. 2.14. Підсистема

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

2.3.3. Процеси

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

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

Мал. 2.15. Процес

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

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

"Видати інформацію про поточні витрати";

"Перевірити кредитоспроможність клієнта".

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

Інформація у полі фізичної реалізації показує, який підрозділ організації, програма чи апаратний пристрій виконує цей процес.

2.3.4. Накопичувачі даних

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

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

Мал. 2.16. Накопичувач даних

Накопичувач даних ідентифікується буквою "D" та довільним числом. Ім'я накопичувача вибирається з найбільшої інформативності для проектувальника.

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

2.3.5. Потоки даних

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

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

Мал. 2.17. Потік даних

2.3.6. Побудова ієрархії діаграм потоків даних

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

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

наявність великої кількості зовнішніх сутностей (десять і більше);

розподілена природа системи;

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

Для складних ІС будується ієрархія контекстних діаграм. У цьому контекстна діаграма верхнього рівня містить єдиний головний процес, а набір підсистем, з'єднаних потоками даних. Контекстні діаграми наступного рівня деталізують контекст та структуру підсистем.

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

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

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

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

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

правило нумерації - означає, що з деталізації процесів має підтримуватися їх ієрархічна нумерація. Наприклад, процеси, що деталізують процес із номером 12, одержують номери 12.1, 12.2, 12.3 і т.д.

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

Мініспеціфікація є кінцевою вершиною ієрархії ДПД. Рішення про завершення деталізації процесу та використання мініспецифікації приймається аналітиком виходячи з наступних критеріїв:

наявності у процесу щодо невеликої кількості вхідних та вихідних потоків даних (2-3 потоки);

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

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

можливості опису логіки процесу за допомогою міні-специфікації невеликого обсягу (не більше 20-30 рядків).

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

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

2.4. Моделювання даних

IDEF1X - метод моделювання даних та проектування реляційних баз даних. Він відноситься до типу методологій «сутність-взаємозв'язок» ( ER - Entity - Relationship ), проте сутності тут розуміються не як реальні об'єкти, а як їх типи, що мають загальними властивостями. Зв'язки між сутностями складніші. Це дозволяє зберігати інформацію у формі абстрактної схеми (семантичної моделі), яка пов'язує символи, що зберігаються в комп'ютері, з реальним світом і є вірним його відображенням. Подібний спосіб зберігання інформації є відносно незалежним, «нейтральним» і дозволяє отримати відповідь на різні запитикористувача про властивості описаної моделі середовища. Стандарт IDEF1Х випущено 1993 року ( FIPS 184).

2.4.1. Case-метод Баркера

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

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

Нотація ERD була вперше введена П. Ченом (Chen) та отримала подальший розвиток у роботах Баркера. Метод Баркера викладатиметься на прикладі моделювання діяльності компанії з торгівлі автомобілями. Нижче наведено витяги з інтерв'ю, проведеного з персоналом компанії.

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

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

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

Перший крок моделювання - вилучення інформації з інтерв'ю та виділення сутностей.

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

Мал. 2.18. Графічне зображення сутності

Кожна сутність повинна мати унікальний ідентифікатор. Кожен екземпляр сутності повинен однозначно ідентифікуватися та відрізнятися від усіх інших екземплярів даного типусутності. Кожна сутність повинна мати деякі властивості:

кожна сутність повинна мати унікальне ім'я, і ​​до одного й того самого імені повинна завжди застосовуватися та сама інтерпретація. Одна й та інтерпретація неспроможна застосовуватися до різних імен, якщо вони є псевдонімами;

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

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

кожна сутність може мати будь-яку кількість зв'язків з іншими сутностями моделі.

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

Мал. 2.19.

Наступним кроком моделювання є ідентифікація зв'язків.

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

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

Наприклад, зв'язок продавця з контрактом може бути виражений таким чином:

продавець може отримати винагороду за 1 або більше контрактів;

Договір має бути ініційований як одним продавцем.

Ступінь зв'язку та обов'язковість графічно зображуються наступним чином (рисунок 2.20).

Мал. 2.20.

Таким чином, 2 пропозиції, що описують зв'язок продавця з контрактом, графічно висловлюються таким чином (рисунок 2.21).

Мал. 2.21.

Описав також зв'язки решти сутностей, отримаємо наступну схему (рисунок 2.22).

Мал. 2.22.

Останнім кроком моделювання є ідентифікація атрибутів.

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

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

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

Мал. 2.23.

Мал. 2.24.

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

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

З урахуванням наявної інформації доповнимо побудовану раніше діаграму (рисунок 2.25).

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

Підтипи та супертипи:одна сутність є узагальнюючим поняттям групи подібних сутностей (рисунок 2.26).

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

Мал. 2.25.

Мал. 2.26. Підтипи та супертипи

Мал. 2.27. Взаємно виключають зв'язки

Рекурсивний зв'язок:сутність може бути пов'язана сама із собою (рисунок 2.28).

Непереміщувані (non-transferrable) зв'язки:екземпляр сутності не може бути перенесений з одного екземпляра зв'язку в інший (рисунок 2.29).

Мал. 2.28. Рекурсивний зв'язок

Мал. 2.29. Непереміщуваний зв'язок

2.4.2. Методологія IDEF1

Метод IDEF1, розроблений Т.Ремей (T.Ramey), також ґрунтується на підході П.Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі у третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створено її Нова версія- Методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення та можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERwin, Design/IDEF).

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

Мал. 2.30. Сутності

Кожній сутності присвоюється унікальне ім'я та номер, що розділяються косою рисою "/" і розміщені над блоком.

Зв'язок може додатково визначатися за допомогою вказівки ступеня або потужності (кількості екземплярів сутності-нащадка, яка може існувати для кожного екземпляра сутності-батька). У IDEF1X можуть бути виражені такі потужності зв'язків:

кожен екземпляр сутності-батька може мати нуль, один або більше пов'язаних з ним екземплярів сутності-нащадка;

кожен екземпляр сутності-батька повинен мати не менше одного пов'язаного з ним екземпляра сутності-нащадка;

кожен екземпляр сутності-батька повинен мати не більше одного пов'язаного з ним екземпляра сутності-нащадка;

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

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

Зв'язок зображується лінією, що проводиться між сутністю-батьком і сутністю-нащадком з точкою на кінці лінії біля сутності-нащадка. Потужність зв'язку позначається як показано на рис. 2.31 (потужність за замовчуванням – N).

Мал. 2.31. Потужність зв'язку

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

Мал. 2.32. Ідентифікуючий зв'язок

Пунктирна лінія зображує неідентифікуючий зв'язок (рис. 2.33). Сутність-нащадок у неідентифікуючому зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком у будь-якому ідентифікувальному зв'язку.

Мал. 2.33. Неідентифікуючий зв'язок

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

Мал. 2.34. Атрибути та первинні ключі

Сутності можуть мати також зовнішні ключі (Foreign Key), які можуть використовуватися як частина або цілий первинний ключ або неключовий атрибут. Зовнішній ключ зображується за допомогою приміщення всередину блоку сутності імен атрибутів, після яких йдуть літери FK у дужках (рис. 2.35).

Мал. 2.35. Приклади зовнішніх ключів

2.5. Приклад використання структурного підходу

2.5.1. Опис предметної області

У цьому прикладі використовується методологія Yourdon, реалізована в CASE-засобі Vantage Team Builder.

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

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

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

2.5.2. Організація проекту

Весь проект поділяється на 4 фази: аналіз, глобальне проектування (проектування архітектури системи), детальне проектування та реалізація (програмування).

На фазі аналізу будується модель середовища (Environmental Model). Побудова моделі середовища включає:

• аналіз поведінки системи (визначення призначення ІС, побудова початкової контекстної діаграми потоків даних (DFD) та формування матриці списку подій (ELM), побудова контекстних діаграм);
• аналіз даних (визначення складу потоків даних та побудова діаграм структур даних (DSD), конструювання глобальної моделі даних у вигляді ER-діаграми).

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

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

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

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

Початкова контекстна діаграма зображено малюнку 2.42. На відміну від нотації Gane/Sarson зовнішні сутності позначаються звичайними прямокутниками, а процеси – колами.

Мал. 2.42. Початкова контекстна діаграма

Список подій будується у вигляді матриці (ELM) та описує різні діїзовнішніх сутностей та реакцію ІВ на них. Ці дії є зовнішніми подіями, що впливають на бібліотеку. Розрізняють такі типи подій:

Абревіатура	Тип
	Нормальне управління
	Нормальні дані
	Нормальне управління/дані
	Тимчасове управління
	Тимчасові дані
	Тимчасове керування/дані

Усі дії позначаються як нормальні дані. Ці дані є подіями, які ІС сприймає безпосередньо, наприклад, зміна адреси клієнта, яка має бути одразу зареєстрована. Вони з'являються в DFD як вміст потоків даних.

Матриця списку подій має такий вигляд:

	Опис	Тип	Реакція
	Клієнт бажає стати членом бібліотеки		Реєстрація клієнта як члена бібліотеки
	Клієнт повідомляє про зміну адреси		Реєстрація зміненої адреси клієнта
	Клієнт просить оренду фільму		Розгляд запиту
	Клієнт повертає фільм		Реєстрація повернення
	Керівництво надає повноваження новому постачальнику		Реєстрація постачальника
	Постачальник повідомляє про зміну адреси		Реєстрація зміненої адреси постачальника
	Постачальник направляє фільм до бібліотеки		Отримання нового фільму
	Керівництво запитує новий звіт		Формування необхідного звіту для керівництва

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

Потоки на діаграмі верхнього рівня	Потоки на діаграмі нульового рівня
Інформація від клієнта	Дані про клієнта, Запит про оренду
Інформація для клієнта	Членська картка Відповідь на запит про оренду
Інформація від керівництва	Запит звіту про нових членів, Новий постачальник, Запит звіту про постачальників, Запит звіту про оренду, Запит звіту про фільми
Інформація для керівництва	Звіт про нових членів, Звіт про постачальників, Звіт про оренду, Звіт про фільми
Інформація від постачальника	Дані про постачальника, Нові фільми

На наведеній DFD (рис. 2.43) накопичувач даних "бібліотека" є глобальним або абстрактним поданням сховища даних.

Аналіз функціонального аспекту поведінки системи дає уявлення про обмін та перетворення даних у системі. Взаємозв'язок між "абстрактними" потоками даних та "конкретними" потоками даних на діаграмі нульового рівня виявляється у діаграмах структур даних (рисунок 2.44).

На фазі аналізу будується глобальна модель даних, що подається у вигляді діаграми "сутність-зв'язок" (рисунок 2.45).

між різними типамидіаграм існують такі взаємозв'язки:

• ELM-DFD: події – вхідні потоки, реакції – вихідні потоки
• DFD-DSD: потоки даних – структури даних верхнього рівня
• DFD-ERD: накопичувачі даних - ER-діаграми
• DSD-ERD: структури даних нижнього рівня – атрибути сутностей

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

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

Мал. 2.43. Контекстна діаграма

Мал. 2.44. Діаграма структур даних

Результатами проектування архітектури є:

• модель процесів (діаграми архітектури системи (SAD) та мініспецифікації на структурованою мовою);
• модель даних (ERD та підсхеми ERD);
• модель інтерфейсу користувача (класифікація процесів на інтерактивні та неінтерактивні функції, діаграма послідовності форм (FSD - Form Sequence Diagram), що показує, які форми з'являються в додатку і в якому порядку. На FSD фіксується набір і структура викликів екранних форм. Діаграми FSD утворюють ієрархію на вершині якої знаходиться головна формапрограми, що реалізує підсистему. На другому рівні знаходяться форми, що реалізують нижній рівень функціональної структури, зафіксованої на діаграмах SAD.

Мал. 2.45. Діаграма "сутність-зв'язок"

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

• уточнення моделі бази даних для подальшої генерації SQL-пропозицій;
• уточнення структури інтерфейсу користувача;
• побудова структурних схем, що відображають логіку роботи інтерфейсу користувача і модель бізнес-логіки (Structure Charts Diagram - SCD) і прив'язка їх до форм.

Результатами детального проектування є:

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

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

• генерацію SQL-пропозицій, що визначають структуру цільової БД (таблиці, індекси, обмеження цілісності);
• уточнення структурних схем (SCD) та діаграм послідовності форм (FSD) з подальшою генерацією коду додатків.

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

Характеристики сучасних операційних систем

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

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

· Архітектура мікроядра.

· Багатопоточність.

· Симетрична багатопроцесорність.

· Розподілені операційні системи.

· Об'єктно-орієнтований дизайн.

Відмінною особливістю більшості операційних систем на сьогоднішній день є велике монолітне ядро. Ядро операційної системи забезпечує більшість її можливостей, включаючи планування, роботу з файловою системою, мережеві функції, драйвери різних пристроїв, управління пам'яттю і багато інших. Зазвичай монолітне ядро ​​реалізується як єдиний процес, всі елементи якого використовують один і той же адресний простір. В архітектурі мікроядра ядру відводиться лише кілька найважливіших функцій, до яких входять робота з адресними просторами, забезпечення взаємодії між процесами (interprocess communication - IPC) і основне планування. Роботу інших сервісів операційної системи забезпечують процеси, які іноді називають серверами. Ці процеси запускаються в режимі користувача і мікроядро працює з ними так само, як і з іншими додатками. Такий підхід дозволяє поділити завдання розробки операційної системи на розробку ядра та розробку сервера. Сервери можна настроїти для конкретних програм або середовища. Виділення у структурі системи мікроядра спрощує реалізацію системи, забезпечує її гнучкість, а також добре вписується у розподілене середовище. Фактично мікроядро взаємодіє з локальним та віддаленим серверомза тією ж схемою, що спрощує побудову розподілених систем.

Багатопотоковість (multithreading) - це технологія, при якій процес, що виконує додаток, поділяється на кілька потоків, що одночасно виконуються. Нижче наведено основні відмінності між потоком та процесом.

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

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

Донедавна все персональні комп'ютери, розраховані на одного користувача, та робочі станції містили один віртуальний мікропроцесор загального призначення. Внаслідок постійного підвищення вимог до продуктивності та зниження вартості мікропроцесорів виробники перейшли до випуску комп'ютерів з кількома процесорами. Для підвищення ефективності та надійності використовується технологія симетричної багатопроцесорності (symmetric multiprocessing – SMP). Цей термін відноситься до архітектури апаратного забезпечення комп'ютера, а також до образу дій операційної системи, що відповідає цій архітектурної особливості. Симетричну багатопроцесорність можна як автономну комп'ютерну систему з такими характеристиками.

1. У системі є кілька процесорів.

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

3. Усі процесори можуть виконувати одні й самі функції (звідси назва симетрична обробка).

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

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

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

· Нарощування. Додаючи до системи додаткові процесори, користувач може підвищити її продуктивність.

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

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

Мал. 2.12. Багатозадачність та багатопроцесорність

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

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

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

Міністерство економічного Міністерства науки та освіти розвитку Російської Федерації Російської Федерації

Державний університет -

вища школа економіки

Факультет бізнес-інформатики

Реферат з дисципліни

« Методологія програмної інженерії»

« CASE технології розробки програмних систем».

Виконав:

Гладишев І.А.

171м, УРПО

Перевірив:

Авдошин С.М.

Москва 2008 р.

Вступ

1. CASE засіб: визначення та загальна характеристика.

2. Застосування CASE технологій: переваги та недоліки.

3. Використання CASE-технологій.

4. Приклади CASE-засобів та його характеристики.

4.3 Vantage Team Builder

4.4 Локальні засоби (ERwin, BPwin, S-Designor)

4.5 Об'єктно-орієнтовані CASE-засоби (Rational Rose)

4.6 Кошти конфігураційного управління

4.7 Засоби документування

4.8 Засоби тестування

Висновок

Література

Вступ

Мета мого реферату – розглянути технології розробки програмних системна основі CASE засобів. У 70-х і 80-х роках при розробці ІВ досить широко застосовувалася структурна методологія, що надає розпорядникам у розпорядження суворі формалізовані методи опису ІВ і прийнятих технічних рішень. Протягом усієї історії програмування програмні проекти дедалі більше ускладнювалися, обсяг робіт стрімко збільшувався, виникла потреба у універсальних засобах, які б допомогти якось структурувати створення ПЗ. Традиційні мови програмування в силу малої наочності, надмірності та багатослівності втрачали свою ефективність і в 70-х та 80-х роках при розробці програмних систем досить широко застосовувалася структурна методологія. Наочність та суворість засобів структурного аналізу дозволяла розробникам та майбутнім користувачам системи обговорювати та закріплювати розуміння основних технічних рішень. Все йшло до появи програмнотехнологічних засобів спеціального класу.

1. CASE засіб: визначення та загальна характеристика.

Абревіатура CASE розшифровується як Computer Aided Software Engineering. Цей термін широко використовується зараз. На етапі появи подібних коштів термін CASE використовувався лише щодо автоматизації розробки програмного забезпечення. Сьогодні CASE кошти подразмевают процес розробки складних ІВ загалом: створення та супровід ІВ, аналіз, формулювання вимог, проектування прикладного ПЗ та баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління та управління проектом, а також інші процеси. Таким чином, CASE-технології утворюють ціле середовище розробки ІВ. Отже, CASE-технологія є методологією проектування програмних систем, а також набір інструментальних засобів, що дозволяють у наочній формі моделювати предметну область, аналізувати цю модель на всіх етапах розробки та супроводу ІС та розробляти додатки відповідно до інформаційних потреб користувачів. Більшість існуючих CASE-засобів засновані на методологіях структурного або об'єктно-орієнтованого аналізу та проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поведінки системи та архітектури програмних засобів. Головні складові CASE-продукту такі:

методологія (Method Diagrams), яка задає єдину графічну мову та правила роботи з нею.

графічні редактори (Graphic Editors)які допомагають малювати діаграми; виникли з поширенням PC та GUI, так званих «upper case технологій

генератор: по графічному уявленнюМодель можна згенерувати вихідний код для різних платформ (так звана low case частина CASE-технології).

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

2. Застосування CASE технологій: переваги та недоліки.

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

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

реальні витрати на використання CASE-коштів зазвичай набагато перевищують витрати на їх придбання;

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

Зважаючи на різноманітну природу CASE-засобів, було б помилково робити будь-які беззастережні твердження щодо реального задоволення тих чи інших очікувань від їх впровадження. Можна перерахувати такі фактори, що ускладнюють визначення можливого ефекту від використання CASE-засобів:

широке розмаїття якості та можливостей CASE-засобів;

відносно невеликий час використання CASE-засобів у різних організаціях та брак досвіду їх застосування;

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

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

широкий діапазон предметних галузей проектів;

різний ступінь інтеграції CASE-коштів у різних проектах.

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

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

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

Управління: чітке керівництво та організованість стосовно найбільш важливих етапів та процесів впровадження.

високий рівень технологічної підтримки процесів розробки та супроводу ПЗ;

позитивний вплив на деякі або всі з цих факторів: продуктивність, якість продукції, дотримання стандартів, документування;

прийнятний рівень віддачі від інвестицій у CASE-кошти.

3. Використання CASE-технологій.

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

визначення потреб у CASE-засобах;

оцінка та вибір CASE-засобів;

виконання пілотного проекту;

практичне використання CASE-засобів.

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

4. Приклади CASE-засобів та його характеристики.

4.1 Silverrun

CASE-засіб Silverrun американської фірми Computer Systems Advisers, Inc. використовується для аналізу та проектування ІС бізнес-класу. Воно застосовується підтримки будь-якої методології, заснованої на роздільному побудові функціональної та інформаційної моделей. Silverrun має модульну структуру і складається з чотирьох модулів, кожен з яких є самостійним продуктом і може купуватись і використовуватись без зв'язку з іншими модулями: модуль побудови моделей бізнес-процесів, модуль концептуального моделювання даних, модуль реляційного моделювання та менеджер репозиторію робочої групи. Платою за високу гнучкість та різноманітність образотворчих засобів побудови моделей є такий недолік Silverrun, як відсутність жорсткого взаємного контролю між компонентами різних моделей

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

ядро системи;

JAM/DBi – спеціалізовані модулі інтерфейсу до СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC тощо);

JAM/RW – модуль генератора звітів;

JAM/CASEi – спеціалізовані модулі інтерфейсу до CASE-засобів (JAM/CASE-TeamWork, JAM/CASE-Innovator тощо);

JAM/TPi – спеціалізовані модулі інтерфейсу до менеджерів транзакцій (наприклад, JAM/TPi-Server TUXEDO тощо);

Jterm – спеціалізований емулятор X-терміналу.

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

4.3 VantageTeamBuilder

Vantage Team Builder є інтегрованим програмним продуктом, орієнтованим на реалізацію каскадної моделі ЖЦ ПЗ та підтримку повного ЖЦ ПЗ. Наявність універсальної системи генерації коду, що ґрунтується на специфікованих засобах доступу до репозиторію проекту, дозволяє підтримувати високий рівень виконання проектної дисципліни розробниками: жорсткий порядок формування моделей; жорстка структура та вміст документації; автоматична генерація вихідних програмних кодів і т.д. - все це забезпечує підвищення якості та надійності ІС, що розробляються.

4.4 Локальні засоби (ERwin, BPwin, S-Designor)

ERwin – засіб концептуального моделювання БД, що використовує методологію IDEF1X. ERwin реалізує проектування схеми БД, генерацію її опису мовою цільової СУБД та реінжиніринг існуючої БД. ERwin випускається в різних конфігураціях, орієнтованих на найбільш поширені засоби розробки додатків 4GL. Для ряду засобів розробки додатків (PowerBuilder, SQLWindows, Delphi, Visual Basic) виконується генерація форм та прототипів додатків. BPwin – засіб функціонального моделювання, що реалізує методологію IDEF0. S-Designor є CASE-засіб для проектування реляційних баз даних. За своїми функціональними можливостями і вартістю він близький до CASE-засобу ERwin, відрізняючись нотацією, що зовні використовується на діаграмах. S-Designor реалізує стандартну методологію моделювання даних та генерує опис БД для таких СУБД, як ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Serverта ін.

4.5 Об'єктно-орієнтовані CASE-засоби (Rational Rose)

Rational Rose - CASE-засіб фірми Rational Software Corporation - призначений для автоматизації етапів аналізу та проектування ПЗ, а також для генерації кодів різними мовами та випуску проектної документації. Rational Rose використовує синтез-методологію об'єктно-орієнтованого аналізу та проектування, засновану на підходах трьох провідних фахівців у цій галузі: Буча, Рамбо та Джекобсона. Розроблена ними універсальна нотація для моделювання об'єктів (UML – Unified Modeling Language) претендує на роль стандарту в галузі об'єктно-орієнтованого аналізу та проектування. Конкретний варіант Rational Rose визначається мовою, якою генеруються коди програм (C++, Smalltalk, PowerBuilder, Ada, SQLWindows і ObjectPro). Основний варіант – Rational Rose/C++ – дозволяє розробляти проектну документацію у вигляді діаграм та специфікацій, а також генерувати програмні коди на С++. Крім того, Rational Rose містить засоби реінжинірингу програм, що забезпечують повторне використання програмних компонентів у нових проектах.

4.6 Кошти конфігураційного управління

Мета конфігураційного управління - забезпечити керованість та контрольованість процесів розробки та супроводу ПЗ. Для цього необхідна точна та достовірна інформація про стан ПЗ та його компонент у кожний момент часу, а також про всі передбачувані та виконані зміни. Для вирішення завдань КУ застосовуються методи і засоби, що забезпечують ідентифікацію стану компонентів, облік номенклатури всіх компонентів і модифікацій системи в цілому, контроль за змінами, що вносяться до компонентів, структуру системи та її функції, а також координоване управління розвитком функцій і поліпшенням характеристик системи. Найбільш поширеним засобом КУ є PVCS фірми Intersolv (США), що включає низку самостійних продуктів: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder та PVCS Notify.

4.7 Засоби документування

Для створення документації у процесі розробки ІС використовуються різноманітні засоби формування звітів та компоненти видавничих систем. Зазвичай засоби документування вбудовані у конкретні CASE-кошти. Винятком є ​​деякі пакети, які надають додатковий сервіс під час документування. З них найбільше активно використовується SoDA (Software Document Аutomation).

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

4.8 Засоби тестування

Під тестуванням розуміється процес виконання програми з виявлення помилок. Регресійне тестування - це тестування, яке проводиться після вдосконалення функцій програми або внесення змін до неї. Один з найбільш розвинених засобів тестування Quality Works є інтегрованим багатоплатформовим середовищем для розробки автоматизованих тестів будь-якого рівня, включаючи тести регресії для додатків з графічним інтерфейсом користувача. Quality Works дозволяє починати тестування на будь-якій фазі ЖЦ, планувати та керувати процесом тестування, відображати зміни у додатку та повторно використовувати тести для більш ніж 25 різних платформ.

Висновок

У роботі було розглянуто технології розробки програмних систем з урахуванням CASE технологій. Докладно розібрано визначення такого широкого поняття, як CASE засіб, визначено основні складові CASE продукту. Також у роботі мною розглядалися основні переваги та можливі недоліки у процесі застосування CASE засобів у розробці програмних систем, як з погляду технічних, так і з боку економічних аспектів. Далі були перелічені приклади CASE технологій та дані їх характеристики.

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

Література

А.М. Вендров: CASE-технології. Сучасні методи та засоби проектування інформаційних систем
М.: Фінанси та статистика, 1998. - 176 с.: Ілл

Калянов Г.М. CASE. Структурний системний аналіз(Автоматизація та застосування). М., "Лорі", 1998.

Новоженов Ю.В. Об'єктно орієнтовані технології розробки складних програмних систем. М., 1997

Панащук С.О. Розробка інформаційних систем із використанням CASE-системи Silverrun. "СУБД", 1997.

Горчинська О.Ю. Designer/2000 – нове покоління CASE-продуктів фірми ORACLE. "СУБД", 1996.

Горін С.В., Тандо А.Ю. Застосування CASE-засобу Erwin 2.0 для інформаційного моделювання у системах обробки даних. "СУБД", 1999.