(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Процесс разработки программно-аппаратных систем на основе визуального моделирования с использованием SysML/UML

Дмитрий Рыжов, Денис Иванов

Авторы: Дмитрий Рыжов, Денис Иванов  

Все  большее  число  системных  инженеров  начинают  использовать  язык  моделирования  SysML  для  специфицирования и проектирования программно-аппаратных систем. Это дает им много преимуществ, в  том  числе  возможности  верификации  и  валидации  моделей  систем  и  облегчение  передачи  информации представителям других инженерных дисциплин, в частности разработчикам программного и аппаратного  обеспечения.  Данная  статья  содержит  описание  процесса  разработки  систем,  основанного  на  SysML,  который  системные  инженеры  могут  использовать  для  спецификации  требований  и  определения архитектуры систем. В основе процесса лежит функциональная декомпозиция, основанная на определении и дальнейшем уточнении операционных контрактов, а также концепция взаимодействия на основе обмена сообщениями.  Описываемый  процесс  разработан  компанией  IBM Rational / Telelogic  и  активно  используется  во множестве  реальных  проектов  по  разработке  программно-аппаратных  систем  на  основе  визуального
моделирования (MDSE).

1.  Введение
 
Многие  годы  разработчики  программного обеспечения  с  успехом  применяли  язык UML  для разработки  программного  обеспечения  на  основе  визуального  моделирования.  Было  предпринято несколько  попыток  применить UML  и  лежаший  в его  основе  объектно-ориентированный  подход  к
разработке  систем  в  целом  с  целью  унификации всего  процесса  разработки.  Однако  многие системные  инженеры  продолжают  использовать классические  методы  структурного  анализа  и соответствующие  артефакты  для  определения требований  к  системам  и  дальнейшего  ее проектирования. 

Одна  из  возможных  причин такого  положения  дел  состоит  в  том,  что разработка систем определяется в большей степени функциональными требованиями. Формулировки в терминах  функциональности  системы  при  ее проектировании  все  еще  рассматриваются  как наиболее  естественными  большинством специалистов  инженерных  дисциплин, вовлекаемых  на  ранних  этапах  разработки  систем (схемотехников,  конструкторов,    маркетологов  и, конечно,  заказчиков).  Учитывая  вышесказанное, единственный  путь  унификации  всего  процесса разработки  заключается  в  расширении  UML  для получения  возможности  разработки  систем  на основе  функциональной  декомпозиции  и определении  процесса,  позволяющего осуществлять  плавную  передачу  результирующих артефактов  разработчикам  программного обеспечения,  использующим  UML.  Для достижения  этой  цели  OMG  (Object  Management Group)  сформировала  консорциум  для  разработки языка SysML (Systems Modeling Language).   

На  Рис.  1  изображены  диаграммы  языка SysML.  Язык  SysML  является  диалектом  языка UML. Часть диаграмм языка UML не вошли в язык SysML,  но  появились  две  новых.  Другие диаграммы  UML  были  дополнены  и  частично изменены. Базовым элементом модели стал блок, а не  класс.  Диаграмма  классов  и  диаграмма структуры UML получили новые названия.  В  статье описывается процесс, основанный на языке  моделирования  SysML,  который  системные инженеры  могут  использовать  для  спецификации требований  и  определения  архитектуры  систем. Рассматриваемый процесс основан на возможности среды  разработки  IBM Rational / Telelogic  Rhapsody  по исполнению  моделей,  как  средстве  для верификации и валидации требований к системе.

2. Обзор процесса
 
На Рис. 2  с использованием классической "V" диаграммы  показан  интегрированный  процесс, совмещающий  в  себе  разработку  систем  и программного обеспечения. Левая наклонная часть буквы  "V"  отображает  нисходящий  процесс  проектирования,  в  то  время  как  правая  наклонная
часть  отображает  восходящие  этапы  интеграции, начиная  с  элементарных  тестов    и  заканчивая приемкой  конечной  системы.  Используя  нотацию состояний,  итеративная  природа  процесса отображается  в  виде  "высокоуровневого перехода",  возникающего  при  появлении изменений.  Стадия  разработки  систем характеризуется  последовательным  нисходящим потоком  работ,  включающим  анализ  требований, анализ системы и проектирование ее архитектуры.

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

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

  • Определение  требуемой  функциональности системы и источников происхождения требований;
  • Определение  состояний  и  режимов  работы системы;
  • Определение  подсистем  и  их  компонентов  и привязка  к  ним  требований  и  необходимой функциональности;

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

3. Фаза анализа требований

3.1. Этап определения требований

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

3.2. Этап определения вариантов использования 

После  того  как  требования  к  системе становятся  понятны  они  группируются  по вариантам  использования.  Один  вариант использования  описывает  конкретный операционный  аспект  системы  (поток  операций). Он  специфицирует  поведение,  которое  видно пользователю,  и  определяет  поток  сообщений между  пользователем  и  системой.  При  этом внутренняя  структура  системы  не специфицируется  никоим  образом  (представление "черного  ящика"). Варианты  использования могут быть  структурированы  иерархически.  Для отображения  множества  вариантов  использования применяется диаграмма использования. Полученные  варианты  использования связываются с требованиями к системе, после чего производится  проверка  полноты  покрытия требований элементами модели.
 
4. Фаза функционального анализа
 
На фазе функционального анализа для каждого определенного  варианта  использования  создается отдельная  модель  системы  "черного  ящика"  и относящиеся к ним  требования верифицируются и валидируются путем исполнения модели. При этом используется  подход,  основанный  на  обмене сообщениями:  

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

На  Рис.  4  показано  как  связаны  между  собой артефакты  SysML,  создаваемые  для  каждого варианта  использования  в  процессе функционального анализа. Анализ  варианта  использования  "черного ящика"  начинается  с  определения  окружения  для варианта  использования.  Для  этого  используется такой  артефакт  SysML  как  структурная диаграмма. Элементами этой диаграммы являются блоки,  моделирующие  действующих  лиц  и  саму систему. 

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

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

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

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

5. Фаза проектирования архитектуры

5.1. Этап проектирования архитектуры системы

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

Следующие  несколько  шагов  выполняются итеративно для каждого варианта использования. Определенные ранее операционные контракты для  системы  в  рассматриваемом  варианте использования  привязываются  к  физическим подсистемам  с  использованием  диаграммы деятельности  "белого  ящика".  Эта  диаграмма является  практически  копией  диаграммы деятельности    "черного  ящика".  Единственное различие  состоит  в  том,  что  данная  диаграмма содержит  разбиение  на  разделы,  каждый  из которых соответствует физической подсистеме. На основе  выбранной  архитектуры,  операционные контракты  системы  размещаются  на  диаграмме  в разделах  соответствующих  подсистем.  Важным постусловием  для  данной  привязки  является  то, что  изначальные  связи  (последовательность действий)  между  операционными  контрактами сохраняются.

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

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

5.2. Этап проектирования архитектуры подсистем

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

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

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

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

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

  • Спецификация  требований для  аппаратного и программного обеспечения
  • Описание  логических  интерфейсов  между компонентами
  • Тестовые  сценарии  для  подсистем  и  их компонентов  полученные  на  основе  сценариев  вариантов использования уровня системы.

 6.  Заключение

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

Ссылки по теме


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 03.06.2009 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
DeviceLock Endpoint DLP Suite - от 1 ПК до 24 ПК
Купить, скачать Dr.Web Security Space, 1 год, 1 ПК
DevExpress / Universal Subscription
Microsoft SQL CAL 2017 Sngl OLP 1License NoLevel UsrCAL
SmartBear Collaborator - Named User License (Includes 1 Year Maintenance)
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Каждый день новые драйверы для вашего компьютера!
Новые программы для Windows
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Пишу программы на заказ профессионально (2307)
Пишу программы на заказ на языках Pascal (численные методы, списки, деревья, прерывания) под...
 
Надстройка "Поиск решения" MS Excel (6)
Помогите решить задачу с помощью " поиск решения" мука яйца ...
 
Ищу программиста для написания программы (22)
Ищу программиста ,владеющего Вижуал Бэйсик и программированием в Экселе, для написания...
 
Модульный метод создания сайтов (4)
Модульный метод создания (компоновки) сайтов на основе наборов типовых отлаженных функциональных...
 
Пишу программы на заказ для студентов (187)
Пишу для студентов на с, с++, паскаль в средах ms visual studio, qt, builder, borland c, delphi....
 
 
 



    
rambler's top100 Rambler's Top100