CC BY
237
Рецензент: д-р техн. наук, проф. Самойленко Н. И.
Дудолад Александр Стефанович, председатель правления ОАО «Харьковгоргаз».Научные интересы: новые
технологии в нефтегазовой отрасли. Адрес: Украина, 61000, Харьков, ул. Октябрьской Революции, 57/59, к.т. 80572-23-47-14.
Седак Владимир Степанович, канд. техн. наук, доцент, профессор, первый заместитель председателя правления ОАО «Харьковгоргаз» - главный инженер. Научные
УДК 519.688
ПРИМЕНЕНИЕ МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ ЯЗЫКА UML
ЕСИЛЕВСКИЙ В.С., НЕТЁСА П.С.,
КЛИМОВА М.В._______________________________
Рассматриваются вопросы проектирования распределенных информационных систем реального времени. Обсуждается методология объектно-ориентированного проектирования, основанная на применении языка моделирования UML. Предлагаемый подход обеспечивает решение проблем создания программного обеспечения на этапе проектирования, что повышает надежность создаваемых сложных программных систем.
1. Введение
В настоящее время создание программного продукта во многом является искусством. Это означает, что конечный результат всегда зависит от профессиональных качеств исполнителей и множества случайных факторов. В силу того, что требования к программному обеспечению (в отличие от предметов искусства) чаще всего конкретны и строги, а результат проектирования должен быть предсказуем, разработчики ищут промышленные технологии проектирования.
Ответом на эти вопросы на сегодня является методология объектно-ориентированного анализа, проектирования и программирования, предложенная основоположниками этого подхода - Бучем, Рамбо и Дже-кобсоном. Основным ее звеном является представление о жизненном цикле программного обеспечения, в котором выделяются отдельные этапы, причем этап анализа и проектирования отделен от этапа программирования.
Проектирование представляет собой способ графического представления проекта, понятного как эксперту, так и программисту. Методология определяет не только перечень графических диаграмм и способы их оформления, но и процесс его создания. Способ графического проектирования программного обеспечения доведен до стандарта в виде унифицированного языка моделирования - UML (Unified Modeling Language).
интересы: новые технологии в нефтегазовой отрасли. Адрес: Украина, 61000, Харьков, ул. Октябрьской Революции, 57/59, к.т. 8-057-783-94-73.
Дзешульский Евгений Станиславович, заместитель начальника службы аварийно-восстановительных работ ОАО «Харьковгоргаз». Научные интересы: средства коммуникации, мультимедийные технологии. Адрес: Украина, 61000, Харьков, ул. Октябрьской Революции, 57/59, к.т. 8-057-733-07-19.
Целью данной работы является описание процесса анализа и проектирования распределенных систем реального времени, а также исследование применимости для этой цели методологии объектно-ориентированного моделирования на основе языка UML.
В силу большого объема полной проектной документации в статье в качестве базового объекта проектирования используется только одна из подсистем информационно - аналитической системы, разрабатываемой для коммунального предприятия «Харьковкому-ночиствод». Это - автоматизированная подсистема сбора и обработки телеметрической информации с группы канализационных насосных станций городских служб водоотведения на основе радиомодемной GSM-связи
2. Постановка задачи
Неотъемлемой частью системы коммунальных служб городского хозяйства является подсистема водоотведения (канализация) и очистки сточных вод. В ее состав входит канализационная сеть, коллекторы и насосные станции (КНС), обеспечивающие подачу сточной воды для очистки.
Насосные станции, рассматриваемые как активная часть канализационных сетей, являются сложными технологическими объектами с большим количеством параметров контроля и управления. В настоящий момент функционирование насосных станций обеспечивается персоналом в ручном режиме с использованием локальных измерительных средств. Для увеличения эффективности их эксплуатации особенно актуальной является задача централизованного сбора и обработки телеметрической информации с группы насо сных станций.
Формально задача может быть поставлена следующим образом: разработать в графической нотации языка UML проект распределенной системы реального времени централизованного сбора и обработки информации, реализуемый средствами объектноориентированного языка программирования в рамках многозадачной операционной системы.
Принципиальным является то, что множество КНС распределено географически по территории города и информация от них необходима в реальном времени. Для этого нужно создать распределенную информационную систему реального времени, в которой предполагается наличие компьютеров или микроконтроллеров на стороне насосных станций (нижний уровень)
РИ, 2006, № 2
79
и компьютеров в центральном диспетчерском пункте (верхний уровень). Обмен информацией между программами нижнего и верхнего уровней может осуществляется по радиоканалам средствами мобильной связи на основе концепции беспроводной автоматизации М2М (mobile-to-mobile) на основе передачи данных по GSM-сетям (GSM-data).
Так же, как на смену структурному программированию в свое время пришло объектно-ориентированное программирование, так и технология структурного системного анализа информационных систем (SSADM, SADT), основанная на функциональной декомпозиции, в настоящее время практически полностью вытеснена методологией объектно-ориентированного анализа и проектирования. Эта методология поддерживается инструментальными программными средствами на основе унифицированного языка моделирования (UML) [1] и реализуется в рамках стандартизованного процесса проектирования (RUP, USDP).
Язык UML является стандартным способом графической нотации при объектно-ориентированном анализе и проектировании систем и включает в себя набор различных диаграмм для статического и динамического моделирования предметной области на логическом и физическом уровне. Это такие диаграммы:
прецедентов;
классов и объектов;
кооперации;
последовательности;
состояний;
деятельности;
компонентов;
развертывания.
В настоящее время существует большое количество универсальных инструментальных программных средств, реализующих как графическую поддержку языка UML, так и средства автоматизированного перевода проектов в программный код (CASE- средства проектирования), среди которых наиболее известным является Rational Rose фирмы Rational. Различные фирмы предлагают свои средства поддержки UML, специализированные для конкретных языков программирования. В данном проекте использовалась программа Model Maker 6.2 for Delphi 7.
Ниже описывается объектно-ориентированный процесс проектирования программного обеспечения (ПО) подсистемы сбора телеметрической информации с использованием языка UML, которая является частью большого программно-аппаратного комплекса информационной поддержки оперативного дежурного КНС. Так как в этой статье делается упор на исследование методологии, то рассматривается проектирование не всего комплекса, а только одной подсистемы.
3. Реализация
Модель жизненного цикла ПО - это описание последовательности этапов жизни программного продукта и методов их реализации. В рамках обсуждаемого подхода она представляет собой итеративный процесс разработки на основе концепции прецедентов. Нотация UML поддерживает концепции требований, анализа и проектирования, разграничивая виды деятельности для каждого этапа проектирования.
В модели требований задаются функциональные требования к системе в терминах актеров (Actor) и прєцєдєнтов(Шє Case). Каждый прецедент описывает последовательность взаимодействий между несколькими актерами. В аналитической модели прецедент уточняется с помощью характеристик участвующих объектов и взаимодействий между ними. В проектной модели создается архитектура системы, рассматриваются вопросы распределенности, параллелизма и сокрытия информации.
Моделирование требований. На этапе моделирования требований разрабатывается модель типа «черный ящик», в которой определяются функциональные требования к системе в терминах актеров и прецедентов. Она разрабатывается на основе анализа требований заказчика с учетом экспертного анализа предметной области.
Можно выделить следующие прецеденты:
• периодический прием запрашиваемых данных;
• прием инициативных сигналов об аварии;
• обработки и архивация данных;
На рис.1 представлена упрощенная диаграмма прецедентов для системы опроса данных.
Рис. 1. Диаграмма прецедентов
Каждый прецедент сопровождается подробным неформальным словесным описанием. Этот материал нео бходим для о бсуждения модели информационной системы с экспертами (заказчиками) и является документом для дальнейшего проектирования системы.
В этом описании прецедентов формулируются основные понятия и ограничения, используемые в системе.
80
РИ, 2006, № 2
Ниже приводятся часть такого описания, дающая представление о функционировании системы.
В системе используются запрашиваемые данные следующих типов:
1. Мгновенные данные, содержащие информацию о значениях технологических параметров, полученных в результате одного инициированного оператором опроса датчиков с указанием времени опроса.
2. Накопленные данные для архивного хранения и обработки, содержащие массив данных за время, прошедшее с момента последнего удачно завершенного опроса.
Программа обеспечивает прием запрашиваемых данных последовательное (по установленной очереди, через заданный интервал времени) соединение с программно-аппаратными комплексами нижнего уровня, установленными на КНС, и получение технологической информации.
Кроме запрашиваемых данных в системе должен быть обеспечен прием инициативных данных об аварийных событиях, которые содержат информацию о протоколируемых на стороне контроллера КНС ошибках в работе технологического оборудования.
Работа с каналом связи для приема запрашиваемой информации должна выполняться в следующем порядке:
1. Производится модемное подключение конечного абонента (КНС) по хранящемуся в программе телефонному номеру.
2. Передается посылка с запросом на установление связи.
3. Получается подтверждение готовности информации у абонента. В случае отсутствия подтверждения по тайм-ауту или готовности информации сеанс связи закрывается. Формируется запрос на повторную передачу.
4. Осуществляется прием кадра информации.
5. Абоненту выдается подтверждение приема после сохранения информации в базе в виде запроса на синхронизацию времени
Аналитическое моделирование. На этапе аналитического моделирования строятся статическая и динамическая модели системы. Статическая модель задает структурные отношения между классами предметной области. Классы и отношения между ними изо бр ажаются на диаграммах классов. Затем создается динамическая модель, в которой уточняются прецеденты из модели требований с целью показать, какие объекты участвуют в каждом прецеденте и как они взаимодействуют. Объекты и их взаимодействия изображаются на диаграммах кооперации или последовательности. В динамической модели объекты, зависящие от состояния, определяются с помощью диаграмм состояний.
Статическое моделирование. Построение статической модели предметной области - это структурное представление информационных аспектов системы. Задаются классы, их атрибуты и отношения между ними. Операции классов будут указаны позже, в проектной модели. Основное внимание уделяется информационному моделированию классов реального мира, встречающихся в предметной области.
Концептуальная статическая модель предметной области описывает в виде диаграммы классов основные физические классы, участвующие в моделировании предметной области. К ним относятся классы:
визуальной формы TformQBT;
алгоритма опроса TQuestThread;
связи с драйвером радиомодема DDE;
обработчика данных TProcessing.
На диаграмме определена подчиненность классов в виде отношений наследования или агрегирования. Эти классы вводят сущностные классы: кадр информации, набор принятых кадров одного сеанса, шаблон кадра телеметрических данных и т.п. Дальнейшее проектирование классов предусматривает определение их атрибутов
Эти диаграммы определяют, по сути, словарь классов, который позволит впоследствии сгенерировать программный код, описывающий введенные классы. На данном этапе проектирования это делать преждевременно, так как для классов не определены методы, обеспечивающие моделирование динамики предметной области.
Дальнейшее уточнение статической модели требует выделения конкретных объектов, порожденных классами, и разнесение их по подсистемам. При этом важным является определение клиентской и серверной части в случае клиент/серверного взаимодействия в распределенных системах.
Статическое моделирование базы данных. Ядром системы является база данных; пользовательский интерфейс можно рассматривать как оболочку вокруг этого ядра.
При разработке информационной системы будет использоваться стандартная реляционная база данных (СУРБД) MS SQL Server., вокруг которой строится программное приложение. Вся база данных будет расположена на одном компьютере, к которому будут иметь доступ все компьютеры сети, в том числе и компьютер с программой опроса. Такая схема взаимодействия реализует архитектуру клиент-сервер.
Архитектура клиент-сервер. Приложения клиентсервер сочетают пользовательский графический интерфейс клиента с реляционной базой данных, расположенной на сервере. Структура таких приложений подразумевает возможность совместной работы пользователей; при этом ответственность за выполнение тех или иных функций ложится на различные,
РИ, 2006, № 2
81
независимые друг от друга элементы открытой распределенной среды.
Разработка эффективной базы данных является трудной задачей, так как к ней предъявляется много взаимно противоречивых требований. Проектировщик должен учитывать не только функциональные требования к приложению, но также быстродействие и размер базы данных. Базы данных, неэффективные по быстродействию, оказываются, как правило, бесполезными.
Технология проектирования баз данных исторически предшествовала объектно-ориентированной технологии проектирования, но наработанные в ней методы до сих пор являются актуальными.
Проектировщики баз данных используют для анализа данных так называемые диаграммы “ сущно сть-связь” ” (entity-relationship diagrams - ER диаграммы).
Проектирование диаграмм “ сущность-связь” поддерживают многие CASE-средства. В данном проекте использовался программный продукт ERWin фирмы Platinum, который позволяет не только проектировать модель базы данных, но и переводить ее в реальную базу данных под управлением различных СУБД.
Основными элементами реляционной базы данных являются таблицы, в которых столбцы представляют собой предметы и их атрибуты, а строки описывают отдельные экземпляры предметов.
На рис.2 представлен фрагмент ER диаграммы.
Поскольку технологии реляционных баз данных являются в некотором смысле «инородными» для объектно-ориентированного подхода (например, по методам взаимодействия с ними), объекты базы данных должны быть представлены в проекте через так называемые классы-обертки [2].
Разработка модели базы данных заканчивает статическое моделирование информационной системы. Динамические отношения между выявленными объектами изображаются в виде динамической модели, разрабатываемой на следующем этапе моделирования.
Динамическое моделирование. Выявленные ранее прецеденты уточняются с целью показать взаимодействие между участвующими в них объектами. Для этого применяются диаграммы кооперации или последовательности.
Диаграмма последовательности представляет собой взаимодействующие «линии жизни» для каждого объекта. Сигналы и соо бщения будут перенесены при реализации модели в программном коде в раздел описания методов соответствующих классов. На рис.3 представлен фр агмент диаграммы последовательности для системы опроса.
Рис. 3. Фрагмент диаграммы последовательности
Это взаимодействие можно также изображать в виде диаграммы кооперации, которая изоморфна диаграмме последовательности и имеет те же « последствия» в программном коде, что и диаграмма последовательности.
Рис. 2. Фрагмент диаграммы “сущность-связь”
SQL Server предоставляет клиентам несколько специальных инструментов и методов, которые позволяют им обрабатывать информацию, полученную из серверной базы данных. К ним относятся: хранимые процедуры, предписываемые сервером правила и триггеры, которые передают серверу задание на автоматическую обработку данных.
Интерактивные прикладные программы могут получить доступ к данным в базе, созданной для SQL Server, с помощью “диалекта” языка SQL.
В случае, когда в модели имеется зависимость от состояния, необходимо явно промоделировать управляющие о бъекты, зависящие от состояния, и диаграммы их состояний. Каждый зависящий от состояния объект описывается своей диаграммой.
События, переводящие систему из одного состояния в другое, при программной реализации послужат основой для создания соответствующих методов класса. На рис. 4 представлен фрагмент диаграммы состояний для потока опроса.
82
РИ, 2006, № 2
Рис. 4. Фрагмент диаграммы состояния для потока опроса
Таким образом, на этапе аналитического проектирования разрабатывается аналитическая модель предметной области путем описания ее в статике и динамике. При этом вид модели приспособлен для дальнейшей реализации в рамках физического проекта, который может быть выполнен на объектно-ориентированном языке программирования под реальной операционной системой.
Проектное моделирование. На этапе проектного моделирования разрабатывается программная архитектура системы. При этом аналитическая модель, созданная на предыдущем этапе моделирования, отображается на эксплуатационную среду. Аналитическая модель, в которой наиболее важной была предметная область, переносится на проектную модель, где главной становится область решения. Для декомпозиции системы применяются критерии разбиения на подсистемы, последние рассматриваются как агрегированные или составные объекты. Затем проектируется каждая подсистема.
В данном проекте объекты, выделенные на этапе статического моделирования, должны быть распараллелены, если это необходимо для работы системы в реальном времени. Этот процесс может происходить на уровне отдельных задач или на уровне потоков в рамках одной задачи. При этом следует учитывать механизмы синхронизации параллельных объектов.
При проектировании системы опроса телеметрической информации были выделены следующие потоки:
1) сновной поток визуальной формы;
2) поток обеспечения связи с драйвером радиомодема через механизм DDE обмена;
3) поток алгоритма опроса;
4) поток обмена данными с сервером баз данных;
5) вспомогательные потоки:
а) поток таймеров интервалов опроса;
б) потоки аварийного приема сообщений.
На вопросы реального размещения программного обеспечения отвечают диаграммы развертывания, где описываются отдельные узлы размещения прогр амм-ного обеспечения, соответствующие отдельным компьютерам. Поскольку здесь обсуждается вопрос проектирования только одной подсистемы, р азмещаемой на одном компьютере и взаимодействующей с другими компьютерами как с внешней средой, то вопрос выделения активных объектов завершается формированием описания взаимодействующих потоков одного приложения, реализующего функции сбора телеметрической информации.
Таким образом, завершен этап моделирования на логическом и физическом уровне. Дальше выполняется по созданной документации процесс реального написания программного кода, который представляет собой многошаговую процедуру.
При этом определяется, какое подмножество системы будет реализовано на каждом шаге. Подмножество выбирается с учетом того, какие прецеденты и участвующие в них объекты следует добавить. Инкрементное конструирование включает детальное проектирование, кодирование и автономное тестирование классов, вошедших в отобранное подмножество. Т акой поэтапный подход позволяет постепенно создавать и объединять фрагменты системы, пока она не будет собрана целиком.
Как уже обсуждалось выше, переход от проектной документации к программному коду может происходить при помощи различных программных CASE-средств ИЛИ, что позволяет совместить надежность «бумажного» проектирования с высокими темпами разработки программ в современных объектно-ориентированных средах программирования.
CASE-средства позволяют сократить время выполнения рутинной программистской работы и тем самым оправдывают достаточно большие затраты на проектирование.
Выводы
Рассмотрено применение новой в практике разработчиков программного обеспечения методологии объектно-ориентированного проектирования информационных систем на базе специализированного языка проектирования UML. Рассматриваемая задача проектирования подсистемы централизованного сбора телеметрической информации относится к классу сложных задач проектирования распределенных программно-аппаратных комплексов реального времени. Ее решение в рамках предлагаемого подхода подтверждает универсальность и достаточность выразительных средств языка UML
Этот подход был реализован при разработке информационно-аналитической системы эксплуатационных служб коммунального предприятия «Харьковкому-ночиствод» и имеет практическую направленность. Он позволил:
РИ, 2006, № 2
83
1) увеличить надежность программного продукта, так как благодаря доступности графического способа представления проекта в нотации языка UML проектные решения могли обсуждаться с заказчиком и соисполнителями в целях обнаружения логических ошибок на ранних стадиях проектирования;
2) сократить сроки отладки и внедрения программного продукта за счет выявления основных проблем системы на стадии проектирования и сокращения времени выполнения большей части рутинной программистской работы;
3) обеспечить повторное использование найденных решений в других разработках.
Применение другими р азр аботчиками этой мето до ло -гии при проектировании сложных программных систем может способствовать внедрению современных
УДК681.3.016 "
МОДЕЛЬ СОГЛАСОВАНИЯ ДАННЫХ ПРИ ИНТЕГРАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ
ТАНЯНСКИЙ С. С____________________________
Рассматриваются вопросы обеспечения целостности и согласованности распределенных данных. Предлагается модель интегрированной системы на основе реляционной базы данных. Исследование методов поддержки целостности данных, основанных на зависимостях между атрибутами, дало возможность определить ряд свойств, обеспечивающих актуальность информации при совместном использовании нескольких баз данных. Рассматривается класс несогласованных баз данных и определяются методы их согласования.
1. Введение
Проектирование баз данных (БД) представляет собой трудоемкий, длительный и, во многих случаях, неформализованный процесс. Это комплексная проблема, касающаяся, в конечном счете, не только обработки данных, но и организации вычислительного процесса в целом. Качество полученной в итоге структуры определяется общей методологией проектирования, используемой на каждом этапе разработки БД.
Выделяется три основных этапа построения БД [ 1,2].
1. Анализ предметной области. Здесь определяется область прикладных задач, состав и структура программного обеспечения.
2. Логическое проектирование. На этом этапе осуществляется отображение инфологической модели предметной области в логическую структуру данных. Можно отметить, что с повышением уровня автоматизации методов проектирования наблюдается тенденция объединения первого и второго этапов.
3. Физическое проектирование. Выбор структуры хранения данных на основе заданной логической структуры и методов доступа к данным.
84
методов разработки программного обеспечения, принятых в международной практике.
Литература: 1.Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК, 2000. 432с. 2. ГомаХ. UML. Проектирование систем реального времени, распределенных приложений, М.: ДМК, 2002.
Поступила в редколлегию 14.03.2006
Рецензент: д-р техн. наук, проф. Руденко О.Г.
Есилевский Валентин Семенович, канд. техн. наук, доцент кафедры «Прикладной математики» ХНУРЭ. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 7021 -94-36, e-mail:[email protected]
Нетёса Павел Сергеевич, бакалавр, студент ХНУРЭ. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
Климова Мария Валентиновна, бакалавр, студентка ХНУРЭ. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
Этими этапами ограничиваются традиционные методы проектирования БД. Рассматривая класс задач поддержки распределенных данных, введем дополнительный этап проектирования.
4. Проектирование технологии ведения БД. Этап включает определение оценки эффективности БД, анализ причин отклонения от эксплуатационных характеристик, а также осуществление мероприятий по устранению этих отклонений (реорганизация, реструктуризация БД и т. п.).
В дальнейшем под ведением данных будем понимать технологический процесс обновления БД в целях поддержки ее в актуальном состоянии в ходе функционирования информационной системы (ИС).
Недостатки, присущие системам монопольного использования БД, и отсутствие общей технологии управления распределенными данными привели к концепции интегрированных систем БД. Вместе с более сложной структурой появилась необходимость в системах управления такими БД. Однако программное обеспечение систем управления базами данных (СУБД) предназначено только для определения, загрузки и доступа к данным, структура которых заранее установлена.
Сложность ведения интегрированных данных требует дополнительных мероприятий по автоматизации этих процессов. При этом дополнительный этап проектирования технологии ведения должен до начала эксплуатации системы (при интеграции локальных БД) определить эффективные методы поддержки целостности распределенных данных.
Один из способов построения системы управления распределенными БД состоит в интеграции всех БД (или их частей, необходимых для обобщенного представления) на основе глобальной схемы. В дальнейшем под глобальной схемой будем понимать схему, состоящую из имен атрибутов БД, которые соответствуют как синтаксической, так и семантической уникальности. На концептуальном уровне она должна
РИ, 2006, № 2
