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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Абревіатура	Тип
NC	Нормальне управління
ND	Нормальні дані
NCD	Нормальне управління/данні
TC	Тимчасове управління
TD	Тимчасові дані
TCD	Тимчасове управління/данні

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

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

№	Опис	Тип	Реакція
1	Клієнт бажає стати членом бібліотеки	ND	Реєстрація клієнта як члена бібліотеки
2	Клієнт повідомляє про зміну адреси	ND	Реєстрація зміненої адреси клієнта
3	Клієнт запрошує оренду фільму	ND	Розгляд запиту
4	Клієнт повертає фільм	ND	Реєстрація повернення
5	Керівництво надає повноваження новому постачальнику	ND	Реєстрація постачальника
6	Постачальник повідомляє про зміну адреси	ND	Реєстрація зміненої адреси постачальника
7	Постачальник направляє фільм в бібліотеку	ND	Отримання нового фільму
8	Керівництво запрошує новий звіт	ND	Формування необхідного звіту для керівництва

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

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

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

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

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

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

• ELM-DFD: події – вхідні потоки, реакції – вихідні потоки

• DFD-DSD: потоки даних – структури даних верхнього рівня

• DFD-ERD: накопичувачі даних – ER-діаграми

• DSD-ERD: структури даних нижнього рівня – атрибути суті

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

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

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

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

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

Мал. 2.

Список використаної літератури

1. ВендровА.М.Один з підходів до вибору засобів проектування баз даних і застосувань. «СУБД», 1995 №3.

2. КаляновГ.Н. CASE. Структурний системний аналіз (автоматизація і застосування). М., «Лорі», 1996.

3. МаркаД.А., МакГоуен К.Методология структурного аналізу і проектування. М., «МетаТехнология», 1993.

4. Створення інформаційної системи підприємства. «Computer Direct», 1996 N2

Основи CASЕ-технологій (стр. 2 из 2)

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