К. М. Лавріщева програмна інженерія підручник Київ, 2008

• Название: К. М. Лавріщева програмна інженерія підручник Київ, 2008
• Дата: 05.05.2022
• Размер: 5.23 Mb.
• Имя файла: lavrishcheva-6.pdf
• Тип: Документы; #513598
• страница: 34 из 43

Об'єктні застосування розробляють незалежні розробники ПС за об'єктним підходом і ті, хто забезпечує розширення функцій існуючих систем. Це зв'язані набори прикладних функцій (наприклад, підготовка текстів і відображення витраченого часу й ін.). Вони не стандартизовані, утворять компоненти середовища
CORBA і можуть мати доступ до сервісу і послуг системи через стандартний
інтерфейс.
Класи об'єктів у цих застосуваннях знаходяться на тому ж семантичному рівні, що і класи в загальних засобах обслуговування.
Різниця лише в тому, що класи загальних засобів обслуговування – це дуже загальні функції, а класи об'єктних застосувань і більш спеціалізовані і надають специфічні для прикладного домену інтерфейси. Програми, що входять у складі об'єктних застосувань, можуть використовувати:
– загальні прикладні засоби (підготовка текстів, електронні таблиці, електронна пошта й ін.);
– системи автоматизації застосувань (СА, ECAD, MCAD);
– системи автоматизованого проектування архітектури;
– інструментальні засоби підтримки розробки програм, проектування БД і ін.;
– системні програми керування мережею;
– засоби доступу до інформації й одержання довідок з довідкових систем і з
БД інформаційних систем і т.д.).
Окремі класи в об'єктних застосувань можуть «мігрувати» у загальні засоби обслуговування, якщо є спільність реалізованої задачі й інтерфейсів для класів об'єктів у різних застосуваннях.

246 Розділ 8
Таким чином, CORBA надає розробникам загальну архітектуру створюваної системи, що адаптується до конкретних умов прикладної області, і на її основі реалізуються специфічні задачі системи за об'єктами, методами і їхніми
інтерфейсами. О'єктів повторного використання мають тільки інтерфейси.
8.3.6. JAVA-технологія
JAVA–технологія базується на стандартній моделі EJB (Enterprise Java
Beans), призначеній для забезпечення взаємодії різних компонентів за допомогою виклику методу RMI (Remote Method Invocation) мови Java. Відповідно до цієї моделі програмні компоненти групуються в прикладну програму для роботи в будь-якому середовищі на віртуальній машині JVM (Java Virtual Machine). Веаns- компонент розробляють як КПВ для різних середовищ. Механізм розгортання beans-компонентів на сервері базується на програмах, записаних мовою Java.
Існуює спеціальна утиліта побудови застосування для його конфігурування, об'єднання і включення до них нових компонентів [20].
Для визначення функціональних властивостей компонентів, орієнтованих на
КПВ, використовують проектні шаблони властивостей і подій. До властивостей beans-компонентів відносять підмножину станів, значення яких визначають поведінку і зовнішній вигляд компонента. Bean–компоненти генерують події або посилають їх іншим об'єктам, а проектні шаблони забезпечують ідентифікацію цих подій.
Компоненти beans підрозділяють на три категорії:
1. Компоненти сеансів, що підтримують правила бізнесу-логіки, орієнтовані на стани і можуть бути пов'язані з конкретним клієнтським сеансом.
2. Компоненти сутностей, що виконують зв'язок з БД безпосередньо і надають дані в об'єктній формі.
3. Компоненти керування подіями, що функціонують за одержанням повідомлень, а також отримують від системи повідомлення JMS (Java Messaging
System).
При створенні beans-компонентів використовуються інтерфейси: home – для керування ЖЦ компонента; інтерфейс Remote для виклику і реалізації компонента в середовищі віртуальної машини JVM. Кожен компонент beans має свій контейнер, що викликає і регулює всі процеси ЖЦ і інтерфейс.
Основна особливість beans компонентів у JAVA – це відображення здатності аналізувати самого себе і реалізовувати свої можливості динамічно під час виконання, а не під час компіляції. З цією метою використовується пакет
Java.lang.reflect, що входить у ядро API, він підтримує відображення різних компонентів і містить у собі інтерфейс (member), що визначає методи одержання
інформації про поля і структуру класів.
Для завдання властивостей, подій і методів beans компонентів є два способи.
Перший спосіб – використання погоджених імен, другий – створення додаткового класу для надання необхідної інформації.
Beans компонент можна розглядати як підмножину станів, що визначають його поведінку і зовнішній вигляд. Ці властивості підрозділяються на прості, булеві, індексовані і зв'язані. Прості властивості мають одиночні значення, можуть бути ідентифіковані проектними шаблонами (наприклад, властивості для read/write, read-only, write-only). Булеві властивості приймають значення true або false і

Розділ 8 247
ідентифікуються проектними шаблонами. Індексовані властивості складаються з множини індексованих значень, що задаються проектним шаблоном. Зв'язані
властивості відбивають події без зміни функціональності компонента.
Інформаційні масиви властивостей (PropertyDescriptor), подій (EventSetDescriptor) і методів (MethodDescriptor) утримуються безпосередньо в стандартному шаблоні
BeanInfo. При реалізації цих властивостей розробник може задовольнити вимоги користувача. Обмежена властивість відбиває подію, значення властивості якої змінюється, і відсилає подію об'єктам, що можуть відхилити змінені властивості або підтримати їх залежно від середовища виконання. За допомогою меню (File,
Save) інструмента BDK компоненти зберігаються в JАR-архіві у послідовності дій:
– створити каталог для нового beans компонента;
– створити один або трохи вихідних JAVA файлів, що реалізують компонент,
і скомпілювати них;
– створити файл опису властивостей компонента;
– згенерувати JAR файл;
– запустити інструментарій BDK для збереження компонента;
– протестувати компонент.
Взаємодія різних компонентів здійснюється за допомогою механізму виклику вилученого методу RMI, що доповнює мова JAVA стандартною моделлю EJB
(Enterprise Java Beans) компанії Sun. До неї підключені класи мови JAVA, їхні атрибути, параметри середовища і властивості групування компонентів у прикладну програму для виконання на віртуальній машині JVM. Механізм розгортання JAVA-компонентів типу beans на сервері описується в програмах вхідною мовою, а сервер створює для них оптимальне середовище для виконання задач EJB.
Для реалізації і повторного використання КПВ типу beans маються такі шаб- лони в Java for Forte:
– Beans для створення нового компонента, формування каркаса компонента з простими властивостями і можливістю автоматичної їхньої зміни;
– BeanInfo для інтеграції beans компонентів і забезпечення взаємодії;
– Customizer для створення панелі, на якій розміщаються елементи, використовувані для керування конфігурацією beans компонентів;
– Property Editor для створення класу, що використовується під час проектування і редагування властивостей beans компонентів.
Beans компоненти можуть застсовуватися в інтегрованої архітектурі системі
Microsoft Active, контейнери яких підтримують Internet Explorer, Microsoft Office і
Visual Basic. Крім того, на сайте java.sun.com можна завантажити інструментальну систему Bridge for Active для застосування Java Beans компонентів у контейнерах
Active, а також завантажити інструментарій Java Beans Migration Assistant for Active з метою аналізу елементів керування Active і генерації каркаса JavaBean компонентів.
При інтеграції компоненти використовуєть інтерфейс, опис якого задається парою – ім'я параметра і значення параметра. Вони можуть змінюватися автоматично без втручання в код компонента. Цей опис та змінювання необхідних параметрів інтерфейсу перевіряє Inspector Components.
Таким чином, мова JAVA підтримує стандартні механізми для роботи з компонентами як з будівельними блоками, що мають такі особливості:

248 Розділ 8
– властивості, події і методи керування;
– параметри часу розробки шляхом реінженерії компонента;
– збереження і використання параметрів налагодження конфігурації в заданий час;
– реєстрація повідомлень про події або їхня генерація beans компонентами;
– збереження КПВ в архіві системи JAVA за допомогою шаблона JAR
Contents самостійно або у вигляді групи;
– опис компонентів різними МП.
Forte for Java пропонує шаблони інтеграції всіх класів компонентів у програмну структуру в [21].
Інтеграція компонентів. До основних типів компонентів у мові JAVA відносяться: проекти, форми (AWT компоненти), beans компоненти, СОRВА компоненти, RMI компоненти, стандартні класи-оболонки, бази даних, JSP компоненти, сервлети, XML документи, DTD документи, файли різних типів і їхніх груп. Тип компонента має функціональність і підтримується стандартним набором методів JAVA для запуску, функціонування і знищення компонента. Для опису й
ініціалізації різних типів компонентів і інтеграції їх у новий проект використовують спеціалізовані шаблони.
Таким чином, розглянуті сучасні засоби, інструменти та середовища значно спрощують процес створення нових типів компонентів, в том числі і КПВ.
Саме вони забезпечують виробництво ПС на автоматизованої основі.
8.4. Оцінювання вартості системи з компонентів
Інженерія ПС з компонентів, які повторно розробляються або беруться готові, базується на КПВ. Вона вміщує оцінку вартості нової розробки з метою обчислення витрат на створення продукту з сукупності взаємозв'язаних компонентів, що реалізують функції ПрО.
Загальну вартість створення компонентної системи вважаємо такою, що складається з таких складових елементів:
С = С
1
+ С
2
+ С
3
+ С
4
,
де С
1
– вартість аналізу функцій ПрО;
С
2
– вартість підбору КПВ з репозитарію або сучасних бібліотек методів з урахуванням знов розроблених компонентів;
С
3
– вартість інтеграції всіх компонентів в систему;
С
4
– вартість визначення і обробки даних ПС.
Розглянемо окремо кожну складову вартості ПС.
Вартість аналізу функцій ПрО має вигляд
 



M
i
i
i
i
i
D
F
C
b
С
1 1
1 1
,
де D
i
– дані i-функції, M – кількість функцій F в системі,
1, коли функція реалізована компонентом,
b
1
i
= 0, інакше.

Розділ 8 249
Вартість пошуку і дослідження можливостей застосування КПВ з репозитарію для реалізації деякої визначеної функції ПрО визначається за допомогою виразу
)
(
)
(
2 2
1 1
2 2
ji
ji
N
j
M
i
ji
PF
C
F
C
a
С





,
де С
2
(F
ji
) – вартість пошуку КПВ для функції F
i
, сформульованої на процесі аналізу ПрО, N – кількість нових компонентів і КПВ, C
2
(PF
ji
) – вартість розробки деяких типових програмних компонентів,
1, коли j-компонент використовується функцією Fi,
a
2
ji
= 0, інакше.
Вартість композиції компонентів визначається так:
)
(
3 1
1 1
2 3
jr
N
j
M
i
R
r
jir
I
C
d
C





,
де С
3
(Ijr) – вартість створення інтерфейсних модулів пари компонентів K
i
і K
r
,
1, коли r  R відповідає кількості параметрів
d
2
jir
= Х = (Х
1
.,Х
r
) – для j-компонента і r-функції(r =1,..., R),
0, інакше.
Таким чином, кінцевий результат оцінювання вартості ПС має вигляд
(розрахунок С
4
громіздкий, тому не приводиться):








)
(
)
(
)
(
2 2
1 1
2 1
1
ji
ji
N
j
M
i
ji
i
i
i
M
i
i
PF
C
F
C
a
D
F
C
b
C =
4 3
1 1
1 2
)
(
C
I
C
d
jr
N
j
M
i
R
r
jir





.
Головне обмеження цього виразу – це необхідність реалізації заданих функцій в ПС, наявність засобів інтеграції пар компонентів Ki і Kr, які можна представити в будь-яких сучасних МП в певному середовищі функціонування, віповідність кількості компонентів R заданим функціям для розв’язання задач
ПрО.
Розрахунок вартості для компонентних систем є трудомістким процесом.
Загальна вартість зменшується, якщо опис компонентів виконано на одній МП, за рахунок відсутності інтерфейсних модулів перетворення даних в системі.
Висновки. Програмна інженерія характеризується ступенем використання накопиченої програмної продукції у вигляді КПВ і компонентів ПрО багаторазового використання. Розглянуті три напрямки інженерії КПВ, застосувань та ПрО. Інженерія припускає не тільки їхній підбір для застосування в нових розробках ПС, але відповідні інженерні методи планування відбору та оцінювання
їхніх показників якості, вартості і ризику придбання КПВ. Наведено загальний опис підходу до опису специфіки ПрО з використанням мови DSL. Визначено процедуру оцінювання вартості розробленої компонентної системи.

250 Розділ 8
Контрольні питання і завдання
1. Визначте базис інженерії різних застосувань.
2. Охарактеризуйте інженерію КПВ.
3. Визначте базис інженерії предметної області.
4. Наведить модель специфікації КПВ.
5. Назвіть функції репозитарія.
6. Визначте інтерфейс компонентів і інженерію КПВ.
7. Охарактеризуйте особливості прикладної інженерії.
8. У чому суть інженерії домену?
9. Охарактеризуйте мови опису специфіки домену.
10. Які є засоби розроблення доменів?
11. Наведіть призначення лінії виробництва програм.
12. Визначте суть технології виготовлення програмних систем.
13. Назвіть головні цілі VSTS і MSF.
14. Охарактеризуйте технологічні засоби RUP і Corba.
15. Як оцінюється вартість системи з компонентів і інтерфейсів.
Список літератури до розділу 8
1. Бабенко Л.П., Лаврищева Е.М. Основи програмної інженерії. – Киев.:
Знання. – 2001.– 269 с.
2. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика.
Киев: Наукова думка, 2006.–451с.
3. Crarnetcki K. Owerview of Generative Software Development// Canada, www.crarnetcki.fcm.org
4. Чернецки К., Айзенекер У. Порождающее программирование. Методы, инструменты, применение. – Издательский дом «Питер». – М.: СПб.–
Харьков – Минск .– 2005 – 730 с.
5. Fowler M. Language Workbenches and Model Driven Architecture. http://martinfowler.com/articles/mdaLanguageWorkbench.html
6. Mernik Marjan, Anthony M. Domain-Specific Languages for Software
Engineering. Sloane. Proceedings of the 36th Hawaii International Conference on System Sciences.
7. Meyer B. On to Components. Computer. – vol. 32, N 1, January 1999. – pp.139–140.
8. Lowy J. COM and NET Component Services. – O'Reilly, 2001. – 384 p.
9. Batory D., O'Malley S. The Design and Implementation of Hierarchical Software
Systems with Reusable Components / ACM Transactions on Software
Engineering and Methodology. – № 4, vol. 1, October 1992. – P. 355–398.
10. Weide B., Ogden W., Sweden S. Reusable Software Components/ Advances in
Computers, vol. 33. – Academic Press, 1991. – P. 1–65.
11. Jacobson I., Griss M., Johnson P. Software Reuse: Architecture, Process and organization for Business Success – Addison Wesley, Reading , MA, May 1997
.– 501 p.
12. Northrop L.M. SEI`s Software Product Line Tenets // IEEE
Software .– 2002 .– v.–19 .– № 4.– Р.32–39.

Розділ 8 251 13. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature- oriented domain analysis (FODA) feasibility study. Technical Report
CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon
University, 1990.
14. Mezini, M., Ostermann, K.: Variability management with feature-oriented programming and aspects. In: Foundations of Software Engineering (FSE-12),
ACM SIGSOFT (2004)
15. Wilson С., Maples B., Londgrave T. Принципы проектирования и разработки программного обеспечения .–Учебный курс.–Пер.с анг.–М.:
Русская редакция, 2000.–559с.
16. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя:
Пер. с англ. – М.: ДМК, 2000, - 432 с.
17. Кендалл Скотт. Унифицированный процесс. Основные концепции.–
Москва–С–Петербург–Киев, 2002.– 157с.
18. CORBA. The Common Object Request Broker: Architecture and Specification.
Revision 2.0. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc. – 1995. –
621 p.
19. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах
OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510 с.
20. Барлет Н., Лесли А., Симкин С. Программирование на JAVA.
Путеводитель. – Киев. – 1996. – 736 с.
21. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно- ориентированного проектирования. Паттерны проектирования. – СПб:
Питер, 2001. – 368 с.

252
Розділ 9. МОДЕЛІ ЯКОСТІ ТА НАДІЙНОСТІ
ПРОГРАМНИХ СИСТЕМ
Розроблення ПС досягло такого рівня розвитку, що виникла необхідність використання інженерних методів оцінювання результатів проектування на процесах ЖЦ, ризику й ступеня використання готових компонентів для зниження вартості розробки нового проекту та метричного аналізу й контролю досягнутих показників якості. Основою інженерних методів у програмуванні є підвищення якості. Для досягнення цього були сформульовані методи визначення вимог до якості, підходи до вибору й удосконалення моделей метричного аналізу показників якості, методи кількісного виміру ризиків на процесах ЖЦ.
Головна складова якості – надійність, якій приділяється велика увага у сфері надійності технічних засобів і тих критичних систем (реальний час, радарні системи, системи безпеки й ін.), для яких надійність є головною цільовою функцією оцінки їхньої реалізації. Як наслідок у проблематиці надійності розроблено понад сотні математичних моделей надійності, що є функціями помилок, які залишилися в ПС, інтенсивності відмов або частоти виникнення дефектів у ПС. На їхній основі здійснюється оцінка надійності ПС.
Якість ПС – предмет стандартизації. У стандарті ДСТУ 2844–94 наведено визначення якості ПС як сукупності властивостей (показників якості) ПС, що забезпечують його здатність задовольняти потреби замовника відповідно до призначення. Цей стандарт регламентує базову модель якості й показники, головним серед яких є надійність. Стандарт ISO/IEC 12207 визначає не тільки основні процеси ЖЦ розробки ПС, а й організаційні та додаткові процеси, які регламентують інженерію, планування й керування якістю ПС.
Відповідно до стандарту на процесах ЖЦ повинен здійснюватися контроль якості ПС:
 перевірка відповідності вимог до проектованого продукту та критеріїв
їхнього досягнення;
 верифікація й атестація (валідація) проміжних результатів ПС на процесах
ЖЦ і вимірювання ступеня відповідно до певних показників, які досягаються;
 тестування готової ПС, збирання даних про відмови, дефекти й інші помилки, які виявлено у системі;
 підбір моделей надійності для оцінювання надійності за отриманими результатами тестування (дефекти, відмови й ін.);
 оцінка показників якості, заданих у вимогах до розроблення ПС.
Моделі якості й надійності, а також способи їхнього застосування при розробленні систем, будуть розглядатися нижче.