ПроектнийПрактикум / ПрофесійнаПрактика / Разное / lavrishcheva-6

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

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

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

Даний стандарт регламентує:

–концептуальне проектування, тобто побудову концептуальної моделі, уточнення рішень і узгодження вимог;

–архітектурне проектування – визначення головних структурних компонентів і особливостей системи;

–технічне проектування – відображення вимог, визначення задач і принципів їхньої реалізації в заданому середовищі функціонування системи;

–детальне робоче проектування – специфікація алгоритмів розв’язків задач МП, побудова БД і ПЗ системи.

Розглянемо ці види проектування більш докладно. При концептуальному проектуванні визначаються:

–джерела надходження даних від замовника, що несе відповідальність за їхню достовірність;

–об’єкти системи та їхні атрибути;

–способи подання зв’язків між об’єктами і види організації даних;

–цілі і функції системи й інтерфейси з її користувачами;

–методи взаємодії користувачів із системою.

Організація інтерфейсів зв’язана з конкретними формами екранів і форматами обміну даними, а також з визначенням:

1)термінів і понять, що мають значення для користувача і самої системи;

2)моделі системи, що відбиває функції і ролі, подання даних і форми видачі результатів;

3)візуальних прийомів відображення на екрані результатів роботи у наочній і звичній для користувачів формах;

4)методів взаємодії підсистем.

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

параметрів, настроювання сервісів на нові умови середовища й адаптації використовуваних БД.

Особливості об’єктного підходу. Проектування системи може здійснюватися на основі об‘єктно-орієнтованого моделювання ПрО методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо [17].

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

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

Загальна концепція об’єктного проектування — це побудова всіх сценаріїв, екранних діаграм для керування ними і їх випробування в різних варіантах використання. На вибір варіантів використання впливають нефункціональні вимоги (наприклад, забезпечення конфіденційності, швидкодії й ін.).

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

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

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

4.2.2. Проектування різних видів архітектур програмних систем

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

Перший рівень – системні компоненти. Вони здійснюють взаємодію з периферійними пристроями комп’ютерів (принтери, клавіатура, сканери, маніпулятори і т.п.), використовуються при побудові операційних систем.

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

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

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

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

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

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

Архітектурна схема може бути: розподілена, клієнт-серверна і багаторівнева. Розподілена схема реалізує взаємодію компонентів системи, розташованих на різних комп’ютерах через стандартні протоколи виклику віддалених методів RPC (Remote Procedure Calls), RMI (Remote Method Invocation), що представлені в проміжних середовищах (COM/DCOM, CORBA) [15, 16]. Взаємодіючі компоненти можуть бути неоднорідними, створеними на різних мовах програмування (С, С++, Паскаль, Java, Basic, Smalltalk і ін.), що допускається в проміжному середовищі,

наприклад, CORBA (рис. 4.7).

Рис. 4.7. Зв’язок між мовами L1, L2, …, Ln через інтерфейси CORBA

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

Інтерфейси між мовами Li , Ln містять у собі опис:

–зв'язків двох об’єктів у цих мовах, що здійснюються через stub (стаб, заглушку) і skeleton (каркас) у мові IDL;

–атрибутів викликів в stub і skeleton, що відображаються в операції, а операції – в методи.

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

ісерверів.

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

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

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

Ця архітектура заснована на концепції розподілених об’єктів, які інкапсулюють ресурс і надають послуги іншим об’єктам. Об’єкти, що надають послуги, можуть самі користуватися послугами інших об’єктів, і як результат створюється багаторівнева архітектура.

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

Як метод проектування архітектури об’єктно-орієнтованих програмних систем застосовується UML [17, 18]. Зв’язки між об’єктами сервера і клієнта задаються діаграмами взаємодії або послідовності. Схема процесу розроблення в UML з використанням stub і skeleton, семантику яких розглянуто вище, наведена на рис. 4.8.

Діаграми станів задають обмеження на операції об’єктів сервера, визначаючи способи виклику операцій і поведінку об’єктів. Сутність стилю проектування в рамках уніфікованого процесу RUP [19] полягає в описі усіх видів діяльності, виконуваних на моделях (аналізу, проектування, розробки і тестування) процесу ЖЦ.

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

зв’язки й інтерфейси між ними. У ній відображаються структура виділених підсистем, довідників, словників, а також результати всіх процесів.

Рис. 4.8. Процес розроблення інтерфейсних об’єктів з UML

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

1)кожна підсистема повинна відображати вимоги і спосіб їхньої реалізації (сценарій або прецедент);

2)змінювані функції виділяються в підсистемі так, щоб для них прогнозувалися зміни вимог і окремі об’єкти, зв’язані з актором;

3)зв’язок об’єктів здійснюється через інтерфейс;

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

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

Виділені в моделі аналізу об’єкти поєднуються в систему шляхом:

– логічного об’єднання і збирання об’єктів;

– комунікативного об’єднання об’єктів через загальне джерело даних;

– процедурного об’єднання за допомогою операторів виклику;

– функціонального об’єднання об’єктів.

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

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

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

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

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

Висновки. Проведено аналіз різних методів проектування моделей предметних областей. Значна увага приділена методу Шлеєра і Мелора, в якому визначено три види моделей і підхід до побудови на їхній основі архітектури програмних систем. Розглянуто методи проектування систем з використанням об’єктних і стандартних структур програмних систем.

Контрольні питання і завдання

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.

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.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 базується на наступних концепціях:

– графічне зображення структури з поданням функцій блоками, а інтерфейсів дугами, що, відповідно, входять у блок і виходять з нього (рис.5.1);

Рис. 5.1. Структура моделі

–блоків може бути від 3 до 6 на кожному рівні декомпозиції;

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

йвиконання функцій;

–унікальність позначок і найменувань;

–незалежність функціональної моделі від організаційної структури колективу розробників.

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

Результат проектування в методі SADT – модель, що складається з діаграм, фрагментів текстів і глосарію з посиланнями один на одного. Всі функції й інтерфейси зображаються діаграмами у вигляді блоків і дуг. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керуюча інформація позначається дугою, яка входить у блок зверху, у той час як інформація, що піддається обробці, вказується з лівої сторони блоку, а результати виходу – з правої сторони. Механізм, що здійснює операцію (людина або автоматизована система), задається дугою, що входить у блок знизу.

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

Метод SSADM базується на таких структурах: послідовність, вибір й ітерація. Об’єкт моделювання задається відповідними структурними діаграмами, які відображають послідовність операторів, вибір елементів із групи й циклічне виконання операторів за цими елементами.

Загальна діаграма системи згідно з цим методом має ієрархічну структуру і містить у собі: список компонентів модельованого об'єкта; ідентифіковані групи вибраних і повторюваних компонентів; послідовність використовуваних компонентів.

Таке програмування передбачає наявність моделі ЖЦ із послідовними процесами розроблення програмного проекту, починаючи з аналізу і формування вимог для ПрО (рис. 5.2).

До процесів ЖЦ належать:

–стратегічне проектування та вивчення можливості виконання проекту;

–детальне дослідження предметної області, що містить у собі аналіз і специфікацію вимог;