3.2. Пропозиції, щодо впровадження бета-версії нового пз

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

3.3. Об’єктно-орієнтоване моделювання предметної області

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

У мові UML використовується 9 видів діаграм (прецедентів, діяльності, класів, послідовності, кооперації, об’єктів, компонентів, розгортання та станів), але при моделювання розроблюваного ПЗ буде застосовано лише 5.

Діаграма варіантів використання

Розробка діаграми варіантів використання має на меті:

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

• Сформулювати загальні вимоги до функціональної поведінки проектованої системи.

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

• Підготувати вихідну документацію для взаємодії розробників системи з її замовниками і користувачами.

Суть даної діаграми полягає в наступному:

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

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

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

Актори на діаграмі варіантів використання позначаються символом людини, а варіанти використання – еліпсом. Актори та варіанти використання поєднуються напрямленою асоціацією (unidirectional association) – стрілкою, що спрямована від актора до варіанта використання. Також актори можуть поєднуватися з використанням зв’язків узагальнення. Відношення узагальнення (generalization) показують відношення між загальним і частковим.

Діаграма діяльності

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

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

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

В діаграмі я використовую елементи розгалуження і синхронізації, які на діаграмі позначаються так:

Рис.3.1. Елементи розгалуження і синхронізації

На діаграмі їх застосування буде таким:

Рис.3.2. Використання елементів розгалуження, синхронізації та інших

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

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