
- •6.050103 — Програмна інженерія
- •1 Збір інформації про призначення програмної системи
- •1.1 Ситуаційна вправа
- •1.2 Методичні вказівки до заняття
- •2 Моделювання предметної області
- •2.1 Ситуаційна вправа
- •2.2 Методичні вказівки до заняття
- •3 Модель процесу розробки програмної системи
- •3.1 Ситуаційна вправа
- •3.2 Методичні вказівки до заняття
- •4 Специфікація вимог до програмної системи
- •4.1 Ситуаційна вправа
- •4.2 Методичні вказівки до заняття
- •5 Варіанти використання програмної системи
- •5.1 Ситуаційна вправа
- •5.2 Методичні вказівки до заняття
- •6 Діаграма концептуальних класів
- •6.1 Ситуаційна вправа
- •6.2 Методичні вказівки до заняття
- •7 Діаграми взаємодій
- •7.1 Ситуаційна вправа
- •7.2 Методичні вказівки до заняття
- •8 Формальне моделювання об’єктних обмежень
- •8.1 Ситуаційна вправа
- •Навчальне видання
6 Діаграма концептуальних класів
6.1 Ситуаційна вправа
Ну от, з'єднали. «Я знаю, ви мене чуєте, – почав він. – Я відчуваю вас, я знаю, ви боїтеся. Боїтеся нас, боїтеся змін. Я не знаю майбутнього, я не стану пророкувати, чим усе скінчиться. Я скажу лише, з чого почнеться. Зараз я повішу трубку і потім покажу людям те, що ви хотіли сховати. Покажу їм світ без вас. Світ без диктату і заборон, світ без меж. Що буде далі, вирішувати нам». Він повільно повісив трубку, і телефон відразу задзвонив. «Дивно, адже фінал не такий», – подумав він і прокинувся.
«Цікаво, такі сни – це сигнал про необхідність відпочинку?» – розмірковував Андрій Жданов, розробник відділу програмного забезпечення, стоячі біля кава-апарату та вирішуючи, якої кави він бажає.
Зручно розташувавшись з кавою за столом, Андрій завантажив свою френд-стрічку, але прочитати жодного повідомлення не встиг. Біля його стола матеріалізувався Сергій. «Ось вимоги до нової системи, – Сергій як фокусник невідомо звідки витягнув два аркуші з блокноту з рукописним текстом. – Будь ласка, швиденько робимо модельку предметної області». Андрій тужливо подивився в бік свого друга Романа, той про щось домовлявся з Наталкою. Звісно, це лише йому так щастить, мусить працювати з провідним. «Чудово, беруся до роботи», – відповів Андрій, Сергій задоволено кивнув та зник.
Перед Андрієм було два аркуші: «Вимоги до системи» та «Додаткова інформація». Він розпочав з першого.
Завдання
1. Визначити на основі «Вимог до системи» (практичне заняття 2), які класи необхідні для моделювання предметної області системи.
Оскільки залишилися нез'ясованими деякі аспекти, Андрій прийнявся за «Додаткову інформацію».
Завдання
2. Уточнити на основі «Додаткової інформації» (практичне заняття 2) множину концептуальних класів для проектованої системи.
Тепер залишилося визначити, які зв'язки існуватимуть між класами, та навіщо вони потрібні.
Завдання
3. Побудувати діаграму концептуальних класів, доповнивши множину класів потрібними асоціаціями.
З видом переможця Андрій стояв біля стола Сергія. Той, уважно роздивившись подану діаграму, запропонував Андрію сісти, поліз до шухляди свого стола та витягнув звідти пачку CRC-карток. Андрію закортіло вбити провідного: мати напрацьовані рішення і не поділитися ними.
Сергій довго та уважно порівнював діаграму з власними картками, після чого повернув аркуш з діаграмою Андрію. «Ну добре, тепер разом з Романом маєте довести модель до досконалості».
6.2 Методичні вказівки до заняття
Завдання 1-2
Моделювання класів – процес не детермінований, не існує єдиної методики його виконання. Підхід на основі використання іменних груп [1] припускає, що аналітик шукає іменні групи в описі вимог. Кожен іменник є потенційним класом. Потім отриманий список класів розділяють на три групи:
Релевантні класи – це класи, які безумовно належать до проблемної області
Нечіткі класи – це класи, які неможна впевнено та безсумнівно визнати релевантними
Нерелевантні класи – це класи, які виходять за межі проблемної області
Керівні принципи для визначення класів:
Для кожного класу має бути ясно сформульовано його призначення в системі
Кожен клас – це шаблон для опису множини об’єктів. Одиничні класи, для яких можна уявити існування лише одного об’єкта, малоймовірні серед «бізнес-об’єктів»
Кожен клас має містити набор атрибутів
Клас має відрізнятися від атрибуту. Але визначення того, чим є поняття (класом чи атрибутом) залежить від предметної області застосунку
Клас має містити набор операцій
Завдання 3
Знаходження основних асоціацій є побічним ефектом процесу виявлення класів. Під час виконання пробного прогону варіантів використання з’ясовують шляхи взаємодії між класами. Ці взаємодії підтримують асоціації.