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

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

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

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

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

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

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

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

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

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

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

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

Дати изначення методології DATARUN .

Методології проектування ПЗ як програмних продуктів. Методологія DATARUN і інструментальний засіб SE Companion Методологія DATARUN

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

Стадії методології DATARUN

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

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

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

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

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

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