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

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

язык визуального моделирования  с возможностью вставок на программных  языках уровня реализации;

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

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

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

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

Язык  визуального моделирования

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

Язык моделирования – это набор понятий, имеющих имена, атрибуты и отношения друг с другом. Языком моделирования описываются объекты предметной области. Тут уместна объектно-ориентированная аналогия: понятия – это классы, а объекты предметной области – их экземпляры.

Язык моделирования делится  на части, называемые моделями. Разные модели служат для построения различных видов спецификаций системы, выполненных с разных точек зрения (взглядов на систему). В Real существуют следующие виды моделей: модель требований к системе, динамическая модель, статическая модель. Каждая из моделей делится на более мелкие части. Важно отметить, что модели тесно связаны (и иногда пересекаются) между собой – класс из модели классов фигурирует также в поведенческой модели, в модели объектов и т.д.

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

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

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

Почти у каждого значимого элемента языка моделирования имеется  один важный вид атрибутов – пользовательские свойства. Пусть есть необходимость отразить какое-то дополнительное свойство для всех классов в системе, например, что одна их часть транслируется в CORBA-объекты, другая – в COM-объекты. Тогда через механизм пользовательских свойств можно создать специальный атрибут у всех классов и присвоить им определенные строковые значения, например, CL_CORBA или CL_COM. Эти значения можно использовать при генерации конечного кода или при создании каких-либо специфических сервисов внутри самого CASE-средства (например, по-разному отображать классы). Пользовательские свойства позволяют расширять язык моделирования для конкретного технологического решения.

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

Принципы  моделирования

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

Технологическое решение

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

Основные  направления реализации выбранных  стратегий в рамках конкретного  технологического решения:

реализация  связей данного CASE-средства с другими  программными средствами, используемыми  при разработке данной системы;

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

фиксация  дисциплины проекта.

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

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

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

Для выработки  технологического решения необходимо выполнить следующие работы:

реализовать мосты с другими программными продуктами;

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

создать дополнительную документацию к данному технологическому решению;

провести  пилотный проект.

 

 

 Глава 3. Моделирование компонентного ПО

Основная  задача предлагаемой компонентной модели – объединение в единое средство визуального проектирования различных  компонентных стилей. Одни стили основываются на средствах проектирования событийно-ориентированных  систем реального времени (главным  образом, телекоммуникационных). Другие – на распределенных компонентных технологиях типа ActiveX, Java Beans и т.д.

Связь понятий компонентной модели изображена на рис. 13.

При моделировании ПО для систем реального времени целесообразно использовать объекты, имеющие в качестве дополнительных свойств точки входа/выхода. Например, объект ПО управляет каким-то элементом оборудования с n входами и m выходами. При этом, сами входы и выходы являются некоторыми приборами, более простыми, чем данный элемент оборудования, и не нуждающимися в специальном ПО, которое управляло бы их поведением. Входы/выходы можно блокировать, отдельные соединения можно переустанавливать и т.д. Контроль за этими действиями зачастую лежит не на аппаратуре, а на ПО. Следовательно, эта часть оборудования должна быть как-то представлена в ПО системы.

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

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

Компонента

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

Интерфейс

Интерфейс – это описание правил взаимодействия между двумя компонентами. Интерфейс определяется как абстрактный класс. Его члены интерфейса содержатся в секции public; секций private и protected интерфейс не имеет. Между интерфейсами возможно наследование. Интерфейс соединяется с классами через порты.

Интерфейс описывает правила взаимодействия двух объектов, которые его поддерживают. Он может содержать:

набор сообщений  с параметрами и пометкой направления;

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

набор атрибутов  с пометкой направления и правами  доступа (чтение, изменение);

протокол, описанный  при помощи диаграмм взаимодействий.

На рис. 14 приведен пример интерфейса. Сообщение2 и Сообщение3 имеют обратное (back) направление, что обозначается звездочкой рядом с их именами; остальные члены этого интерфейса имеют прямое направление (forward). Интерфейс подключается к порту компоненты. При прямом подключении интерфейса все элементы, имеющие прямое направление, должны посылаться объектом, имеющие обратное направление – приниматься. При обратном подключении интерфейса все происходит наоборот.

 

 

 

 

Заключение

Основными результатами данной диссертационной работы являются:

разработка сквозного  подхода к созданию программного обеспечения с помощью объектно-ориентированных CASE-пакетов – от общей методологии  до технологических решений в конкретных проектов;

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

создание критериев применимости расширенной конечно-автоматной модели при создании систем реального времени  с событийно-управляемой логикой;

создание поведенческой  модели, совмещающей в себе черты  как расширенного конечного автомата SDL (рекомендации комитета ITU), так и STD-диаграмм Харела;

промышленная реализация выработанных подходов в рамках CASE-пакета Real;

апробация методологии и CASE-пакета в реальных проектах.  

 

 

 

 

 

 

 

 

 

 

 

Список  использованной литературы

[1] OMG Unified modeling language spesification (draft). Version 1.3R. http://www.rational.com/uml. 1999.

[2] Ф.П.Брукс мл. Как проектируются и создаются программные комплексы. Мифический человеко-месяц. М. 1979, 150 с.

[3] Booch G. Object-Oriented Analysis And Design With Application, second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.

[4] Чеппел Д. Технологии ActiveX и OLE. М.: Издательский отдел “Русская редакция” ТОО “Channel Trading Ltd.”, 1997, 320с.

[5] J.Rumbaugh, I.Jacobson, G.Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. 550 p.

[6] B.Selic, G.Gullekson, P.T. Ward. Real-Time Object-Oriented Modeling. John Wiley & Sons. Inc. 1994. 525 p.

[7] ITU Recommendation Z.100: Specification and Description Language. 1993. 204 p.

[8] D.Harel, M.Politi. Modeling Reactive Systems with Statecharts: state machine approach. McGraw-Hill. 1998. 258 p.

[9] А.Н.Терехов К.Ю.Романовский, Дм.В.Кознов, П.С.Долгов, А.Н.Иванов. Real: Методология и CASE-средство для разработки систем реального времени и информационных систем // Программирование, 1999, N 5.

[10] Терехов А.Н., Романовский К.Ю, Кознов Дм. В., Долгов П.С., Иванов А.Н. Объектно-ориентированная методология разработки информационных систем и систем реального времени. // Объектно-ориентированное визуальное моделирование / Под ред. Проф. Терехова А.Н. – СПб: Издательство С.-Петербургского университета, 1999. С.4-20.