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

Интерфейс и порт

Для того, чтобы было можно определять на уровне типов возможность взаимодействия их экземпляров, в SDL-92 для типов блоков, процессов и служб было введено понятие порта (gate), имеющее следующие атрибуты:

имя;

список входных сообщений;

список выходных сообщений;

входные и выходные ограничители (constraint);

признак добавления.

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

Входные и выходные ограничители порта накладывают дополнительные условия на тип объекта – партнера связи по этому порту. Тип партнера можно задать точно, указав его имя. Можно ослабить это ограничение, указав, что партнером может быть любой объект, чей тип является подтипом (subtype) данного типа.

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

Конечный автомат SDL может  “видеть” порты всех тех контекстов, в которые он входит. Более того, при посылке сигнала можно  указывать полный путь (порты, сигнальные маршруты, каналы) к получателю, который  является подмножеством всех возможных  путей к процессу-получателю. Таким  образом, данный сигнал может посылаться из этого процесса через разные порты  и идти по разным путям. При этом возможны два крайних варианта:

указан процесс-адресат, но не указан путь, и существует множество  возможных путей; тогда система  сама должна выбирать путь к получателю; указано множество путей, но не указан идентификатор процесса-получателя; тогда получателем будет произвольный процесс, достижимый по одному из этих путей. Кроме механизма пересылки  сообщений в SDL существуют другие средства общения процессов – удаленные процедуры и операции импорта экспорта переменных (так называемых внешних переменных). Таким образом, процесс может вызвать процедуру другого процесса или запросить значение некоторой его переменной, но для этого и процедура, и переменная должны быть описаны в обоих процессах специфическим способом. При этом как сам вызов, так и обработка этого вызова происходят специальным способом, с учетом состояния, в котором находится процесс-сервер.

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

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

Поведенческая модель

Расширенный конечный автомат SDL является способом спецификации поведения  процесса и его составных частей – служб и процедур – и, за исключением некоторых деталей, состоит из следующих частей:

cимвол начала;

набор состояний с возможными переходами;

набор свободных действий.

 

Находясь в состоянии, объект ожидает, когда в его входную  очередь поступит очередное сообщение, после чего он запускает переход-обработчик, связанный с этим сообщением. Если в состоянии не предусмотрен переход-обработчик для данного сообщения, то оно  теряется. Для того, чтобы была возможность сохранять сообщения, обработка которых не предусмотрена в данном состоянии, существует специальная конструкция save – во время просмотра очереди сообщений объект, находясь в данном состоянии, "не заметит" сообщение, помеченное этой конструкцией, оставив его в начале очереди. Оно превратится в видимое только в следующем состоянии, если и там не будет помечено как сохраняемое.

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

Имеются также метки и  конструкции, осуществляющих переходы по ним (аналог оператора goto в языках программирования). Если по тем или иным причинам хочется разбить переход на части (например, он получился слишком большим и не помещается на одной диаграмме), то его можно завершить меткой (соединителем), а на другой диаграмме начать с метки, имеющей такое же имя. Переходы, которые “растут” из меток, называются свободными действиями.

В SDL нет сложных состояний (т.е. состояний, содержащих другие состояния), однако существуют другие средства декомпозиции конечного автомата – службы и  процедуры.

Процесс вместо расширенного конечного автомата может содержать  набор служб (services), каждая из которых сама является расширенным конечным автоматом. Службы внутри процесса выполняются синхронно – т.е. в любой момент времени работает только одна из них, а все остальные ждут. Если поведение системы принципиально асинхронно, то для его моделирования нужно заводить разные объекты (и службы не нужны), если же параллелизм не является необходимым, но систему удобно разбить на несколько объектов, то в SDL это можно промоделировать службами в рамках одного объекта. Таким образом, службы можно считать специальными объектами, которые агрегируются другим объектом.

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

Кроме того, в SDL существуют и другие средства для декомпозиции автомата – групповые утверждения  о состояниях:

при получении сообщения A в состояниях S1, S2, S3 выполнить переход T1;

при получении сообщения A во всех состояниях выполнить переход T2;

при получении сообщения A во всех состояниях, кроме S1, S2, S3, выполнить  переход T3.

То же самое можно делать и с сообщениями.

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

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

process A;

Dcl a,b,c Integer;

start

task: a = 1;

call: proc1(in a, out b);

decision a<b;

(True): stop;

(False): task: b = b+1;

return;

enddecision;

stop;

endprocess A;

Однако использование SDL в качестве обычного языка программирования сильно ограничено отсутствием таких  конструкций, как цикл, массив, указатель  и пр. SDL является модельным языком, с его помощью нельзя запрограммировать  сложную систему целиком (подробнее  об этом см. [22]). Расширенный конечный автомат SDL предназначен для спецификации поведения объектов в сложных телекоммуникационных алгоритмах. Поэтому, в частности, в нем предусмотрена возможность вставок текстов на произвольном, не интерпретируемом самим SDL, языке.

 

Глава 2. Методология CASE-пакета

Внедрение CASE-пакета является сложной задачей. Во-первых, CASE-пакет  встраивается, как правило, в текущий  производственный процесс. Во-вторых, пакет осваивается уже сложившимся коллективом, имеющим иерархию, устоявшийся уклад работы. В-третьих, CASE-пакет должен сочетаться с уже освоенными, досконально изученными программными средствами (компиляторами, СУБД, наработками в виде переиспользуемых библиотек и т.д.). CASE-пакет привносит иные способы анализа, проектирования, документирования и сопровождения системы, а также – и это важно – существенным образом меняет процесс программирования (автоматическая генерация части программного кода по графических диаграммам, смешанные графическо-текстовые спецификации и т.д.). Внедрение CASE-пакета (в отличие, например, от нового компилятора) подразумевает существенную перестройку производственного процесса – реинжениринг. Можно обратиться к литературе по реинженирингу бизнеса и увидеть, что это – отдельная и трудоемкая область деятельности. Особенности данной задачи в контексте компьютерной инженерии обсуждаются.

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

Методология визуального  моделирования ПО, определение основных сервисов CASE-пакета и описание его  типовой архитектуры, а также  рекомендации по применению являются методологией CASE-пакета.

Основными положениями методологии CASE-пакета являются:

Предназначение визуального  моделирования и определение CASE-пакета.

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

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

Принципы моделирования  – общий порядок использования  языка и различных его частей (моделей).

Правила работы с CASE-пакетом.

Фиксированные типы стратегий  использования языка визуального  моделирования и CASE-пакета с возможностью создавать новые стратегии для  конкретного класса задач или  отдельного проекта.

Понятие "технологическое  решение", которое означает реализацию выбранных стратегий использования CASE-пакета применительно к конкретному  производственному процессу.

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

Предназначение  визуального моделирования и  определение CASE-пакета

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

Таким образом, CASE-пакет как  инструмент поддержки визуального  моделирования, должен предоставлять  следующие сервисы:

средства графического моделирования (графические редакторы);

средства поддержания  корректности и связности графических  спецификаций;

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

внешние сервисные утилиты (желательно, с исходными текстами);

средства работы со многими  проектами;

многопользовательский режим  работы;

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

средства автоматической кодогенерации для различных платформ;

средства возвратного  проектирования (reverse engineering);

средства генерации документации.

Архитектура CASE-пакета, как  правило, состоит из следующих частей (рис. 11):

ядро, которое содержит графические  редакторы, объединенные в общую  оболочку;

репозиторий, в котором хранится разрабатываемый проект;

внешние сервисные пакеты, которые реализуют проектно-зависимые  возможности (генераторы текстовой  документации по моделям, средства возвратного  проектирования и т.д.) и могут  меняться от одного технологического решения к другому; сервисные  пакеты связываются с ядром CASE-пакета и репозиторием через специальный интерфейс.

Общая философии использования визуального моделирования в рамках CASE-пакета требует отдельного описания. На рис. 12 изображен принцип представления информации о разрабатываемой системе. Он имеет два измерения. Первое соответствует точкам зрения (view) на систему в UML. Второе определяет три уровня информации о системе – описания, схемы, программный код.

Принцип представления информации о разрабатываемой  системе с точки зрения визуального  моделирования 

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

Схемы описывают каркас приложения – структуру классов системы, таблиц базы данных и т.д. Этот уровень, как правило, тесно связан с уровнем реализации через автоматическую генерацию текстов программ, возвратное проектирование, другие стратегии внесения изменений в проект с сохранением актуальными спецификаций обоих уровней. Если схема приложения определяется только на описательном уровне (т.е. в виде документов) или ее связь с уровнем реализации разовая (только через начальную water-fall генерацию), то сопровождение приложения остается проблемой, которую не решает используемое в данном случае CASE-средство.

Важность схем заключается в  том, что почти всегда, когда говорится  об автоматической генерации конечного  кода по визуальным моделям, подразумевается  генерация именно схемы приложения. Совершенно очевидным является факт, что огромные объемы программных  текстов нельзя представить в  графическом виде. В то же время  на диаграммах удобно показывать “скелет” ПО – его схему, по которой можно  легко ориентироваться в приложении, изменять его архитектуру. Для дополнения схемы ПО на уровне визуального моделирования так, чтобы по ней была возможна генерация целиком кода системы (или подсистемы), существуют следующие способы: