Специальные аспекты компонентно-базированной разработки программного обеспечения
Jozsef Tick
tick@bmf.hu
Перевод с английского: Стародубцев Д.Н.
Источник: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.2837&rep=rep1&type=pdf
Аннотация: компонентно-базированная разработка программного обеспечения (КБРПО) представляет собой новое решение в области разработки программного обеспечения на проблему создания крупных программных продуктов. Системы, разработанные этим методом, являются более стабильными, они имеют более высокое качество, они дешевле и лучше удовлетворяют требованиям. Эта статья рассматривает роль и значение компонентно-базированной разработки программного обеспечения в эволюции методологии программного обеспечения; и в ней проводится анализ специальных аспектов обучения программированию в системе высшего образования.
Ключевые слова: Инженерия Разработки ПО, Компонентно-базированная Разработка ПО
1 Введение
Практически последние 60 лет в разработке программного обеспечения все говорят об истории задач и ответах на эти задачи, в данном случае о парадигмах программирования, а также о методологии разработки. Спрос на разработку всё более крупного и сложного программного обеспечения требует описания программного обеспечения на более высоком уровне абстракции. Значительное расширение аппаратных и программных ресурсов делает возможной разработку всё более сложных проектов. Новейшим шагом в этом развитии является Компонентно-базированная Разработка Программного Обеспечения (КБРПО), а его методология базируется на Компонентно-базированной Инженерии Программного Обеспечения (КБИПО).
Давайте разберём принцип КБРПО на примере. Нам нужен компьютер, который отвечает нашим специальным требованиям. Мы можем выбрать одну из сотен материнских, соответствующую нашим требованиям, просмотрев каталоги. Интерфейсы будут четко определены, каждый модуль поддерживает коммуникационные протоколы, и функции тоже четко определены. Нам не нужно олово, нам не нужны ИС, мы можем собирать большие компоненты, опираясь на предыдущие разработки, которые уже протестированы и имеют хорошее качество. КБРПО проделывает нечто подобное. Программные комплексы могут быть разработаны при помощи сборки ранее разработанных, сложных компонент, а не с использованием языка программирования.
2 Этапы развития от Спагетти-кода до компонентно-базированной разработки ПО
Развитие является непрерывным и последовательным. Можно выделить множество фаз, однако, было несколько основных поворотов в развитии, тупиков и счастливых историй, которые стоит отметить. Категории определяются добровольно, и в соответствии с ними можно выделить следующие основные этапы и тенденции:
2.1 Парадигма «Спагетти-код»
После завершения этапа сборочного программирования, который следовал за эпохой программирования на машинном уровне, появление языков высокого уровня было прорывом. Но всё-таки эти языки имели очень маленький инструментарий, их структура управления была сложна для обзора, решение больших задач было трудно реализуемым и тяжелым в управлении.
2.2 Парадигма «Разделяй и властвуй»
Этот принцип очевиден и ясен, задача слишком большая и сложная, и она должна разбиваться на более мелкие части и после реализации конкретных модулей, эти мелкие детали должны быть интегрированы в один большой проект. Естественно, чтобы решить эту проблему, решающим было появление таких языков программирования, которые могли бы подразделять программы на более мелкие части, подпрограммы, функции, процедуры, модули. Этот метод помогает уменьшить сложность, однако, после определенного размера, сама система становится сложной и трудно управляемой.
2.3 Парадигма «Мир структурирован»
Структурированное программирование и структурированный подход укрепились с 70-х годов. Работа Дейкстры была указателем, появление JSP Джексона, а также появление PASCAL [1] Вирта и ADA способствовало в значительной степени к практической реализации.
Помимо программирования, структурированный подход успешно применялся и в других областях разработки программного обеспечения, анализа и планирования. Следует отметить Мишеля Джексона [2], затем Де Марко [3], Стивенса, Майерса, Константина [4] и Йордана [5]. Для дополнения списка должны быть упомянуты методология Гейна, Соуркон и Варньер, Орр.
2.4 Парадигма «Думайте объектно-ориентировано»
Парадигма, которая пришла вслед за структурным программированием. Она установила программирование на еще более высокий уровень абстракции. Благодаря интеграции данных и операций над этими данными получилось объединить их в органические единицы. Для распространения объектно-ориентированной парадигмы, требовалось развитие техники, благодаря которому мы сейчас используем высокоэффективный языки (C++, Java), которые развились из примитивных языков программирования.
В инженерии объектно-ориентированного программного обеспечения, первую значительную методологию опубликовал Буч [6]. Позже появилось множество методик, но следующей важной методологией, которая больше всех распространилась на практике, была «Объектно-ориентированный анализ и проектирование» начатая Коед-Йорданом, [7] [8], а завершённая позже Якобсоном [9]. Кроме того была разработана и внедрена методология Ребекки Вирфс-Брок [10]. «Техника моделирования объекта», опубликованная Рейнбоу, и др. [11] был первым популярным и широко используемым методом основанном на моделировании, который предшествовал более позднему и наиболее успешному в наши дни «Техники унифицированного моделирования» [12] .
2.5 Компонентно-базированные технологии
Дальнейшее развитие парадигм дало жизнь старо-новой технологии. Основные принципы разработки компонентно-базированного программного обеспечения вовсе не новы. Впервые они были предложены на знаменитой конференции НАТО посвящённой инженерии программного обеспечения в 1968 году в г. Гармише (Германия). Объектно-ориентированные технологии дали новый импульс к развитию в разработке и использовании компонент.
Объектно-ориентированные принципы могут обеспечить определение компонент, заблаговременную реализацию компонент и наиболее эффективное повторное использование компонент. Компоненты – это не простые объекты, компоненты – это более сложные модули. Если взять в качестве примера электронику, то это ИС с интегрированным программным обеспечением (SW-IC), или даже модули более высокого уровня (PC-карты). Существуют мнения, что внедрение компонент означает не только более высокий уровень абстракции, а рождение новой парадигмы программирования (компонентно-ориентированная или компонентно0базированная парадигма программирования).
3 Методология компонентно-базированной разработки программного обеспечения (КБРПО)
3.1 Основные преимущества метода КБРПО
Компонентно-базированная разработка программного обеспечения делает возможной реализацию крупных систем программного обеспечения, путём монтажа ранее разработанных компонент. Наиболее важные особенности этой методики приведены ниже:
- Это значительно снижает общую стоимость разработки системы.
- Это существенно уменьшает время разработки системы.
- Качество и надежность системы в целом улучшаются благодаря хорошему качеству разработанных ранее и повторно используемых компонент.
- Уход, обслуживание, усовершенствование программного обеспечения системы становятся дешевле, быстрее и безопаснее за счет простой замены компонент.
- Приоритет в разработке программного обеспечения растёт, начиная с создания программного обеспечения и заканчивая интеграцией компонент и созданием из больших ещё более сложных модулей.
- Высокий уровень абстракции делает возможным создание еще более крупных и более сложных систем.
3.2 Подход метода КБРПО
Согласно Брауну [13] подход КБРПО имеет четыре основных фазы:
- Квалификация компонент
- Адаптация компонент
- Сбор системы из компонент
- Эволюция системы
3.2.1 Квалификация компонент
Квалификацией компонент является процесс определения "пригодности для использования" ранее разработанных компонент в условиях новой системы. Кроме того, это процесс выбора компонент, если таковые существуют на рынке (решение о покупке).
Квалификация компонент состоит из двух этапов:
- Этап рассмотрения, для определения свойств каждой компоненты (какой тип компонент нам требуется для решения проблемы)
- Этап оценки, для выбора из группы похожих продуктов (какие компоненты из данного множества могут решить поставленную задачу)
Фаза квалификации компонент является крайне критическим этапом в отношении качества системы в период разработки.
3.2.2 Адаптация компонент
В некоторых случаях существующие компоненты, не полностью соответствуют требованиям новой системы, поэтому становится необходимой их адаптация.
ПО Валето [14] существует 3 подхода в адаптации компонент в зависимости от того, насколько является доступной её внутренняя структура:
- Подход белой коробки (исходный код компоненты будет значительно изменён)
- Подход серого ящика (исходный код компонента не изменяется, но компонент предоставляет свой API (Application Programming Interface))
- Подход чёрного ящика (доступен только бинарный код компонента, и нет даже API)
3.2.3 Сборка системы из компонент
На этом этапе описывается, как интегрировать предварительно отобранные компоненты в новую систему, как производить их сборку. Существуют более архитектурные стили разработки системы с использованием существующих компонент, например, такие как Посредник объектных запросов (Object Request Broker — ORB). ORB является промежуточной технологией, которая управляет связями и передачей данных между распределенными объектами в системе.
3.2.4 Эволюция системы
Компонентно-базированные системы, оказывается, довольно легко развиваются, потому что исправление ошибок в данном случае означает "просто" замену дефектной компоненты. Аналогично, когда требуется добавить новые функции, это может быть реализовано с помощью новой компоненты, которую требуется "только" добавить в систему.
Это видение весьма оптимистично. На практике "изменение или модификация" означает всегда потенциальный источник ошибок. Компоненты должны быть отдельно испытаны, но при таких же условиях, при каких бы они работали вместе с другими компонентами системы.
3.3 Реализации КБРПО
3.3.1 «Линия Microsoft»
Microsoft предоставляет технологию COM (Component Object Model) для программных компонент. В Windows 2000 было реализовано важное расширение COM, COM+. COM + может запускаться в компонентном пространстве управляемым Microsoft Transaction Server. Распределенной версией COM является DCOM, которая представляет собой технологию для программных компонент распределенных по нескольким сетевым компьютерам. В 2002 году был выпущен .NET, который представляет собой независимое от платформы средство для разработки программного обеспечения. Он полностью опирается на программные компоненты и компонентно-ориентированную парадигму программирования. Microsoft чётко заявила, что .NET заменит COM как компонентную архитектуру программного обеспечения.
3.3.2 «Линия Sun»
История успеха Java также основывается на компонентно-базированной разработке. Основной принцип Java изначально состоял в развитии сетевых, распределенных приложений. Реакцией Sun в КБРПО был выпуск Enterprise Java Beans (EJB). EJB архитектура является компонентно-базированной архитектурой для разработки и развертывания компонентных объектов. Приложения, написанные по спецификации EJB, являются масштабируемыми, поддерживающими транзакции и защищёнными, они могут быть развёрнуты на любой платформе, поддерживающей EJB. Архитектура EJB будет основываться на стандартных компонентах и разработанных Вами со сторонним производителем компонентах в одном приложении.
3.3.3 "Линия OMG"
Продуктом Object Management Group (OMG) является Common Request Broker Architecture (CORBA), который представляет собой инфраструктуру для обработки компонент (объектов). Она обеспечивает механизм связи между распределенными объектами. Interface Definition Language (IDL) от OMG описывает службы объектов. Большим преимуществом является то, что определение интерфейса не зависит от языка программирования, но оно устанавливается для всех популярных языков программирования, которые поддерживают стандарт OMG (C, C + +, Java, COBOL, Smalltalk, Ada, Lisp, Python, IDLscript).
4 Специальные аспекты компонентно-базированной разработки программного обеспечения
Особым аспектом приведённого обзора являются особенности компонентно-базированных приложений в программной инженерии высших учебных заведений. Выше было четко определено, что компонентно-базированная разработка программного обеспечения имеет много положительных характеристик и применение таких приложений в индустрии программного обеспечения постоянно растет. Параллельно, образование — в соответствии с требованием промышленности – должно использовать КБРПО. Тем не менее, применение КБРПО в области образования имеет специальные аспекты:
- Во-первых, КБРПО может быть хорошо адаптирована в разработке больших систем, которые — в отношении их размера — не могут быть использованы в качестве проектов, выполненных студентами.
- Для того чтобы получить практические знания и изучать приемы и хитрости, целесообразно вводить тематические исследования, в которых подзадачи могут использоваться в качестве задач для студентов.
- КБРПО приложения взаимодействуют с разработкой программного обеспечения на более высоком уровне абстракции, что может создавать у студентов без надлежащего предварительного обучения программированию ложные представления о том, что разработка программного обеспечения означает только построение из кирпичей Lego.
- При использовании техники Components Of The Shelf (COTS) сложность, точное описание и количество компонент делают выбор надлежащей компоненты достаточно сложным, поэтому довольно сложно представить реальную жизненную ситуацию в сфере образования.
- Изучение технологий, делающих возможной реализацию КБРПО (Линия Microsoft, Линия Sun, Линия OMG), требует подготовки и множества знаний, таким образом, стартовый уровень является относительно высоким, что в некоторых случаях отодвигает студентов от технической адаптации.
- Образование должно быть беспристрастным, а это означает, что оно должно держать на одинаковом расстоянии от себя все методологические тенденции, а это значит, что оно должно дать возможность каждой технологии, хотя бы факультативно, представить себя. Что касается начального уровня для каждой технологии и трудностей, связанных с ними, это не легко.
- Огромные ресурсы, использующиеся технологиями, являются препятствием для создания проекта в случае отдельного студента. Достаточно сложно обеспечить доступ к ним для студентов в случае выполнения диссертаций, научных студенческих проектов и т.д.
Выводы
Подводя итог, можно сказать, что компонентно-базированная разработка программного обеспечения является современным и все более распространённым решением в индустрии программного обеспечения. В ответ на спрос в индустрии ей должно быть обеспечено место в системе высшего образования. Применение все более сложных и больших систем, — таких как КБРПО-системы — в образовании не является лёгкой задачей, а вызывает множество вопросов, решение которых является неотложной задачей в ближайшем будущем.
Список использованной литературы
[1] Jensen, K., Wirth, N.: PASCAL – User Manual and Report Springer Verlag, 1974
[2] Jackson, M.: Principles of Program Design Academic Press, 1975
[3] DeMarco, T.: Structured Analysis and System Specification Prentice-Hall, 1979
[4] Stevens, W. P., Myers, G. J., Constantine, L. L.: Structured Design IBM Systems Journal, vol.13, no. 2, 1974
[5] Yourdon, E. N., Constantine, L. L.: Structured Design Yourdon Press, New York, 1978
[6] Booch, G.: Object Oriented Design with Applications The Benjamin/Cummings Publishing Company, Redwood City 1991
[7] Coad, P., Yourdon, E.: Object-Oriented Analysis Yourdon Press, New York, 1991
[8] Coad, P., Yourdon E.: Object-Oriented Design Yourdon Press, New York 1991
[9] Jacobson, I., Christerson, M., Jonsson, P., Oevergaard, G.: Object-Oriented Software Engineering – A Use Case Driven Approach Addison Wesley, 1992
[10] Wirfs-Brock, R., Wilkerson, B., Wiener, L.: Designing Object-Oriented Software Prentice Hall PTR, Englewood Cliffs, New Jersey, 1990
[11] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object-Oriented Modelling And Design Prentice Hall International Edition, 1991
[12] Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual Addison Wesley, 1998
[13] Brown, A. W., Wallnau, K. C.: Engineering of Component-Based Systems IEEE Computer Society Press, 1996.
[14] Valetto, G., Kaiser, G. E.: Enveloping Sophisticated Tools into Computer-Aided Software Engineering Environments Proceedings of the 7th IEEE International Workshop on CASE, Toronto, Ontario, Canada, July 10-14, 1995, pp. 40-48.