Визуальное компонентное программирование

Язык UML развивается с 1994 года и  является результатом слияния трех самых известных объектно-ориентированных  подходов: метода Буча, OMT  и OOSE . В 1997 году UML был принят в качестве стандарта комитетом OMG и практически заменил собой остальные объектно-ориентированные подходы. UML является грандиозной попыткой выработать на основе объектно-ориентированного подхода универсальный язык графического моделирования для анализа проектированию сложных компьютерных систем. Он объединяет большое количество различных графических нотаций с целью упорядочивания хаотического набора графических средств, используемых при создании ПО. Стандартизация здесь существенно повышает уровень понимания между различными специалистами, разрабатывающими сложную систему. Кроме того, стандарт облегчает переносимость спецификаций, выполненных в разных CASE-пакетах.

Ниже кратко рассматриваются понятия UML, на которых основаны средства структурной  декомпозиции проекта и разрабатываемой  системы.

Пакет – это подпространство  имен проекта, которое состоит из набора сущностей, выраженных c помощью понятий и диаграмм UML. Пакеты могут включать в себя другие пакеты.

Модель – это тип пакета, представляющий собой определенный законченный  образ системы, описывающий ее с  какой-либо точки зрения. Например, для разрабатываемой системы  можно построить модель случаев  использования, которая будет определять функциональные требования к ней.

Точка зрения – это определенный способ видения системы, исходя из которого строится определенная модель системы. Точка зрения включает в себя набор графических нотаций и их семантику. Выделяются следующие точки зрения на систему: статическая, случаев использования, взаимодействий, конечно-автоматная, активностей, физическая, управляющая.

Подсистема – это вид пакета, который описывает определенную часть системы, выделенную в единое целое по реализационным или функциональным соображениям. Структура подсистемы делится на две части – декларативную  и реализационную. Первая определяет внешнее поведение подсистемы и  может включать в себя случаи использования, интерфейсы и т.д. Реализационная часть  описывает то, каким образом реализуется  декларативная часть.

Подсистема аналогична блоку в SDL, однако в целом система понятий UML более общая, чем в SDL.

Методология ROOM (Real-time Object-Oriented Modeling)

Real-Time Object-Oriented Modeling (ROOM) – это объектно-ориентированная методология разработки систем реального времени. Она развивается канадской фирмой ObjecTime Limited, которая на основе этой методологии выпустила программный продукт ObjecTime. Методология была анонсирована в 1992 году. В 1994 году в свет вышла монография, содержащая полное описание ROOM. Эти работы являются базисом для создания мостов между программными продуктами, реализующими ROOM и UML.

ROOM содержит два уровня  представления разрабатываемой  системы:

уровень схем;

уровень детализации.

Выделение этих уровней нацелено на автоматическую кодогенерацию. Таким образом, данная методология существенно отличается от UML, где предлагаются лишь точки зрения на систему (view), применение которых не вполне понятно. Для уровня схем ROOM предлагает набор графических нотаций. Уровень детализации предполагает использование языка реализации, поскольку очевидно, что всю систему, если она достаточно сложна, не специфицировать в виде картинок, по которым можно автоматически сгенерировать работающую программу.

Уровень схем состоит из графических нотаций для представления  структуры системы (классов и  объектов) и описания ее поведенческой  модели.

Метод RUP (Rational Unified Process)

UML является только языком  моделирования. Способы применения  вынесены из его спецификации  в отличие от предшествовавших  ему подходов. Компания Rational Corp. создала надстройку над UML под названием RUP [35], которая систематизирует процесс создания ПО на основе UML, предлагая при этом использовать определенный набор программных продуктов (главным образом, компании Rational Corp.).

Структура метода RUP представлена на рис. 2.

Фазы
Основные рабочие процессы (Core Workflows)	Начало (Inception)	Детализация (elaboration)	Конструирование (сonstruction)	Передача (transition)
Бизнес–моделирование (Business Modeling)
Требования (Requirements)
Анализ и проектирование (Analysis and Design)
Реализация (Implementation)
Тестирование  (Testing)
Внедрение системы (Deployment)
Вспомогательные рабочие  процессы (Supporting Workflows)
Управление проектом (Project Management)
Конфигурационное управление и управление изменениями (Configuration and Change Management)
Окружение (Environment)

 

 

Фаза – это этап разработки системы. С ней, как правило, связана  промежуточная или окончательная  отчетность по проекту. RUP выделяет следующий  набор фаз:

Начало – фаза, во время  которой происходит выделение границ проекта, оценка реальности его выполнения (сроки, планы, деньги, люди, риски).

Детализация – на этой фазе происходит создание архитектурного прототипа  системы, определяются требований к  проекту, его цена и срок исполнения, составляется подробный план работы.

Конструирование – фаза реализации проекта.

Передача – фаза передачи системы заказчику.

Цикл разработки системы  завершается после выполнения последней  фазы, в результате чего появляется новая версия системы. После этого  процесс разработки продолжается уже  на новом уровне вследствие возникновения  новых требованиями к системе и завершается выпуском очередной версии.

Метод RUP допускает итеративность  внутри одной фазы. Как правило, результатом  итерации является прототип системы. Приводятся следующие варианты количества итераций по фазам: [0,1,1,1], [1,2,2,1], [1,3,3,2]. Таким образом, формулируется общее правило  о количестве итераций внутри одного цикла: 6 плюс/минус 3.

Понятие фазы является подходящей абстракцией для выделения этапов разработки системы. Это понятие  согласует итеративный процесс  разработки ПО и линейный порядок  отчетности.

Разработка системы проходит через эти четыре фазы с помощью  рабочих процессов (workflow), которые представляют собой последовательности действий, связанных общей спецификой. Рабочие процессы распределяются по различным фазам и, в отличие от последних, могут проходить параллельно.

Определение CASE-пакета

CASE-пакет является программным  продуктом, реализующим определенный  подход компьютерной инженерии.  В работе [36] дается следующие определение:

“Под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения  информационных систем, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.”

В этой же работе определяются основные компоненты CASE-пакета:

репозиторий;

графические редакторы;

средства разработки готовых  приложений, включая генераторы конечного  кода по диаграммам;

средства конфигурационного  управления проектом;

средства документирования проекта;

средства тестирования;

средства управления проектом;

средства реинжениринга.

Компонентные  системы

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

С бурным развитием сетей  понятие компоненты при создании, сопровождении и эксплуатации ПО приобрело глобальный и достаточно универсальный характер. Вот несколько примеров того, какие понятия различных сред программирования можно сопоставить компонентам:

CORBA- и COM-объекты; 

переиспользуемые динамически связываемые библиотеки с интерфейсами доступных функций на С, С++, Pascal;

Java- и C++-классы.

Понятие компоненты широко используется в различных предметных областях, например:

при создании распределенных сетевых приложений ПО удобно представлять в виде набора взаимодействующих  компонент, работающих на разных компьютерах  и на разных платформах (например, на Windows и QNX);

при разработке систем на основе эталонной семиуровневой модели ISO/OSI, адаптируемой для различных  телекоммуникационных стандартов (ISDN, ATM т.д.), понятие компоненты удобно использовать при моделирования уровней и функциональных сущностей.

Понятиями компоненты и интерфейса удобно пользоваться при групповой  разработке ПО – каждая группа реализует свою компоненту. При выделении таких компонент могут доминировать различные мотивации – от функциональной замкнутости подзадачи до территориальной или языковой изолированности группы разработчиков. Примером такой формализации компоненты служит подсистема в UML. На практике часто происходит смешение этих мотиваций в различных пропорциях.

Системы реального времени

Системы реального времени  являются одним из самых важных классов  программного обеспечения. Они определяются как системы, имеющие жесткие временные ограничения. При этом выделяются системы on-line, к которым относятся, в частности, многие бизнес-приложения например, система заказа авиабилетов, которая имеет много рабочих мест и должна быстро обрабатывать большое число запросов), и ПО для встроенных систем управления каким-либо оборудованием (embedded systems).

степень требуемой надежность систем – например, при создании системы управления атомным реактором  требуются особые усилия по обеспечению  безотказной работы; отмечается, что  системы со строгими временными ограничениями  не всегда являются надежными в этом смысле;

размер системы и “плотность”  взаимодействия между ее компонентами;

характеристики окружения, в котором система должна работать – например, неизведанное и непредсказуемое  космическое пространство для космических  кораблей, запускаемых за пределы  солнечной системы, или погодные показания для метеорологической  системы, масштабы изменения которых известны.

В монографии определяется область применимости методологии ROOM (Real-Time Object-Oriented Modeling). Определяются те характерные свойства системы, при наличии которых ROOM может успешно применяться:

временная зависимость (timeliness) процессов системы;

динамический характер внутренней структуры системы;

реактивность системы (в  значении первого пункта определения  реактивной системы Харела);

параллельность;

распределенность.

Обзор существующих подходов к проектированию компонентного ПО с применением расширенных конечных автоматов

В качестве основы компонентного  подхода выделяются следующие понятия:

компонента – это независимый, заменяемый, тиражируемый и переиспользуемый элемент ПО;

порт – это точка  входа в компоненту извне;

интерфейс – это описание правил взаимодействия компоненты с  внешним миром, который подключается к компоненте через порт.

Ниже рассматривается, в  каком виде в разных объектно-ориентированных  методологиях присутствуют эти понятия. Кроме того, в этих подходах выделяются также различные варианты поведенческой  модели как средства описания поведения  компонент.

Язык SDL

Компонента

Изначально SDL не был объектно-ориентированным. Программа на этом языке представляет собой последовательность вложенных  систем, блоков, процессов, являющихся различного вида контекстами (см. рис. 3).

В версии SDL 1992 года появились  объектно-ориентированные черты. Для  различных видов контекстов появились  типы. Для экземпляров типов предусмотрена  возможность группового описания. На рис. 4 определен тип блока BlockingStation и множество (100 шт.) объектов этого типа по имени bls, каждый из которых связан с блоком CenralUnit.

Для типов в SDL-92 есть наследование. Так, если в рассмотренном выше примере  тип блока BlockingStation является наследником типа блока LocalStation, то описание BlockingStation будет выглядеть способом, представленном на рис.5.

Следует отметить, что в SDL/GR нет графических способов изображения  связей между типами, а в UML они  существуют для ассоциаций и наследования. По отношению к UML SDL/GR можно считать  смесью диаграмм классов и диаграмм взаимодействий.

В SDL cуществует дополнительный, по сравнению с обычными языками программирования, способ общения между контекстами – через механизм передачи сообщений. Блоки одного уровня вложенности могут связываться друг с другом каналами, а процессы – сигнальными маршрутами. Основным средством адресации сообщений в SDL является имя процесса-получателя, а не канал. Каналы и сигнальные маршруты используются в большинстве случаев для наглядных графических спецификаций системы.

Сообщения определяются на правах переменных или методов в  контекстах и их доступность определяется стандартными правилами видимости. Кроме сообщений в контекстах можно определять переменные и некоторые другие сущности.