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

У роботі представлено підхід до уточнення поведінкових моделей програмного забезпечення (ПЗ), які представляються діаграмами кооперацій. Уточнення поведінкових моделей ПЗ може бути як і окремою операцією Model-Driven Architecture (MDA) та Model-Driven Development (MDD) [1], так і складовою у вирішен...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2014
Автор:	Чебанюк, О.В.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2014
Назва видання:	Проблеми програмування
Теми:	Методи та засоби програмної інженерії
Онлайн доступ:	http://dspace.nbuv.gov.ua/handle/123456789/113222
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування / О.В. Чебанюк // Проблеми програмування. — 2014. — № 2-3. — С. 112-120. — Бібліогр.: 25 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-113222
record_format	dspace
spelling	irk-123456789-1132222017-02-05T03:03:28Z Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування Чебанюк, О.В. Методи та засоби програмної інженерії У роботі представлено підхід до уточнення поведінкових моделей програмного забезпечення (ПЗ), які представляються діаграмами кооперацій. Уточнення поведінкових моделей ПЗ може бути як і окремою операцією Model-Driven Architecture (MDA) та Model-Driven Development (MDD) [1], так і складовою у вирішенні завдань трансформації та верифікації моделей ПЗ [2]. Запропонований підхід базується на співставленні формалізованого опису процесів застосування з шаблонами, що представляють поведінкові складові паттернів проектування, та подальшого уточнення діаграм кооперацій відповідно до цих шаблонів. Поведінкові складові паттернів проектування містять формалізоване представлення функціональних вимог до застосування, які відповідають визначенному паттерну проектування. Сформовано поведінкові шаблони паттернів проектування «Міст» та «Стан», використовуючи які, спроектовано уточнені діаграми кооперацій. Систематизовано результати досліджень проблемного домену «Проектування розкрійних схем рулонних матеріалів деталей взуття та шкіргалантереї». Представлено специфікацію вимог до бібліотеки класів, що вирішує такі завдання цього проблемного домену, як побудова еквідістанти (образу деталі), укладок, розкладок, секцій та розкрійних схем. Продемонстровано приклад уточнення поведінкової моделі ПЗ для виконання завдання побудови щільних укладок розкрійних схем деталей взуття та шкіргалантереї із використанням формалізованого аналітичного представлення уточнених діаграм кооперацій. An approach to behavioral software models refinement is proposed in this paper. Behavioral software models are represented as UML collaboration diagrams. The operation of behavioral software models refinement can be both executed as a separate operation of Model-Driven Architecture (MDA) and Model-Driven Development (MDD) approaches and as a constituent of other technics which require software models transformation or verification [2]. The proposed approach is based on matching of applications’ formalized process description with behavioral constituents of design patterns. Behavioral constituents of design patterns contain formalized representation of application functional requirements that are corresponded with some design pattern. The behavioral design patterns constituents for patterns “Bridge” and “State” are formed. Using this constituents refinement collaboration diagrams are designed. The results of problem domain explorations “Designing of cutting schemas for shoe and leather good details” are systematized. The requirements specification to class library that solves such tasks of the problem domain as designing of convex hull (detail representation), layings, layouts, sections, and cutting schemas is presented. The example of behavioral software models elicitation for solving task of designing laying for shoe and leather good with using formalized analytical representation is represented. 2014 Article Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування / О.В. Чебанюк // Проблеми програмування. — 2014. — № 2-3. — С. 112-120. — Бібліогр.: 25 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/113222 004.415.2.045 (076.5) uk Проблеми програмування Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Методи та засоби програмної інженерії Методи та засоби програмної інженерії
spellingShingle	Методи та засоби програмної інженерії Методи та засоби програмної інженерії Чебанюк, О.В. Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування Проблеми програмування
description	У роботі представлено підхід до уточнення поведінкових моделей програмного забезпечення (ПЗ), які представляються діаграмами кооперацій. Уточнення поведінкових моделей ПЗ може бути як і окремою операцією Model-Driven Architecture (MDA) та Model-Driven Development (MDD) [1], так і складовою у вирішенні завдань трансформації та верифікації моделей ПЗ [2]. Запропонований підхід базується на співставленні формалізованого опису процесів застосування з шаблонами, що представляють поведінкові складові паттернів проектування, та подальшого уточнення діаграм кооперацій відповідно до цих шаблонів. Поведінкові складові паттернів проектування містять формалізоване представлення функціональних вимог до застосування, які відповідають визначенному паттерну проектування. Сформовано поведінкові шаблони паттернів проектування «Міст» та «Стан», використовуючи які, спроектовано уточнені діаграми кооперацій. Систематизовано результати досліджень проблемного домену «Проектування розкрійних схем рулонних матеріалів деталей взуття та шкіргалантереї». Представлено специфікацію вимог до бібліотеки класів, що вирішує такі завдання цього проблемного домену, як побудова еквідістанти (образу деталі), укладок, розкладок, секцій та розкрійних схем. Продемонстровано приклад уточнення поведінкової моделі ПЗ для виконання завдання побудови щільних укладок розкрійних схем деталей взуття та шкіргалантереї із використанням формалізованого аналітичного представлення уточнених діаграм кооперацій.
format	Article
author	Чебанюк, О.В.
author_facet	Чебанюк, О.В.
author_sort	Чебанюк, О.В.
title	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
title_short	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
title_full	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
title_fullStr	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
title_full_unstemmed	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
title_sort	підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування
publisher	Інститут програмних систем НАН України
publishDate	2014
topic_facet	Методи та засоби програмної інженерії
url	http://dspace.nbuv.gov.ua/handle/123456789/113222
citation_txt	Підхід до уточнення поведінкових моделей програмного забезпечення з використанням паттернів проектування / О.В. Чебанюк // Проблеми програмування. — 2014. — № 2-3. — С. 112-120. — Бібліогр.: 25 назв. — укр.
series	Проблеми програмування
work_keys_str_mv	AT čebanûkov pídhíddoutočnennâpovedínkovihmodelejprogramnogozabezpečennâzvikoristannâmpatternívproektuvannâ
first_indexed	2025-07-08T05:23:43Z
last_indexed	2025-07-08T05:23:43Z
_version_	1837055056008970240
fulltext	Методи та засоби програмної інженерії © О.В. Чебанюк, 2014 112 ISSN 1727-4907. Проблеми програмування. 2014. № 2–3. Спеціальний випуск УДК 004.415.2.045 (076.5) ПІДХІД ДО УТОЧНЕННЯ ПОВЕДІНКОВИХ МОДЕЛЕЙ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ З ВИКОРИСТАННЯМ ПАТТЕРНІВ ПРОЕКТУВАННЯ О.В. Чебанюк Національний авіаційний університет, 03058, Київ, проспект космонавта Комарова 1, Тел.: 044-406-76-41, E-mail: chebanyuk.elena@gmail.com У роботі представлено підхід до уточнення поведінкових моделей програмного забезпечення (ПЗ), які представляються ді- аграмами кооперацій. Уточнення поведінкових моделей ПЗ може бути як і окремою операцією Model-Driven Architecture (MDA) та Model-Driven Development (MDD) [1], так і складовою у вирішенні завдань трансформації та верифікації моделей ПЗ [2]. Запропонований підхід базується на співставленні формалізованого опису процесів застосування з шаблонами, що представляють поведінкові складові паттернів проектування, та подальшого уточнення діаграм кооперацій відповідно до цих шаблонів. Поведінкові складові паттернів проектування містять формалізоване представлення функціональних вимог до засто- сування, які відповідають визначенному паттерну проектування. Сформовано поведінкові шаблони паттернів проектування «Міст» та «Стан», використовуючи які, спроектовано уточ- нені діаграми кооперацій. Систематизовано результати досліджень проблемного домену «Проектування розкрійних схем рулонних матеріалів де- талей взуття та шкіргалантереї». Представлено специфікацію вимог до бібліотеки класів, що вирішує такі завдання цього про- блемного домену, як побудова еквідістанти (образу деталі), укладок, розкладок, секцій та розкрійних схем. Продемонстровано приклад уточнення поведінкової моделі ПЗ для виконання завдання побудови щільних укладок роз- крійних схем деталей взуття та шкіргалантереї із використанням формалізованого аналітичного представлення уточнених діаг- рам кооперацій. An approach to behavioral software models refinement is proposed in this paper. Behavioral software models are represented as UML collaboration diagrams. The operation of behavioral software models refinement can be both executed as a separate operation of Model-Driven Architecture (MDA) and Model-Driven Development (MDD) approaches and as a constituent of other technics which require software models transformation or verification [2]. The proposed approach is based on matching of applications’ formalized process descr iption with behavioral constituents of design patterns. Behavioral constituents of design patterns contain formalized representation of application functional requirements that are corresponded with some design pattern. The behavioral design patterns constituents for patterns “Bridge” and “State” are formed. Using this constituents refinement collaboration diagrams are designed. The results of problem domain explorations “Designing of cutting schemas for shoe and leather good details” are systematized. The requirements specification to class library that solves such tasks of the problem domain as designing of convex hull (detail representation), layings, layouts, sections, and cutting schemas is presented. The example of behavioral software models elicitation for solving task of designing laying for shoe and leather good with using formalized analytical representation is represented. Актуальність У життєвих циклів розробки ПЗ, які характеризуються послідовним перебігом процесів (RUP та водо- спад) процедури виправлення помилок та зміни архітектурних рішень після остаточного визначення вимог до ПЗ є такими, що вимагають багато часу та коштів. Тому більшого поширення набувають інкреметно-ітеративні підходи розробки ПЗ [3]. У таких підхо- дах весь час розробки ділиться на ітерації (тривалість ітерації зазвичай два тижні) та функціональність ПЗ нарощується поступово при виконанні завдань ітерації. Прикладами інкрементно-ітеративних підходів роз- робки ПЗ є життєві цикли сімейства Agile [3]. Характерною рисою розробки ПЗ відповідно до методології Agile є можливість змінювати або уточ- нювати вимоги до ПЗ та артефакти програмної розробки на кожній ітерації. Під артефактами програмної розробки [4] розуміють будь-яку річ, яка має відношення до розробки ПЗ. Прикладами артефактів є: докуме- нтація, архітектурні рішення, сценарії тестування, специфікація вимог тощо. За умови частої зміни вимог до ПЗ артефакти програмної розробки зручно замінювати моделями про- грамного забезпечення. Більшість моделей, які використовуються у процесі розробки програмного забезпечення, можуть бути поділені на статичні та динамічні (поведінкові). Класифікацію моделей ПЗ представлено у роботах [2, 5]. Статичні моделі ПЗ відображають його структуру, а саме: об’єкти, взаємозв’язки між ними, атрибути та операції. До таких моделей ПЗ належать UML діаграми класів, компонентів та пакетів [5]. Динамічні або поведінкові моделі ПЗ відображають поведінку програмних систем показуючи змін ста- нів об’єктів, їх взаємодію, процеси та потоки даних. До таких моделей ПЗ належать UML діаграми коопера- цій, послідовностей, діяльності та станів [5]. Методи та засоби програмної інженерії 113 Зміна вимог до ПЗ спричиняє зміну поведінкових моделей ПЗ, які в свою чергу містять вихідну інфор- мацію для проектування та уточнення багатьох артефактів програмної розробки [1]. Складність отримати поведінкову модель ПЗ, яка відповідає вимогам доменної інженерії, а саме пов- нота, достовірність та непротирічність, обумовлює використання інкрементно-ітеративного підходу для про- ектування таких моделей ПЗ [2]. Зазвичай процедура отримання поведінкової моделі ПЗ відбувається у два етапи. Перший – отримання приблизної моделі при аналізі функціональних вимог. Наступний - подальше уточнення моделей ПЗ. Використання запропонованого підходу, який дозволяє отримати якісні поведінкові моделі ПЗ, дозво- лить більш ефективно вирішувати наступні завдання:  синхронізувати зміни поведінкових моделей з іншими артефактами програмної розробки;  уточнювати поведінкові моделі при застосуванні методів трансформації моделей ПЗ як з моделей верхніх рівнів (СІМ моделі) [1] у моделі середнього рівня (РІМ моделі) [1], так і навпаки;  проектувати MDE артефакти, які будуть застосовуватися для повторного використання (наприклад пр. доменному аналізі);  уточнювати вимоги до програмного забезпечення. Постановка задачі. Розробити підхід до уточнення поведінкових моделей ПЗ при зміні артефактів програмної розробки. Вимоги до результату поведінкові моделі, отримані відповідно до запропонованого підходу, по- винні мати мінімальну кількість об’єктів та зв’язків між ними і водночас відображати всю актуальну інфор- мацію про процеси ПЗ та задовольняти вимогам доменної інженерії. Об’єкт дослідження – процес уточнення поведінкових моделей ПЗ. Предмет дослідження – характеристики та властивості поведінкових моделей ПЗ. Огляд робіт Залучення технік та методів підходів MDA та MDЕ у процес розробки ПЗ є передумовою появи низки робіт, присвячених уточненню статичних та поведінкових моделей ПЗ. Операції уточнення моделей базують- ся на використані різного типу шаблонів, за якими проводиться модифікація UML діаграм. У роботі [7] пред- ставлено класифікацію паттернів проектування та запропоновано механізм їх використання для уточнення структури діаграм класів. Для цього сформовані правила, які дозволяють визначити підмножину зі всіх скла- дових діаграм класів, які підлягають уточненню при виконанні певної операції уточнення. У роботі також запропоновано метрики, що дозволяють оцінити ефективність результатів уточнення моделей. У роботі [8] представлено метод, який дозволяє оцінити ефективність перетворень діаграм класів на різних ітераціях роз- робки ПЗ. Цей метод може використовуватися при веденні історії ітерацій розробки ПЗ та оцінки ефективно- сті повторного використання архітектурних рішень. Запропонований підхід базується на використанні мови Notation Business Process (BPMN) для моделювання бізнес-процесів при уточненні вимог до ПЗ. Визначено характеристики якості вимог до ПЗ, здійснена їх порівняльна оцінка. Визначено оцінку впливу кожного кри- терію на якість вимоги у цілому. Для візуалізації вимог та процесів теж використовується BPMN. Представлена робота є продовженням робіт [9–12]. У роботі [10] було представлено метамову опису процесів проблемного домену. За допомогою метамови представляється формалізований опис вимог до про- грамного забезпечення та поведінкових складових паттернів проектування. У роботі [11] запропоновано ал- гебру опису статичних моделей ПЗ. За допомогою алгебри опису статичних моделей ПЗ визначено функціо- нальність об’єктів діаграм кооперацій. У роботах [9, 12] досліджено процеси проблемного домену «Проекту- вання розкрійних схем рулонних матеріалів» та спроектовано поведінкові моделі процесів, що представля- ються діаграмами кооперацій. Обґрунтування вибору засобів уточнення поведінкових моделей ПЗ Паттерни проектування містять одночасно опис функціональних вимог до ПЗ та архітектурних рішень [7]. Визначимо складові паттернів проектування, що дозволяють описати архітектурні рішення як статичні. Відповідно, складові паттернів проектування, що характеризують функціональні вимоги до програмного забезпечення та бізнес процеси, визначимо як динамічні. Відповідно, при використанні інкрементно-ітеративних життєвих циклів розробки ПЗ, залучення тех- нік та методів співставлення функціональних вимог паттернам проектування у процес розробки ПЗ, дозволяє пов’язати функціональні вимоги з фрагментами поведінкових моделей ПЗ, уточнити відповідні поведінкові моделі ПЗ. Проектування та уточнення поведінкової моделі ПЗ відбувається у два етапи. Перший етап – створен- ня поведінкової моделі у першому наближенні із використанням сценаріїв виконання процесів відповідно до специфікації вимог. Поведінкова модель представляється діаграмою кооперацій. Далі виконується формаль- ний опис процесів, які зазначені у специфікації. Для формального опису процесів ПЗ та збереження інформа- ції про них використаємо метамову опису процесів проблемного домену, яка представлена у роботі [10]. Методи та засоби програмної інженерії 114 Наступний етап – уточнення поведінкової моделі ПЗ відповідно до шаблонів діаграм кооперацій, що відповідають паттернам проектування. Формальний опис процесів ПЗ співставляється з поведінковими скла- довими паттернів проектування (рис. 1). Якщо формальний опис процесу ПЗ відповідає динамічній складовій певного паттерну проектування, то відповідна поведінкова модель уточнюється з використанням шаблону діаграми кооперацій, що відповідає цьому паттерну. Схематично процес уточнення поведінкових моделей ПЗ показано на рис. 1. Поведінкова модель програмного забезпечення Формальне представлення процесів програмного забезпечення Уточнена поведінкова модель програмного забезпечення Специ- фікація вимог Метамова представлення процесів проблемного домену поведінкові складові паттернів проектування Рис. 1. Схема уточнення поведінкових моделей ПЗ із використання паттернів проектування. Визначимо етапи уточнення поведінкових моделей ПЗ відповідно до запропонованого підходу. 1. Проектується поведінкова модель програмного забезпечення, яка представляється діаграмою коопера- цій із використанням специфікації вимог. 2. Виконується опис процесів ПЗ, які представлено у цій поведінковій моделі у термінах метамови пред- ставлення процесів проблемного домену. 3. Співставляються динамічні складові паттернів проектування та формальний опис процесів ПЗ. 4. Коригується як формальний опис процесів ПЗ, так і поведінкова модель, що відображає ці процеси. Для ефективної реалізації такого підходу уточнення моделей потрібно підготувати наступну вихідну ін- формацію:  визначити ознаки, які дозволять співставити функціональні вимоги до ПЗ з певним паттерном проектування;  сформувати динамічні компоненти паттернів проектування, представивши їх у термінах мета- мови опису процесів проблемного домену;  визначити шаблони модифікованих фрагментів діаграм кооперацій для кожного паттерну про- ектування, які зберігають всю вихідну інформацію про процеси проблемного домену. Формування опису поведінкових складових паттернів проектування та шаблонів уточ- нених діаграм кооперацій Проілюструємо процес підготовки такої інформації для поведінкових паттернів проектування «Міст» та «Стан». Розглянемо паттерн проектування «Міст». Визначимо ознаки того, що потрібно використовувати паттерн проектування «Міст» при описі вимог у специфікації. Є декілька об’єктів (об’єкти 1o та 2o на рис. 1), які мають як спільну, так і відмінну функціональність. Ці об’єкти виконують певні завдання, використовуючи алгоритми, які мають як спільні так, і відмінні етапи. Для виконання цих завдань об’єкти 1o та 2o можуть використовувати як різні алгоритми (функціональність алгори- тмів закладена у об’єктах 1lga та 2lga рис. 1), так і інші об’єкти діаграми кооперацій (об’єкти 1ob та 2ob на рис. 1). Порядок виконання цих завдань і їх кількість може змінюватися. Такі функціональні вимоги відповіда- ють діаграмі кооперацій на рис. 2. Діаграма кооперацій ілюструє три можливі сценарії виконання процесів. Методи та засоби програмної інженерії 115 Послідовність операцій 1, 2, 3 та 4 відповідає сценарію, коли певний об’єкт використовує певний алго- ритм (об’єкт alg) та інший об’єкт, а саме 1ob для виконання визначеної задачі. Послідовність операцій 5, 6, 7 та 8 відповідає сценарію, коли певний об’єкт використовує властивості та методи різних об’єктів для виконання певної задачі. 9 o2 ob2 ob1o1 alg 1 3 4 5 6 7 alg 10 Рис. 2. Фрагмент діаграми кооперації, що відповідає паттерну проектування «Міст» Послідовність операцій 9 та 10 відповідає сценарію, коли певний об’єкт використовує деякий алгоритм для виконання визначеної задачі. Для формулювання динамічних компонентів паттерну проектування «Міст» визначимо наступні колекції об’єктів: О – колекція об’єктів, які виконують певні дії за допомогою як різних алгоритмів, так і інших об’єктів; lga – колекція об’єктів, функціональність яких дозволяє реалізувати алгоритми виконання цих дій; Ob – коле- кція об’єктів, функціональність яких потрібна для вирішення задач об’єктів, що є елементами колекції О.                      ,},...,{ ])lg[())(())(( ])[()())(( ... }...{ ])lg[())(())(( ])lg[()())(( ][][ 1 ][ 0 ]lg[]lg[ 1 ]lg[ 01 11 111 iOb n iObiOb t t ref t ttt ja n jaja ref mmmH iaFOOFOOF HkObrefOOOOcon mmmH jaFOOFOOF HjarefOOOOcon (1) Наведемо пояснення щодо динамічних складових паттерну проектування «Міст» (1). Розглянемо два елементи колекції О, які позначимо як iO та jO . Так як міст дозволяє змінювати як абстракцію, так і реаліза- цію, то відповідно до першого (другого) сценарію створюється об’єкт iO ( jO ) з посиланням на об’єкт, який інкапсулює собою певний алгоритм з колекції lga або об’єкт з колекції Ob (1). Позначимо алгоритм з колекції lga , як ]lg[ ja , а об’єкт з колекції Ob , як ][kOb . Відповідно до нотації метамови процес створення об’єкта iO з посиланням на об’єкт ]lg[ ja запишеться наступним чином: ])lg[()())(( jarefOOOOcon ii  . Відповідно, функціональність об’єкта iO розширюється на функціональність об’єкта ]lg[ ja . У нотації алгебри опису статичних моделей ПЗ це запишеться наступним чином: ])lg[())(())(( 11 jaFOOFOOF ref  . Далі об’єкт iO виконує набір операцій за допомогою викликів певних методів об’єкта ]lg[ ja . Так, як послідовність операцій має значення, то використовується позначення метамови H . Приклад 1H }...{ ]lg[]lg[ 1 ]lg[ 0 10 tja n jaja mmm  ілюструє, що для виконання операцій з послідовності 1H викликаються методи nim ja i ,...,1,]lg[  , ( n – кількість методів у ланцюжку 1H ) об’єкта ]lg[ ja у певній послідовності. Методи та засоби програмної інженерії 116 Аналогічні міркування приводяться для пояснення другого сценарію паттерну проектування «Міст» з викорис- танням об’єкта, що є елементом колекції Ob . Підготуємо шаблон модифікованої діаграми кооперацій для паттерну проектування «Міст». Після аналізу виразу (1) та діаграми на рис. 2 формуємо уточнену діаграму кооперацій, що відповідає функціональним вимогам паттерну «Міст». Наведемо рекомендації за співставленням функціональних вимог, складовим діаграми кооперацій на рис. 3. ][ia – один об’єкт із колекції об’єктів O . Він виконує певні операції за допомогою або різних алгорит- мів ( lga – колекція таких алгоритмів), або використовуючи інші об’єкти ( Ob – колекція таких об’єктів). * 1 :o a[i]:o :alg :ob 1 2 Рис. 3. Уточнена діаграма кооперацій, що відповідає паттерну проектування «Міст» Для проектування такої діаграми кооперації під час аналізу функціональних вимог необхідно визначити які сутності проблемного домену, відповідають колекціям об’єктів O , Ob та lga . Визначимо функціональні ознаки паттерну проектування «Стан». Об’єкт ( 1Ob на рис. 3) може виконува- ти визначені дії за умови знаходження його у певному стані (на рис. 4 перша умова – 1cond , друга умова – 2cond і .т. д.). При переході об’єкта із стану у стан можуть виконуватися певні дії ( 1action – перша дія, 2action – друга дія і т. п.), для виконання яких задіяна функціональність певних об’єктів. Фрагмент діаграми коопера- цій, який представляє такі функціональні вимоги показано на рис. 4. Ob1 action1[cond1] action2 [cond2] . . . . [cond2] actionN 1 2 N Рис. 4. Фрагмент діаграми кооперацій, що відповідає паттерну проектування «Стан» Отже сформуємо формальний опис процесів, який відповідає паттерну проектування «Стан».       .,...,1,,},,...,,{ ,))(( 10 1 nkjimmm OObcon kji action t actionaction (2) Наведемо пояснення виразу (2). Створюється об’єкт 1Ob , який може виконувати різні операції, перебу- ваючи у різних станах. Процес виконання різних операцій характеризується викликом різних методів з колекції action. Так як порядок виконання операцій довільний то використовується позначення Ф метамови. Після аналі- зу виразу (2) та діаграми на рис. 3. формуємо уточнену діаграму кооперацій, що відповідає функціональним вимогам паттерну проектування «Стан». Методи та засоби програмної інженерії 117 Пояснимо діаграму на рис. 5. Для кожного елемента ][ia , з колекції action визначимо, які дії буде вико- нувати об’єкт 1Ob , перебуваючи у певному стані, та умови ( ][icond ), при яких відбувається зміна стану об’єкта (повідомлення changeState() на рис. 4). Кількість станів об’єкта визначає кількість елементів у колекції action. * 1 :action a[i]:action 1 changeState() 2 ReplaceElement() [cond[i]=true] :Ob1 2.1 DoTask() Рис. 5. Уточнена діаграма кооперацій, що відповідає паттерну проектування «Стан» Використання запропонованого підходу для уточнення поведінкових моделей ПЗ Представимо приклад використання запропонованого підходу для уточнення поведінкових моделей ПЗ проблемного домену «Проектування розкрійних схем для деталей взуття та шкіргалантереї», які представлені діаграмами кооперацій. 1. Проектування поведінкової моделі ПЗ та специфікації вимог. Скористуємося поведінковими моделями ПЗ, що представлені у роботах [11, 12]. Представимо специфікацію вимог для проблемного домену «Побудова розкрійних схем рулонних мате- ріалів деталей взуття та шкіргалантереї» із зазначенням посилань на роботи, де проаналізовано процеси про- блемного домену (таблиця). Таблиця. Специфікація вимог для проектування бібліотеки класів проблемного домену «побудова розкрійних схем рулонних матеріалів» Код функціона- льної вимоги Опис функціональної вимоги 1 2 F1 Зчитування інформації про деталь із *.dgt формату та формування образу деталі [13] F1.1 Формування інформації про групову деталь шляхом об’єднання контурів декількох дета- лей [14] F2 Нанесення декоративних елементів на деталь [14] F 2.1 Збереження інформації про ключові характеристики декоративних елементів, нанесених на деталь [14] F 2.2 Розробка формату файлів для збереження інформації про розкрійні схеми з нанесенеми на деталі декоративними елементами [15] F 2.3 Розробка формату файлу, що дозволяє збереження інформації про координати зовнішніх контурів декоративних елементів [15] F 3 Проектування щільних укладок деталей взуття та шкіргалантереї [11, 16, 17, 18, 19, 20] F 3.1 Проектування щільних укладок для однотипних деталей [17, 18] F 3.1.1. Визначення векторів одинарної решітки [17, 18] F 3.2 Проектування щільних укладок для двох різних типів деталей [18, 19] 1 2 F 3.2.1 Визначення векторів подвійної решітки [18] F 3.2.2 Побудова годографа вектор-функції щільного розміщення для подвійних укладок [18] F 3.3 Проектування щільних укладок для групових деталей [21] F 3.3.1 Об’єднання деталей у групову деталь [21] F 3.3.2 Побудова годографа вектор-функції щільного розміщення для укладок групових деталей [21] F 3.4 Визначення лінійних ефектів для укладок деталей шкіргалантереї [11, 13, 20] Методи та засоби програмної інженерії 118 Завершення таблиці 1 2 F4 Проектування розкладок [13, 22, 23, 24] F 4.1 Задача „Розкладка А” Знайти таке системне розміщення двох многокутників, що мають довільну конфігурацію зовнішніх контурів на матеріалі прямокутної форми з їх змінною орієнтацією в заданих межах, яке забезпечує максимальне значення показника викорис- тання матеріалу із врахуванням інших технологічних умов та обмежень [23] F 4.2. Задача „Розкладка В” Знайти таке системне розміщення двох многокутників, що мають довільну конфігурацію зовнішніх контурів на матеріалі прямокутної форми без обмежень на їх орієнтацію на матеріалі, яке забезпечує максимальне значення показника викорис- тання матеріалу із врахуванням інших технологічних умов та обмежень [23] F 4.3. Поворот решіток при проектуванні розкладок [24] F5 Проектування секцій [24]. Постановка задачі: знайти таке системне розміщення деталей взуття на матеріалі прямо- кутної форми із шириною Sh для фіксованої орієнтації деталей, яке забезпечує максима- льне значення показника використання матеріалу із врахуванням потреби в деталях та те- хнологічних умов та обмежень F 5.1 Щільне суміщення секцій [23] F 5.2 Пошук оптимальної перестановки секцій [23] F6 Розрахунок траєкторії різального апарату при розкрої струменем води або лазера [25] Для більш детального дослідження процесів використовуються математичні та технологічні постановки задач укладка, розкладка та секція, які представлені у роботах [20, 23, 24]. 2. Використовуючи цю поведінкову модель ПЗ та специфікацію вимог виконується опис процесів ПЗ у термінах метамови представлення процесів проблемного домену. Представимо опис процесів які виконуються при проектуванні щільних укладок, у термінах метамови опису процесів. 2.1. Формальний опис процесів побудови щільних укладок деталей взуття охоплює вимоги специфікації F 3.1, F3.2, F3.3 [13, 22–24]. Розглянемо класи, які використовуються для побудови щільних укладок, а саме: деталь (клас )(DetailC ), об’єднана деталь або груповий об’єкт( клас )_( DetailjoinC ), ГВФЩР (клас 1)(GodographC ), решітка (клас )(GridC ) та укладка (клас )(LayingC ). Функціональність всіх класів крім класу годограф розглянута у роботах [9, 12]. Клас 1)(GodographC відповідає за побудову годографа вектор функції щільного розміщення (ГВФЩР) для однотипних деталей, клас 2)(GodographC відповідно за побудову різнотипних, клас )_( DetailjoinC опи- сує функціональність об’єкта, що представляє об’єднану деталь [21]. Використовуючи спефицікацію вимог розглянемо завдання, які потрібно виконати для побудови щільних укладок відповідно до специфікації вимог (таблиця). 2.1.1. Проектування щільних укладок для однотипних деталей [17, 18]. 2.1.1.1. Визначення векторів одинарної та подвійної решіток. Вектори решітки для укладок будуються за допомогою ГВФЩР шляхом аналізу взаємного розташування деталей [18]. У термінах метамови клас решітка, а саме: )(GridC , використовує функціональність класу годог- раф. Одинарні решітки будуються для одного типу деталей, використовуючи об’єкти класу 1)(DetailC . У тер- мінах нотації метамови опису процесів проблемного домену операції створення різних типів об’єктів ГВФЩР запишемо наступним чином: ))(()())(( 111 ODetailrefOGodographGodographCcon  для одинарних решіток та ))(),(()())(( 2122 ODetailODetailrefOGodographGodographCcon  для подвійних. Для побудови решітки об’єкт класу решітка створюється із посиланням на об’єкт класу годограф. Отже функціональність класу )(GridC розширюється на функціональність класу, що містить алгоритм побудови ГВФЩР різних типів. У нотації алгебри опису статичних моделей ПЗ це запишеться наступним чином: ))(())(())(( 1 OGodographFOGridFGridCF ref  або ))(())(())(( 2 OGodographFOGridFGridCF ref  . Укладки будуються на векторах решітки. Різні укладки використовують решітки та деталі різних типів. Відповідно при створенні класу укладка ( )(LayingC ) використовуються посилання на об’єкт класу решітка та деталі різних типів, які входять до цієї укладки. Так як посилання на об’єкти класів деталей вже є у класі решіт- ка, то процедура створення об’єкта класу «Укладка» запишеться наступним чином: Методи та засоби програмної інженерії 119 ))(()())(( OGridrefOLayingLayingCcon  . Відповідно для побудови різних типів укладок використовуються різні алгоритми, які мають як спільні так і відмінні етапи. Позначимо послідовність дій, які виконуються для побудови щільних укладок одного типу деталей як 1 GridH , двох типів деталей 2 GridH . Дії, що виконуються при побудові обох типів укладок представ- лено у роботі [18]. Операція генерації множини допустимих решіток GridbestH _ однакова для всіх типів укладок [18]. Вона описана у роботах [11, 18]. Розглянемо клас груповий об’єкт. Так як груповий об’єкт представляє собою об’єднання декількох дета- лей, то при створенні цього класу використовуються об’єкти класів 1)(DetailC , 2)(DetailC та 3)(DetailC . Реш- та операцій, що дозволяють побудувати щільну укладку для групового об’єкта збігається з послідовністю опе- рацій 2H . Використовуючи (1) та нотацію метамови і алгебру опису статичних моделей ПЗ представимо формаль- ний опис процесів ПЗ: )3( })()({ ))(())(())(( ))(()())(()( ))(),(),(()(_))_(( )())(( })()()2()()1({ ))(()())(( ))(())(())(( ))(()())(( ))(),(()())(( )())(( })()2()()1({ ))(())(())(( ))(()())(( ))(()())(( )())(( ))(( 1 ))(( 0 _ _ 21 2321 33 432102 22 22 22 2122 22 32101 111 11 111 11                                                  OLayingOLayingGridbest ref GridbestGridGrid Grid GridGridGridGridGridGrid Grid ref GridGridGridGridGrid Gridref addestimateH OGridFOLayingFLayingCF HOGridrefOLayingLayingCconHH HODetailODetailODetailrefODetailjoinDetailjoinCcon ODetailDetailCcon qbettaaalphaaH HOGodographrefOGridGridCcon OGodographFOGridFGridCF OGodographrefOGridGridCcon ODetailODetailrefOGodographGodographCcon ODetailDetailCcon bettaaalphaaH HOGodographFOGridFGridCF OGodographrefOGridGridCcon ODetailrefOGodographGodographCcon ODetailDetailCcon       3. Співставимо формальний опис процесів ПЗ з динамічними складовими паттернів проектування. Для побудови різних типів решіток використовуються різні алгоритми, які мають як відмінні та схожі ознаки. Від- повідно укладки будуються із використанням різних типів об’єктів (решітка для однотипних деталей, для двох різних типів деталей та групових деталей), а алгоритми побудови ГВФЩР для різних типів укладок також ма- ють як спільні, так і відмінні операції. Отже, функціональні вимоги до застосування, що будує щільні укладки, збігаються з ознаками паттерну проектування «Міст», а саме: використання об’єктів, що мають як спільні, так і відмінні властивості алгорит- мів, що виконують визначену задачу та мають певні спільні операції. Аналізуючи вирази (1) та (3) визначаємо об’єкти уточненої діаграми кооперацій, що співставляються з сутностями проблемного домену. O – об’єкт укладка. Для побудови укладок використовується як алгоритми, що мають, як спільні, так і відмінні етапи та інші об’єкти. lga – колекція алгоритмів, які використовуються при побудові щільних укладок різних типів, що міс- тять як спільні, так і відмінні етапи. Відповідно ]0lg[a – алгоритм побудови укладок для однотипних деталей, ]1lg[a – алгоритм побудови укладок для двох типів деталей, ]2lg[a – алгоритм побудови укладок для групових деталей. Ob – колекція об’єктів, які використовуються при побудові укладок. ]0[Ob – решітка для укладок, що складаються з деталей одного типу, ]1[Ob – відповідно двох та ]2[Ob – решітка для укладок, які містять групові об’єкти. Методи та засоби програмної інженерії 120 4. Уточнимо поведінкову модель ПЗ. Уточнена діаграма кооперації процесу побудови щільних укладок для двох типів деталей відповідає діаграмі, представленій на рис. 3. Кожен алгоритм з колекції alg цієї діаграми може бути представлений окремою поведінковою моделлю [24], яка ілюструє деталі реалізації. Висновки Огляд робіт, присвячених уточненню моделей, показує, що більшість методів уточнення моделей ПЗ спрямовано на дослідження та покращення характеристик статичних моделей ПЗ [1, 2, 7, 8]. Методи уточнення динамічних моделей ПЗ вимагають залучення таких засобів, як ВРМН або методів чи технік уточнення вимог і включають досить трудомісткі операції. Часто ефективне використання таких методів вимагає певної поперед- ньої або супровідної роботи (формування артефактів доменної інженерії або доменний аналіз, можливе аналіз бізнес процесів тощо). Такий підхід є не дуже ефективним у інкрементно-ітеративних життєвих циклах розроб- ки ПЗ, через те, що під час проведення трудомістких операцій вже можуть змінитися вимоги. На відміну від методу уточнення поведінкових моделей, який представлено у [8] підхід, запропонований у цій роботі, дозволяє уточнювати поведінкові моделі, зменшуючи трудомісткість операції їх уточнення. Так як у інкрементно-ітеративних життєвих циклах розробки ПЗ таку операцію потрібно проводити доволі часто, то як вихідну інформацію для уточнення поведінкових моделей ПЗ можливо використати або формальний опис проце- сів, або одразу співставити функціональні вимоги поведінковим складовим паттернів. У порівнянні із методами, що запропоновані у [2, 7] трудомісткість уточнення діаграм зменшується, а наперед визначені готові шаблони поведінкових діаграм дозволяють спростити процедуру візуалізації уточнених поведінкових моделей ПЗ. Також запропонований підхід може використовуватися, як етап методів MDA, які вирішують задачу пе- ретворення моделей. 1. Beatriz M., Pereira1 J., Giachetti G., Hermosilla F., Estefan S. A General Framework for the Development of MDD Projects // Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development Spain, Barselona. – 2013. – P. 258–264. 2. Stephan M., Cordy J. A Survey of Model Comparison Approaches and Applications // Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development. Spain, Barselona. – 2013. – P. 265–277. 3. Stavru S.,Krasteva I. And Ilieva S. Challenges of Model-Driven Modernization-An Agile Perspective // In Proceedings of the 1st international conference on model-Driven Engineering and Software Development. Spain, Barselona. – 2013, P. 219–230. 4. Tamlr Kllnger, Peri L. System and method for publication classification automatically determining relationships between software sources Patent Aug. 22, 2013. 5. Gupta S., Singla J. S A component-based approach for test case generation // International Journal of Information Technology 5.2 2012. – P. 239–243. 6. http://www.omg.org/mda/faq_mda.htm 7. Lano K. and Kolahdouz-Rahimi S. Optimising Model-transformations using Design Patterns. In Proceedings of the 1st International Conferenceon Model-Driven Engineering and Software Development. Spain, Barselona. – 2013. – P. 77–82. 8. Störrle H. Making Sense to Modelers-Presenting UML Class Model Differences in Prose // In Proceedings of the1st International conference on model-driven engineering and software development Spain, Barselona. – 2013. – P. 39–48. 9. Chebanyuk E. Algebra describing software static models // International journal Information technologies and knowledge. – 2013. – № 1. – Vol. 7. – P. 83–93. 10. Chebanyuk E. Metalanguage for description problem domain processes // Міжнародна конференція “Сучасна інформатика. Проблеми, досягнення та перспективи розвитку”.,11-13 вересня 2013. – К. Інcтитут програмних систем. – 2013. – С. 63–64. 11. Chebanyuk O.V., Сhuprinka V.I. One approach of constructing problem domain metamodel. Інженерія програмного забезпечення. – 2011. – № 4 (8). – С. 13–21. 12. Chebanyuk E. Method of domain models designing. International models and analysis. – 2014, N 1. –Vol. 3. 13. Чупринка В.І., Хоменко О.О., Свістунова Л.Т. Комплексний підхід до розв’язання задачі щільного розміщення об’єктів складної фор- ми на площині // Проблеми програмування. – 2010. – № 2-3. – С. 621–628. 14. Чупринка В.И., Чебанюк Е.В. Алгоритм сохранения информации о декоративных элементах на деталях обуви // Техническое регули- рование: базовая основа качества товаров и услуг: сб. науч. трудов. – Шахты (РФ): ЮРГУЄС, 2009. – С. 70–73. 15. Чебанюк О.В., Чупринка В.І. Математичне та програмне забезпечення побудови розкрійних схем з декоративними елементами // Вісник Східноукраїнського національного університету імені Володимира Даля. –2010. – № 9 (151). – С. 194–199. 16. Чупринка В.И., Чебанюк Е.В. Математическая модель оценки эффективности раскладок при построении раскройных схем рулонных материалов// Техническое регулирование: базовая основа качества товаров и услуг.: зб. науч. трудов – Шахти ЮРГУЄС, 2012. – С. 193–198. 17. Чупринка В.І.; Пінчук А.В.; Чебанюк О.В. Автоматизована підготовка інформації про схеми розкрою рулонних матеріалів на однакові плоскі геометричні об’єкти // Вісник Східноукраїнського національного університету імені Володимира Даля. –2008. – № 5(139). – С. 194–199. 18. Чебанюк О.В., Чупринка В.І. Методика автоматичної побу дови розкрійних схем для двох видів плоских геометричних об’єктів // Проблеми програмування. − 2008. – № 2–3. − С. 730−734. 19. Чупринка В.І., Чебанюк О.В. Метод програмного проектування найщільніших решітчастих укладок // Проблеми програмування. – 2010. – № 2–3. – С. 629–635. 20. Чупринка В.И., Мурженко В.С., Омельченко П.В. Автоматизированное проектирование схем раскроя при прямоугольно-гнездовом методе раскроя // Международный сборник научных трудов «Техническое регулирование: базовая основа качества товаров и услуг», – Шахты: ЮРГУЭС, 2013. – С. 70–72. 21. Чупринка В.І. Автоматизоване проектування раціональних схем розкрою рулонних матеріалів на деталі виробів шкіргалантереї// Інформаційна безпека. – 2011. – 7: 2. – С. 46–50. 22. Чупринка В.І., Чебанюк О.В. Алгоритм автоматичної підготовки вихідної інформації для побудови раціональних схем розкрою // Вісник Київського національного університету технологій та дизайну. – 2006. –№ 6(32). – С. 182–186. 23. Чупринка В.І., Чебанюк О.В. Метод автоматичного проектування раціональних схем розкрою на деталі взуття // Проблеми програму- вання. – 2012. – № 2–3. – С. 168–174. 24. Чупринка В.І., Чебанюк О.В. Доменний аналіз методів автоматичної побудови розкрійних схем зі змінним кутом повороту решіток // Вісник Східноукраїнського національного університету імені Володимира Даля. – 2012. – № 9(151). – С. 194–199. 25. Чупринка В.И., Чебанюк Е.В., Мурженко В.С. Оптимизация маршрута режущего інструмента при автоматическом раскрое материалов с помощью воды или луча лазера // Междунар. сб. науч. тр. Южно-Рос. гос. ун-та экономики и сервиса. – Шахты. Изд-во ЮРГУЄС, 2011. – С. 93−95. http://www.omg.org/mda/faq_mda.htm

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

Репозитарії

Схожі ресурси