Problems and tools of designing and estimation of viable program system

This work deals with problems and tools of designing and estimation of viable objectoriented program system (PS). The solution of mentioned problems based on describing PS model and changes tracing model to supply system requirement assurance. Suggested approach corresponds wits object-oriented PS a...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2015
Автори:	Ignatenko, P.P., Byistrov, V.M., Ignatenko, O.P., Tkachenko, V.M.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	PROBLEMS IN PROGRAMMING 2015
Теми:	UDC 681.3
Онлайн доступ:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/21
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Problems in programming
Завантажити файл:

Репозитарії

Problems in programming

id	pp_isofts_kiev_ua-article-21
record_format	ojs
resource_txt_mv	ppisoftskievua/a9/709bf3e0352b2a8c9e64df4dd0dffda9.pdf
spelling	pp_isofts_kiev_ua-article-212018-10-09T11:12:02Z Problems and tools of designing and estimation of viable program system Задачи и средства моделирования и оценивания жизнеспособных программных систем Задачі та засоби моделювання й оцінювання життєздатних програмних систем Ignatenko, P.P. Byistrov, V.M. Ignatenko, O.P. Tkachenko, V.M. UDC 681.3 УДК 681.3 УДК 681.3 This work deals with problems and tools of designing and estimation of viable objectoriented program system (PS). The solution of mentioned problems based on describing PS model and changes tracing model to supply system requirement assurance. Suggested approach corresponds wits object-oriented PS artefacts estimation based on analysis of project of system defined in term of UML diagrams. It is proposed to use metrics, oriented on design patterns and considered in scenario context, for estimation PS quality attributes. The direction of change of marked attributes is defined by projecting of relation between inner and outer PS attributes on PS architecture. Рассмотрены задачи и средства моделирования и оценивания жизнеспособных объектно-ориентированных программных систем (ПС). Проблема решается в рамках создания модели ПС и модели прослеживания изменений для обеспечения требований системы. Подход к оцениванию артефактов объектноориентированных ПС основан на анализе проекта системы, который специфицирован в виде диаграмм UML. Для оценки атрибутов качества ПС предлагается использовать метрики, ориентированные на шаблоны проектирования, рассматриваемые в контексте сценарного подхода. Связь между внутренними и внешними атрибутами ПС проектируется на архитектуру ПС и определяет направление преобразования. Розглянуті задачі та засоби моделювання й оцінювання життєздатних об’єктноорієнтованих програмних систем (ПС). Проблема вирішується в рамках створення моделі ПС і моделі простежування змін для забезпечення вимог до системи. Підхід до оцінювання артефактів об’єктно-орієнтованих ПС заснований на аналізі проекту системи, специфікованому у вигляді діаграм UML. Для оцінки атрибутів якості ПС пропонується використовувати метрики, які орієнтовані на шаблони проектування та розглядаються у контексті сценарного підходу. Зв’язок між внутрішніми та зовнішніми атрибутами ПС проектується на архітектуру ПС та визначає напрямок їх перетворень. PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2015-07-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/21 PROBLEMS IN PROGRAMMING; No 3 (2003) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 3 (2003) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 3 (2003) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/21/25 Copyright (c) 2015 ПРОБЛЕМИ ПРОГРАМУВАННЯ
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2018-10-09T11:12:02Z
collection	OJS
language	Ukrainian
topic	UDC 681.3
spellingShingle	UDC 681.3 Ignatenko, P.P. Byistrov, V.M. Ignatenko, O.P. Tkachenko, V.M. Problems and tools of designing and estimation of viable program system
topic_facet	UDC 681.3 УДК 681.3 УДК 681.3
format	Article
author	Ignatenko, P.P. Byistrov, V.M. Ignatenko, O.P. Tkachenko, V.M.
author_facet	Ignatenko, P.P. Byistrov, V.M. Ignatenko, O.P. Tkachenko, V.M.
author_sort	Ignatenko, P.P.
title	Problems and tools of designing and estimation of viable program system
title_short	Problems and tools of designing and estimation of viable program system
title_full	Problems and tools of designing and estimation of viable program system
title_fullStr	Problems and tools of designing and estimation of viable program system
title_full_unstemmed	Problems and tools of designing and estimation of viable program system
title_sort	problems and tools of designing and estimation of viable program system
title_alt	Задачи и средства моделирования и оценивания жизнеспособных программных систем Задачі та засоби моделювання й оцінювання життєздатних програмних систем
description	This work deals with problems and tools of designing and estimation of viable objectoriented program system (PS). The solution of mentioned problems based on describing PS model and changes tracing model to supply system requirement assurance. Suggested approach corresponds wits object-oriented PS artefacts estimation based on analysis of project of system defined in term of UML diagrams. It is proposed to use metrics, oriented on design patterns and considered in scenario context, for estimation PS quality attributes. The direction of change of marked attributes is defined by projecting of relation between inner and outer PS attributes on PS architecture.
publisher	PROBLEMS IN PROGRAMMING
publishDate	2015
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/21
work_keys_str_mv	AT ignatenkopp problemsandtoolsofdesigningandestimationofviableprogramsystem AT byistrovvm problemsandtoolsofdesigningandestimationofviableprogramsystem AT ignatenkoop problemsandtoolsofdesigningandestimationofviableprogramsystem AT tkachenkovm problemsandtoolsofdesigningandestimationofviableprogramsystem AT ignatenkopp zadačiisredstvamodelirovaniâiocenivaniâžiznesposobnyhprogrammnyhsistem AT byistrovvm zadačiisredstvamodelirovaniâiocenivaniâžiznesposobnyhprogrammnyhsistem AT ignatenkoop zadačiisredstvamodelirovaniâiocenivaniâžiznesposobnyhprogrammnyhsistem AT tkachenkovm zadačiisredstvamodelirovaniâiocenivaniâžiznesposobnyhprogrammnyhsistem AT ignatenkopp zadačítazasobimodelûvannâjocínûvannâžittêzdatnihprogramnihsistem AT byistrovvm zadačítazasobimodelûvannâjocínûvannâžittêzdatnihprogramnihsistem AT ignatenkoop zadačítazasobimodelûvannâjocínûvannâžittêzdatnihprogramnihsistem AT tkachenkovm zadačítazasobimodelûvannâjocínûvannâžittêzdatnihprogramnihsistem
first_indexed	2025-07-17T09:38:55Z
last_indexed	2025-07-17T09:38:55Z
_version_	1850409955432071168
fulltext	Методы и средства программной инженерии © П.П. Ігнатенко, В.М. Бистров, О.П. Ігнатенко, В.М. Ткаченко, 2003 ISSN 1727-4907. Проблемы программирования. 2003. № 3 59 УДК 681.3 П.П. Ігнатенко, В.М. Бистров, О.П. Ігнатенко, В.М. Ткаченко ЗАДАЧІ ТА ЗАСОБИ МОДЕЛЮВАННЯ Й ОЦІНЮВАННЯ ЖИТТЄЗДАТНИХ ПРОГРАМНИХ СИСТЕМ Розглянуті задачі та засоби моделювання й оцінювання життєздатних об’єктно- орієнтованих програмних систем (ПС). Проблема вирішується в рамках створення мо- делі ПС і моделі простежування змін для забезпечення вимог до системи. Підхід до оцінювання артефактів об’єктно-орієнтованих ПС заснований на аналізі проекту сис- теми, специфікованому у вигляді діаграм UML. Для оцінки атрибутів якості ПС пропо- нується використовувати метрики, які орієнтовані на шаблони проектування та роз- глядаються у контексті сценарного підходу. Зв’язок між внутрішніми та зовнішніми атрибутами ПС проектується на архітектуру ПС та визначає напрямок їх перетворень. У роботі [1] розглянуто підхід до створення життєздатних (viable) ПС, який базується на передбаченні можли- вих змін у системі залежно від її типу, на прогнозуванні наслідків змін, прий- нятті рішень щодо їх доцільності, ефек- тивності та оптимальності. Згідно цього підходу життєздатність ПС повинна за- безпечуватись спеціальними засобами, імплементованими в середовище роз- робки та функціонування ПС. На стадії супроводження ПС також виникає не- обхідність в адаптації, модифікації чи реінжинірингу ПС згідно виникаючих змін, а, отже, в отриманні нових оцінок атрибутів якості ПС, таких, як функціо- нальність, надійність, зручність вико- ристання, ефективність, супроводжу- ваність та переносність [2, 3]. Таким чином, в середовище розробки та су- проводження ПС повинні входити за- соби моделювання та оцінювання ПС, які б використовувались при внесенні змін до ПС або їх адаптації. У даній статті розглядаються питання розробки та застосування таких засобів для об’єктно-орієнтованих ПС. Однією з основних властивостей життєздатних програмних систем є їх здатність до адаптації, ефективних мо- дифікацій та реінжинірингу при зміні функціональних і нефункціональних вимог до ПС протягом життєвого цик- лу [1—3]. Така властивість відповідає, зокрема, наявності варіантів проектних рішень (варіантності ПС) та можливос- ті їх оцінювання на основі моделі ПС. Задачі, що відносяться до проблеми за- безпечення варіантності ПС, можуть розглядатись як у контексті передба- чення вимог до системи, з’ясування їх варіантності, специфікації та конкре- тизації [2], так і у контексті варіантно- сті артефактів, специфікації та конкре- тизації механізмів, що підтримують та- ку варіантність і забезпечують різні атрибути якості артефактів. У першому випадку задача стосується проблеми повторного використання та забезпе- чення адаптивних властивостей систем та більшою мірою відноситься до мак- ропроцесу розробки ПС, у другому – проблеми створення внутрішніх архі- тектурних та програмних релізів сис- теми із заданими властивостями і бі- льшою мірою відноситься до мікро- процесу розробки. Окрема задача по- лягає у забезпеченні можливості оцін- ки артефактів на основі аналізу проек- ту системи, який специфіковано відпо- відно до певних засобів моделювання. У даній статті розглядаються задачі мо- делювання, що виникають на рівні мік- ропроцесу розробки та стосуються за- безпечення варіантності артефактів та їх оцінювання. При цьому мікропроцес об’єктно-орієнтованої розробки розгля- дається як такий, що зумовлюється ар- тефактами та архітектурними продук- тами, що породжуються та послідовно уточнюються на рівні макропроцесу [4]. Як засіб моделювання ПС перед- бачається уніфікована мова моделю- вання (Unified Modeling Language, UML) [5], базована на діаграмах та призначена для моделювання систем на основі об’єктно-орієнтованого під- ходу. Загальні механізми мови UML – Методы и средства программной инженерии 60 прийняті розподіли (Common divisions), механізми розширення (Extensibility mechanisms) – підтримують варіант- ність артефактів і забезпечують мож- ливість керування їхніми версіями. UML також володіє засобами моделю- вання механізмів проектування систем з урахуванням представлень їхньої ар- хітектури [4, 6]. Відокремлення пред- ставлення архітектури з точки зору прецедентів (use case view) від інших видів та розгляд сценаріїв – екземпля- рів прецедентів (instances of use cases) як артефактів, що реалізують варіант- ність архітектури ПС, надає можливість моделювання варіантності ПС засобами UML та її оцінювання на рівні мікро- процесу розробки. Можливості вико- ристання UML в аспекті представлення варіантності вимог до ПС на рівні мак- ропроцесу розробки розглянуті у [7]. Як механізми проектування ПС, що підтримують створення ПС із заданими властивостями, розглядають- ся архітектурний стиль (architectural style), архітектурні зразки (architectural patterns) або каркаси (frameworks), зра- зки або шаблони проектування (design patterns). Їх систематизоване та послі- довне використання на рівні мікро- та макропроцесу об’єктно-орієнтованої розробки в рамках ітеративного жит- тєвого циклу сприяє визначенню та стабілізації архітектури ПС, а також утворенню архітектурних та програм- них релізів, що відповідають необхід- ним функціональним та нефункціона- льним вимогам до ПС. Архітектурний стиль спрямовує та визначає організа- цію системи у цілому: статичні та ди- намічні елементи, їх інтерфейси, коо- перації та способи об’єднання. Архітек- турні зразки моделюють певну інфра- структуру, яку у подальшому плануєть- ся повторно використовувати або адап- тувати до конкретного контексту. Зра- зки проектування надають типове ви- рішення типової проблеми у даному контексті. Вони використовуються для моделювання типових ситуацій, що ви- никають при проектуванні. Викорис- тання архітектурного стилю та архітек- турних зразків пов’язано із архітектур- ним плануванням відповідно до макро- процесу розробки, а зразків проекту- вання – із тактичним проектуванням відповідно до мікро- та макропроцесу розробки [8]. Серед зразків проекту- вання слід відокремити шаблони GRASP (General Responsibility Assign- ment Software Patterns – загальні шаб- лони розподілення обов’язків у про- грамних системах) [9]. Вони більшою мірою відповідають мікропроцесу роз- робки, дозволяють встановити зв’язок із макропроцесом та забезпечують ва- ріантність проектних рішень щодо утворення артефактів із різними атри- бутами якості. У даній статті висвітлені наступні питання: • запропоновано концепцію мо- делювання та оцінювання об’єктно- орієнтованих ПС при їх адаптації, мо- дифікації та реінжинірингу протягом життєвого циклу; • наведено класифікацію мож- ливих змін в об’єктно-орієнтованих ПС відповідно до архітектурних перетво- рень системи з метою досягнення пев- них нефункціональних вимог; • запропоновано підхід до оці- нювання об’єктно-орієнтованих ПС на основі застосування метрик, що орієн- туються на шаблони проектування та розглядаються у контексті сценарію, висвітлено технологічні аспекти його реалізації. Стаття відображає основні ре- зультати, які отримані в рамках теми “Розробка теоретичного підґрунтя та засобів забезпечення супроводження прикладних програмних систем” згідно плану фундаментальних досліджень ІПС НАН України. 1. Концепція моделювання та оцінювання життєздатних ПС Основними задачами моделюван- ня та оцінювання життєздатних ПС є: • задачі моделювання та забез- печення варіантності проектних рі- шень при необхідності адаптації, мо- дифікації та реінжинірингу ПС; • задачі визначення для основ- них характеристик якості ПС сукупно- Методы и средства программной инженерии 61 сті зовнішніх та внутрішніх показників або атрибутів ПС, що характеризують якість ПС, визначення відповідних ме- трик для їх виміру та алгоритму їх ін- теграції відповідно до зовнішніх харак- теристик ПС. Задачі моделювання та оціню- вання ПС розглядаються в рамках мо- делі простежування змін та концепції сценарного підходу [10, 11]. Відповідно до архітектури процесів життєвого ци- клу [2, 3] модель простежування змін підтримує процеси розробки, керуван- ня конфігурацією та, зокрема, процес внесення змін. Вона визначає зв’язок між артефактами ПС відповідно до рі- зних етапів життєвого циклу та проце- су розробки, а також механізми, що зумовлюють процес перетворень архі- тектури ПС. Концепція сценарного підходу розглядає сценарій як базовий артефакт, що підтримує варіантність ПС та визначає механізми забезпечен- ня варіантності проектних рішень, ар- тефакти, що підлягають оцінюванню, конкретизує модель якості на рівні мі- кро- та макропроцесу об’єктно-орієнто- ваної розробки в рамках ітеративного життєвого циклу. Модель якості ПС підтримує процес керування якістю та процес забезпечення гарантії якості. Вона визначає атрибути якості ПС від- повідно до нефункціональних вимог до системи, внутрішні та зовнішні атрибу- ти ПС, а також зв’язок між ними, вну- трішні та зовнішні метрики для вимі- рювання атрибутів ПС тощо. Відповід- но до концепції сценарного підходу модель якості повинна враховувати ва- ріантність проектних рішень, наявність певних шаблонів проектування, що приводять до створення артефактів із заданими атрибутами якості, надавати можливість оцінювати системи на рівні мікро- та макропроцесу розробки. Пропонований підхід до оціню- вання ПС включає: • розробку засобів та методів оцінювання ПС на основі використан- ня моделі ПС у вигляді діаграм UML; • розробку та застосування мет- рик, що орієнтовані на шаблони проек- тування та відповідають різним погля- дам на архітектуру ПС; • встановлення базових артефа- ктів ПС, розробка та оцінювання яких визначають якість ПС у цілому. Для вирішення задач моделюван- ня та оцінювання ПС пропонується побудувати моделі ПС, варіанти сце- наріїв для підтримки варіантності ПС та моделі простежування змін. 1.1. Концепція сценарного під- ходу та узагальнення поняття сцена- рію. Проблема забезпечення варіант- ності ПС, що розглядається у даній статті, базується на концепції сценар- ного підходу. Відповідно до цієї конце- пції поняття сценарію охоплює як функціональний аспект розробки ПС, так і аспект розробки, пов’язаний із забезпеченням нефункціональних ви- мог до ПС, об’єднує мікро- та макро- процес розробки. Узагальнення понят- тя сценарію в рамках сценарного під- ходу приводить до розгляду наступних аспектів варіантності ПС. 1. Варіантність функціональнос- ті ПС на рівні мікро- та макропроцесу розробки, яка відповідає діхотомії “клас/об’єкт” [12]. При цьому сценарій розглядається як екземпляр прецеденту та являє собою конкретну послідов- ність подій, що ілюструє та виражає деякий аспект поведінки системи. Сценарій абстрагує вимоги користува- ча та ідентифікує основні абстракції (такі, як класи, механізми, процеси, підсистеми). Шляхом розширення сце- нарію (утворення нового варіанту пре- цеденту) протягом ітеративного та ін- крементного процесу розробки ПС на- рощується функціональність системи. На кожній ітерації відбувається вимі- рювання та оцінка системи. 2. Варіантність нефункціональ- них вимог на рівні мікропроцесу роз- робки, яка відповідає діхотомії “інтер- фейс/реалізація” [12] і розглядається у контексті сценарію та певних механіз- мів проектування. При цьому сценарії розкривають певні функціональні точ- ки системи, визначають інтерфейси системи, а поведінка абстракцій, що належать сценарію, реалізується та Методы и средства программной инженерии 62 ілюструється діаграмами об’єктів і діа- грамами взаємодій. Утворення варіан- тів сценаріїв здійснюється шляхом пе- рерозподілу обов’язків між об’єктами та визначення інтерфейсів, що забез- печують взаємодію між сценаріями. Такі перетворення відбуваються при незмінній функціональності сценаріїв. При кожному перетворенні відбуваєть- ся вимірювання та оцінка артефактів у контексті сценарію. 3. Варіантність нефункціональ- них вимог на рівні макропроцесу роз- робки, яка підтримується розширенням поняття сценарію щодо варіантів реа- лізації нефункціональних вимог під час архітектурних перетворень системи на основі певних механізмів проектуван- ня. При цьому нефункціональні вимоги розкриваються у вигляді послідовності сценаріїв, за допомогою яких відбува- ється специфікація змін у системі для досягнення певних атрибутів якості. Варіантність проектних рішень закладається на етапі аналізу та проек- тування, коли визначаються основні функціональні точки системи [4] та утворюється її архітектура. Функціона- льні точки розкриваються у вигляді сценаріїв згідно функціональних вимог до системи. Семантика сценаріїв при специфікації моделі системи у вигляді діаграм UML пояснюється та ілюстру- ється діаграмами об’єктів та взаємодій. Варіанти сценаріїв породжуються від- повідно до нефункціональних вимог шляхом послідовного використання шаблонів GRASP. Архітектура системи визначається групуванням та розподі- ленням функціональних точок по ша- рах та розділах архітектури з ураху- ванням їх варіантності та встановлен- ням відповідних інтерфейсів за допо- могою інших шаблонів проектування, зокрема шаблонів GoF [12]. При цьому архітектура системи базується на пев- них архітектурних зразках або карка- сах, в рамках яких вона еволюціонує та супроводжується. На етапі еволюції та супроводження утворюються архі- тектурні та еволюційні релізи ПС від- повідно до варіантності, яку закладено до систем. Внесення змін до ПС та під- тримка варіантності здійснюються в рамках певних моделей простежування та процесу керування змінами. Рішен- ня щодо реінжинірингу ПС приймаєть- ся за умови, коли вимоги до адаптив- ності ПС та ефективності модифікацій не задовольняються або вимагають ви- трат, що перевищують витрати на їх реінжиніринг. Таким чином, запропонована концепція сценарного підходу узагаль- нює поняття сценарію відповідно до мікро- та макропроцесу проектування ПС у контексті досягнення певних функціональних та нефункціональних вимог до ПС. Розглядаючи функціона- льні точки (сценарії) як точки деякого фазового простору, а шаблони проек- тування як певні керуючі дії, що спря- мовують процес розробки та супрово- дження ПС, можна побудувати іміта- ційну модель оптимального керування еволюцією ПС. Координатами фазово- го простору є певні міри, що відпові- дають різним атрибутам якості ПС. Функціональні точки, що належать рі- зним варіантам сценаріїв, утворюють реліз системи, який відповідає потріб- ному рівню атрибутів якості ПС. Траєк- торії функціональних точок визнача- ють напрямок еволюції ПС, який за- безпечує нефункціональні вимоги до них. Архітектурний стиль та архітектур- ні шаблони (а взагалі, і обмеження на розробку ПС) та відповідні зовнішні атрибути ПС утворюють обмеження для тих архітектурних перетворень, що відбуваються у ПС на рівні мікропро- цесу розробки. 1.2. Оцінювання ПС. Проблема оцінювання ПС щодо їх відповідності певним функціональним та нефункціо- нальним вимогам повинна розглядати- ся в контексті наступних аспектів, що мають визначальний для неї характер: технологія розробки системи; шаблон процесу розробки; мова та засоби мо- делювання; підхід до оцінювання атри- бутів якості (quality attributs, QA) ПС; зовнішні та внутрішні метрики відпо- відно до шаблонів проектування та по- глядів на архітектуру ПС. Методы и средства программной инженерии 63 Як атрибути якості ПС можна розглядати характеристики та підхарак- теристики якості ПС [2, 3], головні з них – відмовостійкість, зрозумілість, реактивність, зручність супроводжен- ня, можливість повторного викорис- тання тощо, які відповідають нефунк- ціональним вимогам до процесу розро- бки (development non-functional requi- rements, development NFR), а також надійність (reliability), продуктивність (performance) тощо, які відповідають нефункціональним вимогам до експлу- атації ПС (operational NFR). Зазначимо, що основною та най- більш складною задачею з тих, що роз- глядаються, є встановлення зв’язків між внутрішніми та зовнішніми атри- бутами ПС. При цьому внутрішні ат- рибути, такі, як зв’язність, зачепленість тощо, звичайно стосуються окремих логічних та фізичних структурних сут- ностей ПС різного рівня складності (клас, кооперація, компонент тощо). Отримання оцінок для зовнішніх атри- бутів ПС на основі залучення існуючих внутрішніх метрик або розробки нових відповідно до усіх складових елементів системи складає досить важку задачу. Тому конструктивним підходом при розробці та оцінюванні ПС є вибір та- кого артефакту, проектування та оцін- ка якого є найбільш доцільним та важ- ливим з погляду одержання якісної ПС в цілому. Такими артефактами ми про- понуємо вважати сценарії та відповідні діаграми об’єктів та діаграми взаємо- дій. При цьому внутрішні атрибути си- стеми будемо відносити до тих артефа- ктів, які складають сценарій, а зовніш- ні – власне до сценарію. Відповідно до цього положення і повинні розробля- тися та використовуватися внутрішні та зовнішні метрики. Тобто, проблема оцінювання проектних рішень ПС роз- глядається у контексті вибраного сце- нарію. 1.3. Теоретичний аспект. У тео- ретичному аспекті проблема оцінюван- ня у процесі внесення змін до артефа- ктів ПС з метою досягнення певних значень атрибутів якості системи не має формальних методів вирішення. Це пов’язано з так званим інваріантом розробки ПС, який полягає у наявності таких властивостей ПС, як складність, піддатливість, мінливість і невідчутність [13], завдяки яким процеси розробки, модифікації чи реінжинірингу ПС, що гарантують досягнення певних значень атрибутів якості системи, не можуть бути строго детермінованими. Це зу- мовлено також тим, що перетворення архітектури ПС під час ітеративного процесу розробки системи є неізомор- фними. На кожній ітерації можуть з’являтися нові архітектурні сутності та сутності предметної області, зміню- ватися (зокрема, ускладнюватися) їхня структура та зв’язки. Отримані оцінки на поточній ітерації щодо значень ат- рибутів якості системи не гарантують тієї ж якості на новій ітерації. Це, зок- рема, означає, що задача побудови по- вної та несуперечливої системи оцінок артефактів ПС з метою досягнення у процесі ітеративної розробки системи необхідних значень атрибутів її якості нині не має строгого вирішення. 1.4. Практичне вирішення. Для практичного вирішення проблеми про- понується побудова моделей простежу- вання змін ПС. Визначимо основні їх аспекти: • категорії змін, що відбувають- ся у системі протягом життєвого циклу; • зв’язки між артефактами ПС, які забезпечують внесення змін до си- стеми відповідно до шаблону процесу розробки та етапів життєвого циклу; • напрямок внесення змін під час здійснення перетворень у системі згід- но певних шаблонів проектування для забезпечення необхідної функціональ- ності та відповідності нефункціональ- ним вимогам. Категорії змін відповідають пев- ним фазам життєвого циклу системи, рівням архітектурних перетворень та типам артефактів, які підлягають змі- нам. Зв’язок між артефактами забез- печує необхідну послідовність внесен- ня змін для певного шаблону процесу розробки. Направленість змін визнача- ється результатом вимірювання та отримання оцінок щодо внутрішніх та Методы и средства программной инженерии 64 зовнішніх атрибутів системи на основі певних методів та засобів оцінювання в рамках моделі якості. Важливим аспектом даної про- блеми є розробка механізмів підтримки моделі простежування змін, які б за- безпечували можливість доступу до моделі системи з метою оцінювання ПС. Ця задача повинна вирішуватися на основі створення прикладного про- грамного інтерфейсу (Application Pro- gramming Interface, API) та застосуван- ня компонентної технології для взаємо- дії механізмів підтримки моделі про- стежування у середовищі розробки та функціонування системи. У [5] розгля- нута задача побудови таких механізмів для оцінювання артефактів ПС на від- повідність шаблонам GRASP і отриман- ня інтегральних оцінок, що визначають атрибути якості системи. Запропоно- вані механізми забезпечують доступ до функціонального коду системи та за допомогою створювання та обробки так званих спеціальних ситуацій на етапі функціонування ПС дозволяють накопичувати певним чином специфі- ковану інформацію у репозиторії. Ін- ший підхід полягає у побудові таких механізмів, які дозволяють проводити оцінювання системи та підтримувати процес внесення змін на різних етапах життєвого циклу на основі моделі сис- теми у вигляді діаграм UML. Загальна схема моделювання та оцінювання рішень щодо змін в об’єктно-орієнтованих ПС представле- на на рисунку. 1.5. Вимоги до середовища ство- рення та функціонування ПС. Опише- мо основні висхідні умови до створен- ня та функціонування ПС, у контексті яких вирішується проблема оцінюван- ня, що розглядається у даній статті. Розглянемо об’єктно-орієнтовану технологію розробки ПС, яка базується Модель ПС (діаграми UML) Відповідають Включає Сценарії Шаблони проектування Включає Об’єктно- орієнтовані метрики Базуються Включає Варіанти проекту Моделювання Утворює Спрямовують Зовнішні оцінки якості Включає Використовує Внесення змін до сценаріїв Реліз ПС Відповідає Моделі простежу- вання змін Змінює Включає Вимоги користувача Обмежують Визначають Визначає Внесення змін до моделей Визначає Використовує Визначає Визначає Визначає Змінює Включає Рисунок. Схема моделювання та оцінювання об’єктно-орієнтованих ПС при їх створенні, модифікіції та реінжинірингу Методы и средства программной инженерии 65 на об’єктній моделі [4]. Використання такої моделі є найбільш сприятливим для створення ПС, що відповідають ви- могам масштабованості (scale adjust- ment), можливості повторного викорис- тання (reusability) та зручності супро- водження (maintainability). Вибір об’єк- тно-орієнтованої технології зумовлює вибір відповідного шаблону процесу розробки, мови та засобів моделюван- ня, а також об’єктно-орієнтованих мет- рик для підтримки вимірювань протя- гом життєвого циклу ПС. У пропонованому підході як шаб- лон процесу розробки ПС розглядається раціональний уніфікований процес (Ra- tional Unified Process) [5]. Цей процес розробки ПС заснований на архітекту- рі, керується прецедентами викорис- тання, є ітеративним та інкрементним, включає аналіз якості і керування ри- зиками. Одне з положень методології Rational Unified Process звучить у такий спосіб: “Ітеративний процес – це про- цес, спрямований на керування пото- ком версій програмного забезпечення, що виконуються. Процес з нарощуван- ням можливостей (incremental) – це процес, спрямований на безперервну інтеграцію системної архітектури для створення (виробництва) цих версій, при цьому кожна версія містить в собі удосконалені можливості у порівнянні з попередніми” [9]. Тобто використан- ня цього шаблону процесу розробки відповідає такому оцінюванню артефа- ктів ПС, яке враховує перетворення логічного рівня, коли з кожною ітера- цією нарощується функціональність системи (за рахунок ускладнення вер- сій прецедентів) та певні архітектурні перетворення, що приводять до зміни атрибутів якості у напрямку нефункці- ональних вимог до ПС. Як уже зазначалося, мовою моде- лювання ПС вибирається уніфікована мова моделювання UML. Мова UML до- бре узгоджується з раціональним уні- фікованим процесом та призначена для візуалізації, специфікації, конструю- вання та документування артефактів ПС [12]. Оцінювання ПС на фазі проек- тування (design phase) може відбува- тися на основі аналізу діаграм UML і тих сутностей (класів, інтерфейсів, ко- операцій тощо) та відношень (залежно- стей, асоціацій тощо), що їх утворю- ють. Таке оцінювання може проводи- тися з використанням як простих об’єктно-орієнтованих метрик (напри- клад, кількість класів, атрибутів, асоці- ацій, глибина дерева наслідування), так і метрик, що базуються на певних зра- зках (наприклад, кількість Singleton зразків [13] та відповідних екземплярів у діаграмі). Крім того, для оцінки архі- тектури системи, представленої як на- бір діаграм UML, може бути викорис- тано результат витягання зразків (pat- tern mining results) або антизразків на основі аналізу цих діаграм. Також важ- ливою особливістю UML, яка стосуєть- ся оцінювання ПС, є можливість відо- браження системної архітектури із різ- них точок зору та їх взаємодії. Це по- гляди з точки зору: проектування (De- sign view), процесів (Process view), реа- лізації (Implementation view), розгор- тання (Deployment view). Статичні ас- пекти Design view передаються діагра- мами класів та об’єктів, а динамічні – діаграмами взаємодій, станів та дій. Статичні та динамічні аспекти Process view візуалізуються тими ж діаграмами, що і Design view, але при цьому особ- лива увага приділяється активним кла- сам, які представляють нитки (thread) та процеси. Статичні аспекти Imple- mentation view передаються діаграмами компонентів, а динамічні – діаграмами взаємодій, станів та дій. Статичні аспе- кти Deployment view описуються діаг- рамами розгортання, а динамічні – ді- аграмами взаємодій, станів та дій. По- гляд з точки зору прецедентів (Use case view) об’єднує наведені погляди на ар- хітектуру системи. Як засіб розробки ПС розгляда- ються СASE-засіб Rational Rose компа- нії Rational Software [5]. Це інструмент аналізу і проектування об'єктно-орієн- тованих ПС на основі мови UML. Він дозволяє створювати та супроводжува- ти UML-діаграми, здійснювати пряме та зворотне проектування тощо. На даний час цей інструмент є найбільш Методы и средства программной инженерии 66 потужним та широко уживаним серед існуючих засобів розробки. Розробка засобів доступу до UML-діаграм, що зберігаються у моделях Rational Rose, для обчислення метрик програмного забезпечення до початку реалізації проектних рішень складає важливу за- дачу оцінювання ПС. 2. Архітектурні перетворення ПС Можна виділити наступні види змін, що відбуваються у ПС протягом життєвого циклу. • Зміни, що пов’язані з розроб- кою нової системи та зумовлюються необхідністю виконання функціональ- них та нефункціональних вимог корис- тувача за наявності певних обмежень на розробку. Розробка ПС здійснюєть- ся відповідно до шаблону процесу роз- робки – раціонального уніфікованого процесу, який об’єднує мікро- та мак- ропроцес. • Зміни, що пов’язані з етапом супроводження ПС. Відповідно до змін ПС розглядаються наступні стадії [13]: підтримка експлуатації, адаптивне су- проводження, поліпшуюче супрово- дження. • Зміни, що відповідають наслі- дуваній системі для реконструкції її проекту та часткової реалізації у ново- му вигляді (реінжиніринг). При змінюванні нефункціональ- них вимог до системи протягом її жит- тєвого циклу архітектура системи та- кож змінюється для досягнення нових атрибутів якості. Такі зміни розгляда- ються як архітектурні перетворення. Наступні п’ять категорій змін визна- чаються тими факторами, які зумов- люють перетворення архітектури від- повідно до нефункціональних атрибу- тів ПС. Перетворення архітектури від- повідно до обраного архітектурного стилю. Існує декілька архітектурних стилів, запровадження яких дозволяє досягти певних атрибутів якості ПС, тобто їх застосування приводить до покращення або погіршення тих чи інших нефункціональних вимог до ПС. Певний стиль, наприклад, такий, що відповідає багаторівневій архітектурі, збільшує гнучкість (flexibility) ПС, але зменшує її продуктивність. Придатний стиль необхідно вибирати залежно від того, досягнення яких нефункціональ- них вимог є пріоритетним. При цьому треба зважати на те, що зміна архітек- турного стилю зажадає суттєвої чи на- віть кардинальної переробки ПС. Тобто такі рішення повинні прийматися до стадії планування та аналізу ПС або на перших ітераціях розробки системи. Перетворення архітектури від- повідно до архітектурних зразків, що використовуються. Архітектурний зра- зок відрізняється від архітектурного стилю тим, що він не є переважним щодо впливу на архітектуру ПС. Він також відрізняється від зразку проек- тування тим, що впливає на архітекту- ру ПС у цілому або принаймні на зна- чну її частину. Архітектурний зразок нав’язує скоріше певне правило ство- рення проекту ПС, яке специфікує по- ведінку системи в одному аспекті, на- приклад паралельність (concurrency) або стійкість (persistency). Перетворення архітектури від- повідно до застосування зразків проек- тування. Вплив зразків проектування на архітектуру ПС є найменш значним. Наприклад, для багаторівневої архітек- тури такі зразки можуть визначати структуру певного рівня щодо пере- розподілу обов’язків між прикладними або програмними сутностями, які на- лежать цьому рівню. Вони також мо- жуть зажадати появи нової структурної сутності на іншому рівні. Такі перетво- рення відповідають, зокрема, шаблонам GRASP. Зміни, пов’язані з переведенням (converse) нефункціональних вимог до функціональних. Таке перетворення розширює архітектуру ПС за рахунок внесення певної функціональності, яка не має відношення до проблемної об- ласті. Наприклад, застосування механі- зму обробки виключень під час реалі- зації певної функції (не змінюючи при- значення функції) приводить до поліпшення відмовостійкості (fault-tole- rance) певного компонента ПС. Методы и средства программной инженерии 67 Зміни, пов’язані з розподілом (або перерозподілом) вимог. При цьому пев- ний системний рівень розподіляється між підсистемами або компонентами та для кожного такого компонента визна- чаються нефункціональні вимоги. Тоб- то початкова нефункціональна вимога розглядається як певна композиція ви- мог до компонентів для деякого рівня архітектури. Перелічені фактори, що відпові- дають наведеним категоріям, також ви- значають направленість змін у системі для досягнення певних значень атрибу- тів якості. 3. Підхід до оцінювання об’єктно- орієнтованих ПС Розглянемо основні особливості вимірювання об’єктно-орієнтованих ПС у пропонованому підході. Для оці- нювання атрибутів якості довільних ПС можуть бути застосовані наступні основні підходи. 1. Оцінки, що базуються на сце- наріях. Для того щоб оцінити деякий атрибут якості (наприклад, maintain- ability QA), розроблюється певна кіль- кість сценаріїв, які конкретизують да- ний атрибут. Кожний такий сценарій визначає деяку низку змін у системі, яка стосується прикладних та архітек- турних сутностей ПС і прийнята до розгляду у контексті даного сценарію. Далі проводиться та підраховується кіль- кість перетворень у системі, необхід- них для її адаптації відповідно до кож- ного сценарію. Кінцевий результат аналізується на предмет кількості сце- наріїв, що вдалося реалізувати шляхом перетворень різного типу, зокрема із використанням шаблонів проектуван- ня. Цей результат визначає оцінку пев- ного атрибута якості. 2. Імітація. Застосовуються за- соби та методи імітаційного моделю- вання для розгляду та оцінювання не- обхідних перетворень у ПС. При цьо- му використовується інформація, що характеризує вже реалізовані компоненти. 3. Математичне моделювання. Базується на розробці та застосуванні математичних моделей або метрик, особливо для оцінювання експлуата- ційних нефункціональних вимог. 4. Об’єктивна аргументація. Цей підхід ґрунтується на логічній аргумен- тації прийнятих проектних рішень. Основою пропонованого підходу до оцінювання атрибутів якості як ПС, так і проектів змін до ПС є викорис- тання метрик ПС, які засновані на ша- блонах проектування та враховують повноту їх застосування. При цьому стандартом середовища для проекту- вання систем пропонується середови- ще Rational Rose, де логічному предста- вленню відповідають діаграми класів та взаємодії, представленню процесу – діаграми процесів, представленню роз- робки – діаграми розробки, фізично- му представленню – діаграми компо- нентів і, нарешті, сценарному – діаг- рами способів використання. Представлення процесу враховує такі нефункціональні вимоги, як про- дуктивність (performance) та придат- ність (availability) системи. Це відпові- дає властивостям паралелізму (concur- rency), розподіленості (distribution), ці- лісності (integrity) системи та відмовос- тійкості (fault-tolerance). Представлення розробки бере до уваги такі внутрішні вимоги, як легкість розробки, керуван- ня розробкою, повторне використання або загальність та обмеження, що на- кладаються на систему інструменталь- ними засобами розробки. Фізичне представлення враховує такі нефункці- ональні атрибути, як придатність, на- дійність (відмовостійкість), продуктив- ність та масштабованість. Логічне представлення взагалі підтримує функ- ціональні вимоги – сервіси, які систе- ма надає користувачу. У контексті сце- нарного підходу логічне представлення з’ясовує архітектурні елементи систе- ми у процесі архітектурного проекту- вання та ідентифікує механізми та за- гальні елементи системи. Для одержання оцінок рішень підхід повинен об’єднувати, наприклад, метрики логічного представлення та метрики представлення процесу. В під- ході основною ланкою, що зв’язує всі представлення між собою, є сценарії. Методы и средства программной инженерии 68 Тому і метрики представлень повинні взаємодіяти зі сценарними метриками. Сценарні метрики вимірюють характе- ристики конкретних задач, які повинна виконувати система, тому вони інварі- антні відносно рівня реалізації. Напри- клад, час очікування виконання запиту можна оцінити на рівні діаграми класів (кількість класів запиту тощо), діаграми взаємодії (кількість елементарних вза- ємодій між об’єктами), діаграми ком- понентів (кількість та потужність про- цесорів, що задіяні) або інших. Дослідження та розробка мето- дів і засобів оцінювання можливих змін ПС спирається в підході на моде- лі простежування змін. На основі цих моделей передбачається оцінювати якість сценаріїв, що визначають най- більш важливі та критичні властивості і функції проекту ПС. У рамках підхо- ду сценарії найбільш природним обра- зом забезпечують варіантність про- ектних рішень і використовують такий важливий стандарт для об’єктно-орієн- тованого проектування і розробки ПС, як UML. Як критерії оцінки сценаріїв пропонується розглядати їх відповід- ність шаблонам GRASP. Ці шаблони використовуються в процесі створення діаграм взаємодій при розподілі обов'яз- ків між об'єктами, розробці способу їхньої взаємодії. Такі діаграми безпосе- редньо пов'язані зі сценаріями, і їхня успішна реалізація визначає успіх усього проекту. На основі інтегральних оцінок сценаріїв пропонується формувати аль- тернативні сценарії, визначати най- кращий сценарій і вибирати кращу ре- алізацію. Головна задача полягає у ви- явленні механізму, що дозволяє оціню- вати сценарії по шаблонах. Для самих шаблонів відомий їхній зв'язок із влас- тивостями компонентів ПС, що повин- ні задовольняти необхідним вимогам. Кожен шаблон характеризується своїми відмінними рисами, що забез- печують [9]: • підтримку інкапсуляції, надій- ність і пристосовність до обслугову- вання (Expert, Low Coupling); • простоту розуміння і підтрим- ку визначень класів, спрощення під- тримки і внесення змін (Expert, High Cohesion); • зменшення витрат на супровід і можливості повторного використання (Creator, Low Coupling); • поліпшення умов повторного використання компонентів стосовно логіки процесів предметної області на рівні реалізації, спрощення підтримки і доробки (Controller, High Cohesion); • можливість контролю стану прецеденту для виконання системних операцій у визначеній послідовності (Controller, Expert, High Cohesion). Аналіз шаблонів GRASP показує, що застосування їх під час створення діаграм взаємодій приводить до задачі оптимізації використання шаблонів відповідно до існуючих вимог й обме- жень на розробку як компонентів ПС, так і всієї системи. При оцінюванні об’єктно-орієнто- ваних ПС у контексті сценарію та шаб- лонів розподілення обов’язків можуть розглядатись наступні атрибути ПС: — розмір програми, що відпові- дає класам, які утворюють сценарій; — зв’язність (coupling) або сту- пінь глибини зв’язків між класами та об’єктами; — зачепленість (cohesion) між класами та об’єктами для реалізації функціональності; — спадкування (inheritance) від- повідно до зв’язку підкласів та супер- класів; — повторне використання (reuse) класів та об’єктів сценаріями, що утво- рюють різні релізи ПС. Для вимірювання цих атрибутів можуть бути запропоновані наступні метрики: — кількість методів класу, що підтримують його функціональність в рамках сценарію, та кількість методів класу, що підтримують інтерфейс сце- нарію; — розмір коду класів, що нале- жать сценарію; — зв’язність між об’єктами або кількість інших класів сценарію, з Методы и средства программной инженерии 69 якими зв’язаний даний об’єкт у складі сценарію з (без) урахуванням ієрархії спадкування; — відношення кількості методів класу, які безпосередньо використову- ються у контексті сценарію, до їхньої загальної кількості; — кількість атрибутів класу, які використовуються методами даного класу, по відношенню до загальної кількості атрибутів, що підтримують функціональність класу; — глибина дерева ієрархії класів та кількість нащадків класу відповідно до певного рівня ієрархії; — кількість керувань, які нада- ються даному класу для підтримки функціональності сценарію та його ін- терфейсу. Відповідно до сценарного підходу та узагальненого поняття сценарію зо- внішнім атрибутом ПС, що визначає їх якість, може бути перелік шаблонів, які охоплюють сутності ПС, зокрема класи та об’єкти, а зовнішньою метри- кою – кількість класів та об’єктів, охоплених екземплярами шаблонів, у порівнянні з їхньою загальною кількіс- тю в ПС. Витяг шаблонів може бути здійснений як на основі аналізу діаг- рам UML (зокрема, діаграм класів), так і програмного коду системи. Інші зов- нішні атрибути ПС можуть бути ви- значені шляхом поширення сценарного підходу на макропроцес проектування. При цьому може бути сформована по- слідовність сценаріїв у вигляді вимог до системи, реалізація яких шляхом архітектурних перетворень ПС зумов- лює досягнення певного рівня атрибута якості ПС. Таким чином підтримується варіантність ПС на рівні макропроцесу проектування ПС. Кількість реалізова- них сценаріїв із загальної кількості є мірою певного атрибута якості ПС. Інформація про шляхи еволюції (track evolution) ПС та результати вимі- рювання за допомогою певних метрик повинна накопичуватися у репозиторії (history data repsitory). Надалі вона мо- же використовуватися для аналізу (зо- крема, методами статистичного аналізу) та вибору оптимальних шляхів ство- рення нових версій ПС. При цьому, бе- зумовно, важливу роль відіграє логічна аргументація з боку розробника систе- ми щодо створення варіанту сценарію у контексті забезпечення необхідних нефункціональних вимог до ПС. Подальшим напрямком розробки проблеми оцінювання ПС є обґрунту- вання повної та мінімальної системи метрик, яка б давала оцінку поточним атрибутам системи в контексті задано- го сценарію, аналіз зв’язку вимог до ПС та зовнішніх атрибутів системи, створення інструментаріїв керування процесом верифікації якості ПС. Висновки Проблема моделювання й оці- нювання життєздатних ПС при їх модифікації та реінжинірингу на стадії розробки і супроводження ПС відно- ситься до основних проблем програм- ної інженерії. Перспективним підходом до її вирішення є застосування технології розробки та створення життєздатних ПС, яка базується на запропонованих засобах підтримки життєздатності: мо- делі ПС, специфікованої у вигляді діаг- рам UML; варіантності артефактів на основі сценарного підходу; моделі про- стежування змін в ПС; системі оціню- вання ПС на основі метрик, що базу- ються на шаблонах проектування ПС та розглядаються у контексті сцена- рію; СASE-засобах Rational Rose компанії Rational Software на основі мови UML. Розробка технології створення життєздатних ПС має велике теорети- чне і практичне значення для інформа- тизації змінних (evolutional) систем з підвищеними вимогами до стійкості функціонування, зокрема систем спе- ціального призначення. 1. Ігнатенко П.П. Проблеми забезпечення життєздатності програмних систем та під- ходи до їх вирішення // Пробл. програм- мирования – 2002. – №3—4. – С. 58—73. 2. Бабенко Л.П., Лаврищева Е.М. Основи про- грамної інженерії. – Київ: Знання, 2001. – 269 с. 3. Основы инженерии качества программных систем / Ф.И. Андон, Г.И. Коваль, Т.М. Ко- Методы и средства программной инженерии 70 ротун, В.Ю. Суслов. – Киев: Изд. дом «Ака- демпериодика» НАН України, 2002. – 502 с. 4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложе- ний на С++: 2-е изд., пер. с англ. – М.: Бином, 2000. – 560 с. 5. Боггс У., Боггс М. UML и Rational Rose. – М.: Лори, 2000. – 582 с. 6. Kruchten Ph. The 4+1 View Model of Archi- tecture: Current Practice // IEEE Software. – 1995. – 12(6), Nov. – Р. 42—50. 7. Бабенко Л.П., Поляничко С.Л. Підхід до ате- стації властивостей компонентів програм- них систем засобами UML // Пробл. про- граммирования. – 2001. – №1—2. – С. 35—41. 8. Буч Г., Рамбо Д., Джекобсон А. Язык UML: Руководство пользователя. – М.: ДМК, 2000. – 432 с. 9. Ларман К. Применение UML и шаблонов проектирования. – М.: Вильямс, 2001. – 496 с. 10. Підхід до забезпечення реінжинірингу об’єктно-орієнтованих програмних систем / П.П. Ігнатенко, В.М.Бистров, І.О. Заєць, О.П. Ігнатенко // Пробл. программирова- ния. – 2002. – №1—2. – С.98—108. 11. Scenarios in System Development: Current Practice / K. Weidenhaupt, K. Polh, M. Jarke, P. Haumer // IEEE Software. – 1998. – March/April. – Р. 34—35. 12. Design Patterns, Elements of Reusable Object- oriented Software / E. Gamma, R. Helm, R. Johnson, J. Vlissides. – N.—Y.: Addison— Wesley, 1995. – 345 p. 13. Мацяшек Л. Анализ требований и проекти- рование систем. Разработка информацион- ных систем с использованием UML: Пер. с англ. – М.: Изд. дом “Вильямс”, 2002. – 432 с. Отримано 25.04.03 Про авторів Ігнатенко Петро Петрович кандидат технічних наук, завідувач від- ділом Бистров Віктор Михайлович кандидат фізико-математичних наук, ст. наук. співробітник Ігнатенко Олексій Петрович аспірант Ткаченко Володимир Миколайович аспірант Місце роботи авторів: Інститут програмних систем НАН України просп. Академіка Глушкова, 40, Київ-187, 03680, Україна Тел. (044) 266 1540

Problems and tools of designing and estimation of viable program system

Репозитарії

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