Диссертация (1145120), страница 57
Текст из файла (страница 57)
Для моделирования структурытелекоммуникационной системы Real предлагает расширение диаграммыклассов в виде компонент интерфейсов и портов.Компонента — это независимый элемент ПО, скрывающий свою реализацию и взаимодействующий с внешним миром через интерфейсы. Компонентаможет быть переиспользована в различных приложениях и способна функционировать независимо от использующего её окружения. Кроме того, онаможет тиражироваться и заменяться другими компонентами, имеющими тотже внешний интерфейс. В модели классов Real является классом, имеющимпорты и не содержащим public-секцию (поскольку всё взаимодействие свнешним миром осуществляется через интерфейсы).
В private-секции компоненты могут располагаться её внутренние методы и переменные. Секцияprotected нужна для того, чтобы при наследовании компонент элементы«предка» были доступны «потомку».353Интерфейс — это описание правил взаимодействия между двумя компонентами. Интерфейс определяется как абстрактный класс. Его члены содержатся в секции public; секций private и protected интерфейс не имеет. Междуинтерфейсами возможно наследование. Интерфейс соединяется с классамичерез порты.Интерфейс описывает правила взаимодействия двух объектов, которые егоподдерживают. Он может содержать: набор сообщений с параметрами и пометкой направления; набор методов с параметрами и пометкой направления; набор атрибутов с пометкой направления и правами доступа (чтение,изменение); протокол, описанный при помощи диаграмм взаимодействий.ИнтерфейсСообщение1;Сообщение2*;Сообщение3*;Метод1();Метод2();Метод3();Атрибут1;Атрибут2;Атрибут3;Рис.
5.29. Пример интерфейса в RealНа рис. 5.29 приведён пример интерфейса. «Сообщение2» и «Сообщение3»имеют обратное (back) направление, что обозначается звездочкой рядом с ихименами; остальные члены этого интерфейса имеют прямое направление(forward). Интерфейс подключается к порту компоненты. При прямом подключении интерфейса все элементы, имеющие прямое направление, должныпосылаться объектом, имеющие обратное направление — приниматься.
Приобратном подключении интерфейса все происходит наоборот. Между интер354фейсами возможно только наследование. Никаких других связей между нимибыть не может. Наследование между интерфейсами имеет дополнительныйпараметр — направление: «прямое» (forward) — тогда все содержимое интерфейса-предка добавляется к содержимому интерфейса-потомка, и «обратное» (back) — тогда в интерфейсе-предке направления всех его членов придобавлении в интерфейс-предок меняются на противоположные.
По умолчанию этот параметр имеет значение «прямое».Остановимся на элементе интерфейса под названием протокол. Протоколявляется спецификацией алгоритма взаимодействия, для которого предназначен данный интерфейс. Реализация этого алгоритма должна содержаться вобеих компонентах, которые будут подключать этот интерфейс. Протоколзадаётся с помощью диаграммы сценариев (модель взаимодействия). В протоколе нецелесообразно определять все цепочки обмена событиями междудвумя сторонами, поскольку даже если количество сообщений интерфейса вобе стороны не превышает десяти, количество приемлемых цепочек различной длины может исчисляться тысячами.
Сложные протоколы целесообразно специфицировать с помощью расширенных конечных автоматов для каждой компоненты в отдельности, а в протоколах интерфейсов обозначать лишьосновные прямые ветки с помощью сценария. Протоколы являются удобнымсредством при проектировании алгоритмов, позволяющим иметь в наглядномвиде ту основу алгоритма, которая приобретает многочисленные подробности по мере углубления спецификации.Порт — это носитель конкретного соединения со стороны содержащей егокомпоненты.
В простейшем случае порт может быть реализован как указатель на второго участника взаимодействия, в более сложном случае он можетсодержать специальные данные, методы и таймеры для контроля целостности соединения и обработки данных, поступающих по интерфейсу. Эти элементы являются членами компоненты, которая содержит порт, но они выделяются в сам порт, если используются только для данного соединения. Они355могут использоваться из поведенческой модели данной компоненты или изкода уровня реализации для данной компоненты.Таким образом, порт может включать следующие части: ссылки на входящие в него интерфейсы; множественность; методы; атрибуты; таймеры.Интерфейс описывает взаимодействие двух анонимных сторон.
Для тогочтобы определить возможность взаимодействия между классами, интерфейснужно связать с портами этих классов. Причём с одним из портов интерфейссвязывается как «прямой», а с другим — как «обратный».На рис. 5.30 показано, что экземпляр класса «Класс2» может посылать экземпляру класса «Класс1», в соответствии с «Интерфейс1», сообщение «Запрос», получить обратно «Ответ» и послать «Подтверждение».
При этомсвязь интерфейса с портом «Порт1» является «обратной», а с портом«Порт2» — «прямой».Интерфейс1ЗапросОтвет*ПодтверждениеПорт1Порт2Класс1Класс2Рис. 5.30. Пример компонент, портов и интерфейсовОтметим, что методология Real не предоставляет специальных средств дляразработки оборудования, а также драйверов устройств, сетевых протоколовнижнего уровня и т.д. Как показывает практика, прямые ветки сложных алгоритмов достаточно удобно и наглядно определять с помощью сценариев.На начальных этапах разработки системы нужно определить все основныесценарии. При этом интегрировать эти сценарии, а также описывать правила356поведения системы в ошибочных ситуациях целесообразно позднее. По сценариям можно сгенерировать заготовки поведенческой модели и продолжитьсоздание спецификаций уже в этом стиле, учитывая все допустимые варианты поведения системы.Основные черты поведенческой модели Real: закрепление поведенческой модели за компонентами системы; совмещение STD-диаграмм Харела [272], [426] и поведенческих SDLдиаграмм [285] в рамках одной модели; сохранение исполняемой семантики SDL; ориентация на создание законченных спецификаций для дальнейшейавтоматической кодогенерации в случае разработки систем реальноговремени с событийно-управляемой логикой; наличие различных стилей и подходов в использовании поведенческоймодели; возможность спецификации нереактивных алгоритмов (стиль блоксхем).Для поведенческой модели предлагаются две эквивалентные графическиенотации — одна на основе STD, другая — на основе SDL.
Поскольку обе нотации основываются на одной модели (т.е. с их помощью редактируется однаи та же часть репозитория CASE-пакета Real), постольку вопрос о преемственности этапов разработки системы, выполненных с их помощью, решается относительно просто: то, что создано с помощью STD-нотации, загружается на SDL-диаграммы, там дополняется и изменяется, и наоборот.Достоинства SDL-нотации заключаются в следующем: высокая степь графичности: составные части перехода изображаются ввиде специальных графических символов; структурированность диаграмм: между графическими символами естьиерархия «отец-сын», и «сын» не может изображаться выше «отца».357Для последнего пункта есть исключение: когда завершитель одного перехода совпадает с началом другого, символ “конец-начало” оказывается расположенным выше последнего элемента перехода, как показано рис.
5.31.Рис. 5.31. Пример линий «наверх» в SDL-нотацииВнутренность сложного состояния на SDL-диаграммах не изображается, вотличие от STD. Для сложного состояния заводится специальная SDLдиаграмма, входные порты в состояние изображаются как соединители.Достоинства STD-нотации Real заключаются в следующем: возможность изображать действия в переходах в текстовом виде (чтобывает в некоторых случаях предпочтительнее отдельного графического символа); возможность располагать элементы диаграмм в произвольном порядке; возможность изображать внутренность сложных состояний на тех жедиаграммах, что и их контекст.В на STD/SDL-диаграммах предлагается изображать логическое ветвлениене в виде ромба, как это обычно принято, а способом, представленным нарис.
5.32.358Рис. 5.32. Пример изображения логического ветвленияТакой способ предусматривает более рациональное использование пространства внутри символа (при той же площади в него помещается большетекста, чем в обычный ромб).На рис. 5.33 и 5.34 приводятся примеры одной и той же спецификации,выполненной с помощью STD/SDL-нотаций Real.Рис. 5.33. Пример STD-нотации Real359Рис. 5.34. Пример SDL-нотации RealДля разработки информационных систем Real предлагает традиционныесредства — схемы базы данных, бизнес-логику, пользовательского интерфейса (экранных форм).
Для создания схемы базы данных предлагается использовать модель классов, которая содержит некоторое расширение для базданных. В модели классов есть несколько элементов, предназначенных непосредственно для проектирования баз данных. Во-первых, это специальныйтип атрибута — индекс — с возможностью тиражирования индексов по ассоциациям (foreign keys). Во-вторых, некоторый аналог конструкции viewязыка SQL, предназначенный для визуального редактирования сложных запросов. Если схема БД изначально не выходит за рамки возможностей,предоставляемых реляционными СУБД, то дальнейшая генерация самой базы данных и обеспечение доступа к ней достаточно прозрачны. Если же всхеме данных использовались элементы объектно-ориентированного подхода(впервуюочередь,наследование),тотребуетсялибообъектно-ориентированная целевая СУБД, либо специальные механизмы работы сданными.
Вместе с тем бывает удобно даже с реляционной базой данных об360щаться в терминах модели классов. В Real с этой целью можно сгенерировать библиотеку классов, берущих на себя большую часть общения с базойданных без использования SQL-запросов.Пакет Real состоит из следующих частей (рис. 5.35): базовый Real: графические редакторы, графическая среда, ядро (базовая графическая библиотека, библиотека объектного доступа к репозиторию, библиотеки многоязыковых ресурсов, библиотеки стандартныхдиалогов и графических символов и др.);дополнительные приложения, которые взаимодействуют с базовымReal через специальный интерфейс.Базовая часть Real реализована на Microsoft Visual C++ и представляет собой наиболее трудоёмкую часть пакета. Дополнительные приложения реализованы на Microsoft Visual Basic и взаимодействуют с основной частью пакета через COM-интерфейс.
Эти приложения могут меняться и уточняться помере необходимости от одного внедрения к другому, более того, они могутсоздаваться не только самими разработчиками Real, но и пользователями, атакже третьими фирмами.Пакет Real является коробочным универсальным инструментом визуального моделирования, хотя и имеет специфику. Он создавался коллективом в10 человек в течение пяти лет.
На его основе было создано DSM-решение дляприменений в области разработки семейства ПО для российских телефонныхстанций.Технология Real-IT предназначена для быстрой разработки (моделирования и автоматической генерации) приложений, бизнес-логика которых целиком определяется схемой данных74. В этом случае все целевое приложениеоказывается средством заполнения и редактирования данных и не содержитReal-IT описывается в данной работе на основе материалов автора, представленных им вработах [95], [96], [321].74361сложных функций по их обработке. Таких небольших приложений баз данных оказывается на практике очень много, а почти все крупные информационные системы содержат подобные подсистемы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
