14. Визначення прецеденту. Що таке сценарій прецеденту та правила його опису?

Прецедент (варіант використання) - словесний опис процесів предметної області.

Діаграма прецедентів (варіантів використання) – ілюстрація (візуальне представлення) всіх прецедентів та їх взаємозв’язків. Правила словесного опису:

Прецедент (Придбання товару)

Виконавці (покупець, касир)

Тип (головний, розгорнутий)

Опис (покупець підходить до каси з товарами... Касир реєструє і підраховує суму....

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

Сценарій прецеденту - це його приватний випадок чи реальний шлях його реалізації.

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

Прецедент описується у вигляді таблиці:

Назва П.
Виконавець
Тип (категорія)
Опис

Категорії прецедентів:

основний; другорядний; додатковий.

Опис Реального прецеденту:

Дії виконавця	Відгук системи
Типовий хід подій
1. … 2. …	1. … 2. …
Альтернативи
1. …	1. …

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

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

15. Призначення та правила побудови концептуальної моделі предметної області UML-нотації. Що таке сутність? Правила вибору сутностей. Види зв’язків між сутностями, назви зв’язків, потужність зв’язків. Що таке атрибути сутностей?

Концептуалізації

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

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

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

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

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

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

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

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

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

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

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

Не можна в концептуальну модель вносити 2 функціональних використання однієї і тієї ж суті (не вноситься список боржників так як це той же список студентів);

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

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

Інший тип зв'язків задається відносинами "мати у власності" або "мати властивість".

Відносини: залежності

Асоциации - визначає ступінь відносини, впливу ( «інтер'єр»  «диван» - без дивана це все ще інтер'єр)

Потужність відносин:

• 1..1

• 1..n

• 1..0

• n..n

Агрегації ; part of (агрегація) - «ціле»  «частина» ( «літак»  «крило» - без крила це вже не літак);

Обощенія

На концептуальної моделі для кожної сутності вказуються її атрибути - дані, якими вона описується. Атрибут - це абстрактне властивість об'єкта.В концептуальну модель включаються ті атрибути, для яких визначені відповідні вимоги (наприклад, прецеденти) або для яких передбачається, що необхідно зберігати певну інформацію. Наприклад, в товарному чеку вказується час і дата.Отже, для сутності «Продаж» (Sale) потрібні атрибути «Дата» (Date) та «Час» (Time).