К вопросу о визуальном моделировании с использованием BOUML

Размещено на http://www.allbest.ru/

К вопросу о визуальном моделировании с использованием BOUML

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

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

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

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

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

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

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

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

Надеюсь, мы вас убедили в важности предварительного моделирования программных систем. А теперь подробнее рассмотрим, как это просто сделать с помощью case-средств.

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

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

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

Существует два вида диаграмм взаимодействия:

· диаграммы последовательности (sequence diagrams)

· и кооперативные диаграммы (collaboration diagrams).

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

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

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

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

Рисунок 1 Пикторамма Актер

Линия жизни (Life Line) - изображается в виде пунктирной вертикальной линии, идущей вниз от объекта или актера (рис. 3), и символизирует период времени, в течение которого объект присутствует в системе и может принимать участие во взаимодействиях. В том случае, если объект постоянно присутствует в системе, его линия жизни должна продолжаться по всей плоскости диаграммы. В противном случае, линия жизни объекта, прекращающего свою работу в системе, должна заканчиваться специальным символом в виде латинской буквы «Х».

Фокус управления (focus of control) или бар - изображается в виде узкого вытянутого прямоугольника, расположенного вдоль линии жизни (рис. 3) и используется для визуализации на диаграмме моментов начала и прекращения работы объекта. Верхняя сторона прямоугольника обозначает момент получения управления объектом фокуса управления (начало активности), а нижняя сторона - потерю объектом фокуса (окончание активности). Помимо этого, объекты могут находиться в состоянии ожидания ответа. Эти состояния могут чередоваться на протяжении всего времени существования объекта в системе, следовательно, у объекта может быть несколько фокусов управления.

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

Основная цель формирования диаграмм взаимодействий - показать последовательность обмена сообщениями в системе во время некоторого сценария. Поэтому на отображении сообщений остановимся подробнее. Взаимодействие между объектами осуществляется с помощью сообщений (messages). Это некие сигналы, которыми обмениваются объекты системы в процессе работы. Выделяют следующие основные типы сообщений (рис. 2):

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

· асинхронные сообщения (asynchronous messages) - сообщения, на которые не требуется ответ, передается в произвольный момент времени и не сопровождается получением фокуса управления объектом-получателем. Вызывающий объект может продолжать работу;

· ответные сообщения (reply messages) - сообщения, присылаемые в ответ на синхронные, используемые для возврата из вызова процедуры. Например, простое сообщение о завершении вычислений без предоставления конкретных результатов;

· рефлексивные сообщения (reflexive messages), или самовызов (self-call) - сообщения, которые объект отправляет самому себе, используется, например, при обработке нажатий на клавиши клавиатуры при вводе текста в редактируемый документ, при наборе цифр номера телефона абонента.

Рисунок 2 Виды сообщений на диаграмме последовательности

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

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

· крайним слева на диаграмме отображают объект, являющийся инициатором моделируемого процесса (например, актер);

· вторым по счету указывается объект системы, с которым объект-инициатор взаимодействует в первую очередь;

· и так далее.

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

Пример простейшей диаграммы последовательности представлен на рисунке 3.

Рисунок 3 Пример диаграммы последовательности

Создание диаграммы последовательности в BOUML

Для начала создадим новый проект в среде BoUML, дадим ему произвольное имя.

Создадим новое представление вариантов использования - New use case view (рис. 4). Также можно в качестве основы создать представление класса (New class view).

Рисунок 4 Создание представления вариантов использования

Далее с помощью контекстного меню можно создать саму диаграмму последовательности (рис. 5). Если необходимо описать взаимодействие пользователей с системой, то в рамках представления вариантов использования (use case view) нужно добавить действующее лицо (New actor).

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

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

Создадим главный модуль, с которым будет непосредственно взаимодействовать пользователь (рис. 6).

Рисунок 6 Пиктограмма для создания объекта

Обычно для объекта на диаграмме, через двоеточие, указываются две характеристики: имя объекта и название класса, к которому данный объект принадлежит. Среда BoUML запрашивает эти данные при создании объекта (рис. 7, 8). Дадим главному модулю имя main и укажем, что он, к примеру, относится к классу Module (Модуль).

Рисунок 7 Указание имени объекта

Рисунок 8 Указание класса, к которому принадлежит объект

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

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

Для отображения сообщений между объектами в первую очередь нужно определиться с типом сообщения и выбрать соответствующий инструмент в меню (рис. 9). BoUML предоставляет возможность использовать для моделирования все возможные типы сообщений в UML: синхронное сообщение (рис. 9а), асинхронное сообщение (рис. 9b) и ответное сообщение (рис. 9с).

а) Пиктограмма синхронного сообщения

b) Пиктограмма асинхронного сообщения

с) Пиктограмма ответного сообщения

Рисунок 9 Выбор пиктограмм для сообщений

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

Рисунок 10 Настройка параметров сообщения

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

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

Пример реализации диаграммы последовательности в среде BOUML

Сценарий: «Вход пользователя в систему»

Основной поток событий:

1. Система запрашивает логин и пароль пользователя.

2. Пользователь вводит логин и пароль.

3. Система обрабатывает введённые логин и пароль.

4. Система проверяет правильность введённых данных и в соответствии с ними присваивает пользователю определенную роль (права доступа).

Альтернативные потоки:

1. В случае отказа в предоставлении доступа пользователь может повторить ввод данных или выйти из системы.

Предусловия: нет.

Постусловия: при успешном выполнении сценария пользователь получает доступ к ресурсам системы, в противном случае - состояние системы не меняется.

Диаграмма последовательности для данного сценария имеет вид(рис. 11).

Рисунок 11 Диаграмма последовательности для сценария «Вход в систему»

На диаграмме введены следующие обозначения:

User - пользователь, прошедший авторизацию; main - главный модуль приложения; Module - класс, описывающий модуль приложения; Login, password request - запрос логина и пароля пользователя; Login, password - введенные пользователем данные (логин и пароль); Check, identification - проверка корректности введенных данных, в случае успешного прохождения проверки - идентификация пользователя; Reply (access rights or error) - ответное сообщение от главного модуля: предоставление прав доступа или уведомление об ошибке идентификации пользователя.

Полезные советы

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

Важно помнить:

· актер на диаграмме (т.е. инициатор процесса), как правило, только один;

· время существования объектов не обязательно совпадает с длительностью всего процесса, поэтому необходимо заранее определиться, какие объекты будут существовать постоянно, а какие - временно;

· для уничтожения временных объектов необходимо предусмотреть явные сообщения;

· в случае сложных ветвлений для каждой ветви необходимо сформировать собственную диаграмму взаимодействия.

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

Список литературы

визуализация программный bouml

1. Абрамова О.Ф. CASE-технологии: изучать или исключить? / О.Ф. Абрамова // Alma mater (Вестник высшей школы). - 2012. - № 9. - C. 109-110

2. Абрамова О.Ф. Использование мультимедийных технологий в процессе обучения дисциплине "Компьютерная графика" / О.Ф. Абрамова, С.В. Белова // Успехи современного естествознания. - 2012. - № 3. - C. 90

3. Абрамова О.Ф. Анализ проблем в области автоматизированного проектирования и расчёта электрических схем [Электронный ресурс] / О.Ф. Абрамова, С.А. Лащенов // NovaInfo.Ru : электрон. журнал. - 2015. - № 39. - Режим доступа : http://novainfo.ru/archive/39/problemy-rascheta-elektricheskikh-skhem.

4. Абрамова О.Ф. К вопросу о повышении эффективности функционирования тренажёрно-обучающих систем / О.Ф. Абрамова, М.Л. Цыганкова // Открытое и дистанционное образование. - 2014. - № 4. - C. 34-39

5. Александрина А.Ю. Разработка специализированных программных продуктов как форма научно-исследовательской работы студентов направления «Химическая технология» / А.Ю. Александрина, В.Ф. Каблов, О.Ф. Абрамова // Вестник Российского ун-та дружбы народов. Серия «Информатизация образования». - 2015. - № 4. - C. 59-66.

6. Буньковский Д.В. Управление инвестиционным проектом: регулирование параметров проекта / Буньковский Д.В. // Вестник Иркутского государственного технического университета. - 2013. - № 5 (76). - С. 161-164.

7. Буньковский Д.В. Оценка потенциала возникновения и развития малого предприятия по производству серобетона / Буньковский Д.В. //

8. Известия Иркутской государственной экономической академии. - 2011. - № 4. - С. 120-122.

9. Красильникова А.Н. Информационные технологии в градостроении / А.Н. Красильникова, В.О. Александрова, О.Ф. Абрамова // Успехи современного естествознания. - 2012. - № 6. - C. 32.

10. Мельниченко Д.В. Исследование логических проблем юзабилити сайтов и анализ существующих решений [Электронный ресурс] / Д.В. Мельниченко, О.Ф. Абрамова // Современная техника и технологии. - 2015. - № 1. - C. Режим доступа : http://technology.snauka.ru/2015/01/5360.

11. Савельева И.Е. Pеабилитация / Савельева И.Е. // Международный журнал прикладных и фундаментальных исследований. - 2013. - № 7. - С. 148-149.

12. Савельева И.Е. Система обеспечения национальной безопасности России: Здравоохранение, раздел «Медицинская реабилитация» / Савельева И.Е.// Современные проблемы науки и образования. - 2012. - № 6. - С. 3.

13. Сулейманов А.Ю. Анализ проблем автоматизации бизнес-процессов многопрофильных образовательных учреждений [Электронный ресурс] / А.Ю. Сулейманов, О.Ф. Абрамова // Современная техника и технологии. - 2015. - № 6. - Режим доступа : http://technology.snauka.ru/2015/06/6792

Размещено на Allbest.ru