К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Висновки. Проведено аналіз різних методів проектування моделей предметних областей. Значна увага приділена методу Шлеєра і Мелора, в якому визначено три види моделей і підхід до побудови на їхній основі архітектури програмних систем. Розглянуто методи проектування систем з використанням об’єктних і стандартних структур програмних систем. Контрольні питання і завдання 1. Визначте задачі аналізу предметної області. 2. Назвіть задачі концептуального проектування моделей ПрО. 3. Назвіть продукти аналізу ПрО в методі Шлеєра і Мелора. 4. Назвіть моделі методу Шлеєра і Мелора і опишіть їхню сутність. 5. Які ще види моделей ПрО існують? 6. Перелічіть ключові чинники, що впливають на проектування архітектури. 7. Назвіть приклади нефункціональних вимог, що потрібно враховувати при проектуванні архітектури системи. 8. Які рівні виділяються в архітектурі системи? 9. Назвіть прийоми проектування у середовищі RUP. Список літератури до розділу 4 1. Шлеер С. , Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях .– Киев: Диалектика, 1993. – 240 с. 2. Coad P.,Yourdan E. Object-oriented analysis.–Second Edition.–Prentice Hall, 1991. – 296 p. 3. Yourdan E. Modern Structured Analysis. – New York: Yourdan Press / Prentice Hall, 1988. – 297 p. 4. DeMarko D.A., McGovan R.L. SADT: Structured Analysis and Design Technique. New York: Mcgray Hill, 1988. – 378 p. 5. Yourdan E., Constantine L. Structured Design. Yourdan Press. Engwood Cliffs – N.J. – 1983. 6. Martin J., Odell J.J. Object-oriented analysis and design.–Prentice Hall, 1992. – 367p. 7. Barker R. CASE-method. Entity Relationship Modelling. – Copyright ORACLE Corporation UK Limited–New York: Publ., 1990. – 312 p. 8. Schardt J.A. Assentials of Distributed Object Design M.S.E. Advanced Concepts Center, 1994. – P. 225 –234. Розділ 4 97 9. Rumbaugh J., Blaha V., Premerlani W. Object-Oriented Modelling and Design, Englewood Cliffs.– NJ: Prentice Hall, 1991. – 451 p. 10. Гради Буч.Объектно-ориентированное проектирование. – 3-е издание. – М.: Бином, 1998. – 560 с. 11. Jacobson I. Object-Oriented Software Engineering. A use Case Driven Approach, Revised Printing. – New York: Addison-Wesley Publ.Co. – 1994. – 529 p. 12. Андон Ф.И., Яшунин А.Е., Резниченко В.А. Логические модели интеллектуальных информационных систем.– Киев: Наук. думка, 1999. – 396 с. 13. Чернецки К., Айзенекер У. Порождающее программирование. Методы, инструменты, применение. –Издательский дом «Питер». – М.: СПб. – Харьков – Минск, – 2005. – 730 с. 14. Фреге Г. Логика и логическая семантика. – М.: Аспект–пресс, 2000. – 512 с. 15. Орфали Р., Харки Д. Эдвардс Дж. Основы CORBA.– Из.-во «Малип», М.: 1999. –317с. 16. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. –510 с. 17. Рамбо Дж., Джекобсон А, Буч Г. UML: специальный справочник. – СПб.: Питер. – 2002. – 656 с. 18. Боггс У., Боггс М. UML Rational Rose. Бестселлер #, Лори.– Москва, 2000.- 580 с. 19. Кендалл Скотт. Унифицированный процесс. Основные концепции. – М.: СПБ. – Киев. – 2002. – 157 с. 98 Розділ 5. ПРИКЛАДНІ Й ТЕОРЕТИЧНІ МЕТОДИ ПРОГРАМУВАННЯ Ядро SWEBOK містить у собі два близьких за змістом розділи, які пов’язані з побудовою ПЗ: проектування ПЗ і конструювання ПЗ. Розділ, що стосується програмування, в цьому ядрі відсутній, проте він є необхідний, оскільки в сучасній практиці проектування і розроблення ПП широко використовуються багато різних парадигм програмування (модульне, об’єктно-орієнтоване, компонентне, аспектне тощо), які мають бути певним чином систематизовані. Кожна парадигма програмування характеризується наявністю в ній метода і зв’язком з моделлю ЖЦ. Головне, що об’єднує різні парадигми програмування, – це загальні положення з проектування ПП. Користувач може вибирати ту або іншу парадигму програмування з позицій зручності застосування для задач у ПрО і виготовлення конкретного ПП. Розрізняють прикладні і теоретичні методи, які з’явилися у різний час від моменту появи програмної інженерії і мають свою специфіку й сферу застосування. Наприклад, структурний метод виник багато років тому, він добре відпрацьований і вдосконалений для індустріального виготовлення ПП і навіть став держстандартом у Великобританії. Широкого застосування набули методи модульного і компонентного програмування. Вони базуються на концепції повторного використання компонентів. Саме ці види програмування започаткували індустрію виготовлення ПП з готових компонентів, аналогічно до того, як в промисловості здійснювалося виготовлення виробів з готових деталей. Поява нових методів стимулюється досягненнями загальнонаукових дисциплін (математики, логіки, теорії алгоритмів тощо) і практичними задачами. Теоретичні методи програмування дозволяють створювати програмні системи в абстрактному вигляді, включаючи концептуальні, інформаційні, структурні моделі без урахування особливостей середовищ, в яких вони реалізуються. Ці моделі доводяться до стану кінцевого продукту шляхом використання відповідних мов програмування та їх перетворення. Знаходять застосування формальні й теоретичні методи програмування (алгебраїчний, алгебро-алгоритмічний, композиційний й ін.), які ґрунтуються на математичних і логіко-алгоритмічних підходах до абстрактного створення ПП. У цьому розділі описані базові поняття й особливості методів прикладного, або систематичного програмування, а також окремих методів теоретичного програмування з метою ознайомлення студентів із сучасною теорією і практикою розробки програм і систем. 5.1. Прикладне (систематичне) програмування До методів систематичного програмування відносять такі методи: – структурний; – об’єктно-орієнтований; – UML-метод; – компонентний; – аспектно-орієнтований; Розділ 5 99 – генерувальний; – сервісний; – агентний й ін. Кожен з цих методів має свою множину понять й операцій для проведення процесу розроблення окремих компонентів, сервісів або ПС. Метод генеруючого програмування використовує можливості об’єктно-орієнтованого, компонентного, аспектно-орієнтованого методів й ін. 5.1.1 Структурне програмування Сутність структурного підходу до розробки ПС полягає в декомпозиції (розподілі) системи на функції, що підлягають автоматизації, які у свою чергу, діляться на підфункції й задачі. Процес декомпозиції триває до визначення конкретних процедур. При цьому система, що автоматизується, зберігає цілісне подання, у якому всі складові компоненти взаємозалежні [1]. Основу структурного програмування становлять: – розподіл системи на множину незалежних задач, доступних для розуміння і розв’язання; – впорядкування й організація складових частин проблеми в ієрархічні деревоподібної структури з додаванням нових деталей на кожному рівні. До головних принципів належать: – абстрагування, тобто відокремлення істотних аспектів системи й нехтування несуттєвими; – формалізація, тобто загальне методологічне вирішення проблеми; – обґрунтування й узгодження елементів системи і перевірка їх на несуперечність; – утворення ієрархічної структури даних. При структурному аналізі застосовуються три найпоширеніші моделі структурного проектування ПС: SADT (Structured Analysis and Design Technique) – метод структурного аналізу й техніка проектування моделі системи за допомогою функціональних діаграм [1]; SSADM (Structured Systems Analysis and Design Method) – метод структурного аналізу й проектування систем [2]; IDEF (Integrated Definition Functions) – метод визначення функціональної моделі, IDEF1 – інформаційної моделі, IDEF2 – динамічної моделі й ін. [3]. Розглянемо ці методи детальніше. Метод функціонального моделювання SADT. Цей метод запропоновано Д.Россом і покладено в основу методології IDEF0 (Icam DEFinition), що є головною частиною програми ICAM (Інтеграція комп'ютерних і промислових технологій), проведеної з ініціативи ВПС США. На стадії проектування моделі системи зображаються у вигляді діаграм або екранних форм і відображають структуру або архітектуру системи, а також схеми програм. SADT – це сукупність правил і процедур, призначених для побудови функціональної моделі предметної області, яка відображає функціональну структуру, функції і дії, а також зв'язки між ними. Метод SADT базується на наступних концепціях: 100 Розділ 5 – графічне зображення структури з поданням функцій блоками, а інтерфейсів дугами, що, відповідно, входять у блок і виходять з нього (рис.5.1); Рис. 5.1. Структура моделі – блоків може бути від 3 до 6 на кожному рівні декомпозиції; – взаємодія блоків описується обмеженнями, які визначають умови керування й виконання функцій; – унікальність позначок і найменувань; – незалежність функціональної моделі від організаційної структури колективу розробників. Метод SADT застосовується при моделюванні широкого кола систем, для яких визначаються вимоги й функції, а потім проводиться їхня реалізація. Засоби SADT можуть застосовуватися при аналізі функцій у діючій ПС, а також при визначенні способів їхньої реалізації. Результат проектування в методі SADT – модель, що складається з діаграм, фрагментів текстів і глосарію з посиланнями один на одного. Всі функції й інтерфейси зображаються діаграмами у вигляді блоків і дуг. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керуюча інформація позначається дугою, яка входить у блок зверху, у той час як інформація, що піддається обробці, вказується з лівої сторони блоку, а результати виходу – з правої сторони. Механізм, що здійснює операцію (людина або автоматизована система), задається дугою, що входить у блок знизу. Одна з найбільш важливих переваг методу SADT – поступова деталізація моделі системи в міру додавання функцій і діаграм, що уточнюють цю модель. Метод SSADM базується на таких структурах: послідовність, вибір й ітерація. Об’єкт моделювання задається відповідними структурними діаграмами, які відображають послідовність операторів, вибір елементів із групи й циклічне виконання операторів за цими елементами. Загальна діаграма системи згідно з цим методом має ієрархічну структуру і містить у собі: список компонентів модельованого об'єкта; ідентифіковані групи вибраних і повторюваних компонентів; послідовність використовуваних компонентів. Таке програмування передбачає наявність моделі ЖЦ із послідовними процесами розроблення програмного проекту, починаючи з аналізу і формування вимог для ПрО (рис. 5.2). До процесів ЖЦ належать: – стратегічне проектування та вивчення можливості виконання проекту; – детальне дослідження предметної області, що містить у собі аналіз і специфікацію вимог; Розділ 5 101 – логічне проектування та специфікація компонентів системи; – фізичне проектування структур даних відповідно до вибраної структури БД (реляційної, об’єктно-орієнтованої й ін.) та конструювання окремих компонентів, їх тестування і тестування системи в цілому; – виготовлення продукту і документації з нього для замовника. Рис.5.2. Життєвий цикл SSADM Детальне дослідження предметної області проводиться для того, щоб вивчити її особливості, розглянути потреби й пропозиції замовника, провести аналіз вимог з різних документів, специфікувати їх і погодити із замовником. Мета стратегічного проектування – визначення сфери дії проекту, аналіз інформаційних потоків, формування загальної архітектури системи, визначення витрат на розробку і підтвердження можливості подальшої реалізації проекту. Результат – це специфікація вимог, що застосовується при розроблені логічної структури системи. Логічне проектування – це визначення функцій, діалогу, методу побудови і відновлення БД. У логічній моделі відображаються вхідні й вихідні дані, проходження запитів і встановлення взаємозв'язків між сутностями та подіями. Фізичне проектування – це визначення типу СКБД і подання даних у ній з урахуванням специфікації логічної моделі даних, обмежень на пам'ять і час обробки, а також визначення механізмів доступу, розміру логічної БД, зв'язків між елементами системи. 102 Розділ 5 Фізична специфікація містить у собі: – специфікацію функцій і схеми реалізації компонентів функцій, – опис процедурних і непроцедурних компонентів й інтерфейсів, – визначення логічних і фізичних груп даних з урахуванням обмежень устаткування на розробку й стандарти розробки, – визначення груп подій, які обробляються як єдине ціле з видачею повідомлень про завершення обробки й ін. Процеси, які виконуються у SSADM, пов'язані з роботами, що керують потоками інформації трьох типів: потік робіт; санкціоновані потоки за контролем або керуванням; звіти про хід розроблення. Конструювання – це побудова конструкцій і елементів системи, їхнє тестування на наборах даних, які підбираються на ранніх процесах ЖЦ розробки системи. Життєвий цикл містить у собі процес керування і контролю, який базується на сітковому графіку, що враховує роботи з розробки системи, витрати і строки. Спостереження і контроль виконання плану проводить організаційний відділ. У графіку містяться роботи й взаємозв'язки між ними і їхніми виконавцями, а також проектні документи, які розроблюються виконавцями. Результати кожного з процесів ЖЦ контролюються і передаються на наступний етап у вигляді, зручному для подальшої реалізації іншими виконавцями. Згідно з методом SADM створюється структурна модель системи і модель потоків даних. У діаграмах структурної моделі впорядкування процесів наведено зліва направо і віддзеркалює розвиток у часі, а не інтервали часу. Модель потоків даних (Data Flow Model – DFM) використовується для опису процесів обробки даних у системі й містить у собі: – ієрархічний набір діаграм потоків даних (Data Flow Diagram – DFD); – опис елементарних процесів, потоків даних, сховищ даних і зовнішніх сутностей. Кожна DFD відбиває проходження даних через систему залежно від рівня та призначення діаграми. DFD перетворює вхідні потоки даних (входи) у вихідні потоки даних (виходи). Як правило, процеси, що виконують такі перетворення, створюють і використовують дані зі сховища даних. До об'єктів моделювання системи в SSADM належать: 1. Функції, які створюються на основі DFM і моделювання взаємозв'язків подій і сутностей для дослідження обробки даних у системі; 2. Події – деякі прикладні дії, які ініціюють процеси для занесення й відновлення даних системи. Подія приводить до виклику процесу і досліджується за допомогою моделювання її впливу на сутності; 3. Дані зображаються спочатку логічною моделлю, потім фізичною, яка відображається у реляційну або об’єктно-орієнтовану БД, залежно від вибраної для проекту СКБД. Найпоширеніші засоби моделювання даних – діаграми «сутність–зв'язок» (ER-діаграми), запропоновані Баркером, як застосування класичної ER-моделі Чена. В ER-діаграмах визначаються сутності (множини однотипних об'єктів) ПрО, їхні властивості (атрибути) і залежності (зв'язки). Сутність (Entity) – реальний або уявлюваний об'єкт, що має істотне значення для області. Кожна сутність й її екземпляр мають унікальні імена. Сутність має такі властивості: Розділ 5 103 – один або кілька атрибутів, які або належать сутності, або успадковуються через зв'язок (Relationship); – довільну кількість зв'язків з іншими сутностями моделі. Зв'язок – це асоціація між двома сутностями ПрО. У загальному випадку кожен екземпляр сутності-батька асоційований з довільною кількістю екземплярів успадкованої сутності (нащадка), а кожен екземпляр сутності-нащадка асоційований з одним екземпляром сутності-батька. Таким чином, екземпляр сутності-нащадка може існувати тільки при наявності сутності-батька. Для зв’язків можуть встановлюватися обмеження на кількість екземплярів сутності, що беруть участь у зв’язку. Наприклад, одному екземпляру однієї сутності може відповідати не більше ніж один екземпляр іншої. Метод IDEF1 базується на концепції ER-моделювання і призначений для побудови інформаційної моделі подібно до реляційної моделі. Даний метод постійно розвивається й удосконалюється (наприклад, методологія IDEF1X- проектування, орієнтована на автоматизацію – ERwin, Design/IDEF). Основна особливість полягає в тому, що кожен екземпляр сутності може бути однозначно ідентифікований без визначення відношення з іншими сутностями. Якщо ідентифікація екземпляра сутності залежить від його відношення до іншої сутності, то сутність є залежною. Кожній сутності присвоюється унікальне ім'я і номер, які розділяють косою рискою «/ » і розміщують над блоком, який позначає сутність. Обмеження на множинність зв’язку можуть означати, що для кожного екземпляра сутності-батька існує: – нуль, один або більше пов'язаних з ним екземплярів сутності-нащадка; – не менше ніж один або не більше ніж один пов'язаний з ним екземпляр сутності-нащадка; – зв'язок з деяким фіксованим числом екземплярів сутності-нащадка. Якщо екземпляр сутності-нащадка однозначно визначається своїм зв'язком із сутністью-батьком, то зв'язок є ідентифікований, інакше – неідентифікований. Сутність-батько в ідентифікованому зв'язку може бути як незалежною, так і залежною від зв'язків з іншими сутностями. Сутність-нащадок у неідентифікованому зв'язку буде незалежною, якщо вона не є також сутністю- нащадком у якому-небудь ідентифікованому зв'язку. Атрибути зображуються у вигляді списку імен усередині блока сутності, первинний ключ розміщується нагорі списку і відокремлюється від інших атрибутів горизонтальною рискою. Сутності можуть мати також зовнішні ключі, як частина або ціле первинного ключа або неключового атрибуту. Засобами IDEF1 проводиться збирання і вивчення різних сфер діяльності підприємства, визначення потреб в інформаційному менеджменті, а також: – інформації й структури потоків, що властиві діяльності підприємства; – правил і законів руху інформаційних потоків і принципів керування ними; – взаємозв'язків між існуючими інформаційними потоками на підприємстві; –проблем, що виникають при неякісному інформаційному менеджменті і потребують усунення. Одна з особливостей даної методології – забезпечення структурованого процесу аналізу інформаційних потоків підприємства і можливості зміни неповної й неточної структури інформації на процесі моделювання інформаційної структури підприємства. |