CC BY
174
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
© Кинтонова А.Ж.*, Рахимжанова М.*
Евразийский Национальный университет им. Л.Н. Гумилева, Республика Казахстан, г. Астана
В статье дается описание примера использования унифицированного языка моделирования Unified Modeling Language c применением средства визуального моделирования Enterprise Architect для создания и утверждения плана работы отдела организации.
Ключевые слова моделирование, бизнес-процесс, Unified Modeling Language (UML), диаграмма последовательности, роли.
Введение. Для проектирования информационных систем одним из главных вопросов является вопрос моделирования предметной области. Цель моделирования бизнес-процессов - выявление подлежащих автоматизации действий.
Целью разработки модели бизнес-процессов в виде потока работ является отображение последовательности выполнения работ, связанной с бизнес - процессом.
Один из подходов к моделированию предметной области, основанный на применении унифицированного языка моделирования (Unified Modeling Language, UML) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью [1].
На сегодняшний день в моделировании бизнес-процессов преобладает процессный подход. Моделирование бизнес-процессов является важной составной частью проектов по созданию крупномасштабных систем ПО. Отсутствие таких моделей является одной из главных причин неудач многих проектов [2].
Инструментальное средство Enterprise Architect (ЕА) - это продукт австралийской фирмы Sparx Systems. ЕА представляет собой мощное и гибкое средство визуального моделирования, поддерживающее полный жизненный цикл создания программных систем с использованием унифицированного языка моделирования (UML).
Enterprise Architect (ЕА) позволяет: создавать элементы моделей UML, размещать эти элементы на диаграммах, задавать связи между элементами, документировать созданные модели и элементы, генерировать код для раз-
* И.о. доцента, кандидат технических наук.
* Магистр.
рабатываемого программного обеспечения, импортировать коды на различных языках, включая VB, Java, C++ и т.д. (более 10 языков), создавать различные шаблоны моделей предметной области и систем, поддерживать трассировки от моделей предметной области к моделям системы. Дополнительно ЕА поддерживает диаграммы: требований, пользовательских интерфейсов, баз данных, анализа, и некоторых других типов [3].
На этапе создания концептуальной модели для описания бизнес-деятельности используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов - модели бизнес-объектов и диаграммы последовательностей [4].
В ходе проектирования информационной системы, аналитик поэтапно спускается от общей концепции, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию.
Аналитиками фиксируются такие поведенческие аспекты как алгоритм действий в рамках одного или нескольких прецедентов, необходимый для достижения определённого результата, а также изменение состояния объектов в ходе выполнения приведенных действий.
Диаграмма последовательности является одной из разновидности диаграмм взаимодействия и предназначена для моделирования взаимодействия объектов Системы во времени, а также обмена сообщениями между ними.
Одним из основных принципов ООП является способ информационного обмена между элементами Системы, выражающийся в отправке и получении сообщений друг от друга. Таким образом, основные понятия диаграммы последовательности связаны с понятием Объект и Сообщение.
На диаграмме последовательности объекты в основном представляю экземпляры класса или сущности, обладающие поведением. В качестве объектов могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в Системе или программные компоненты, а иногда и Системы в целом.
Объекты располагаются слева на право, таким образом, чтобы крайним слева был тот объект, который инициирует взаимодействие. Неотъемлемой частью объекта на диаграмме последовательности является линия жизни объекта. Линия жизни показывает время, в течение которого объект существует в Системе. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Временная шкала на диаграмме направлена сверху вниз.
На диаграмме деятельности выделяются сообщения, инициирующие ту или иную деятельность или являющиеся ее следствием. На диаграмме состояний частично показан обмен сообщениями в рамках сообщений инициирующих изменение состояния объекта.
Диаграмма последовательности объединяет диаграмму деятельности, диаграмму состояний и диаграмму классов.
Таким образом, на диаграмме последовательности мы можем увидеть следующие аспекты: Сообщения, побуждающие объект к действию; Действия, которые вызываются сообщениями (методы) - зачастую это передача сообщения следующему объекты или возвращение определенных данных объекта; Последовательность обмена сообщениями между объектами.
Итак, прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Сообщение в большинстве случаев (за исключением диаграмм, описывающих концептуальный уровень Системы) это вызов методов отдельных объектов, поэтому для корректного исполнения метода в сообщении необходимо передать какие-то данные и определить, что мы хотим видеть в ответ. При именовании сообщения на уровне проектирования реализации системы в качестве имени сообщения следует использовать имя метода.
Диаграммы последовательности предназначены для моделирования взаимодействия между несколькими объектами. Зачастую диаграммы последовательности создаются для моделирования взаимодействия в рамках одного прецедента.
На концептуальном уровне можно использовать диаграммы последовательности для моделирования взаимодействия между Бизнес-актерами, но зачастую подобные диаграммы обрастают лишними подробностями и плохо читаются. На данном уровне лучше подойдут диаграммы деятельности, исключение составляют случае, когда необходимо смоделировать обмен сообщениями между двумя независимыми Системами.
Также диаграммы последовательности подойдут для моделирования взаимодействия пользователя и Системы в целом. На уровне реализации с помощью диаграммы последовательности моделируется взаимодействие между отдельными компонентами Системы. На данном уровне детализации лучше подойдет диаграмма коммуникации.
Данная функция предназначена для формирования планов работ подразделений.
Диаграмма последовательности (Sequence diagram) - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются, на рис. 1 изображена диаграмма последовательности по созданию и утверждению плана работы.
Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами.
| ьа ьечие1и.е и план пидразд
сотрудник отдела
X X X
Начальник отдела
разработка предложенийО
сотрудник, объеди н яю щи й предложения на уровне п одра здел ен и я
Начальник отдела в п одра зделен и и
Начальник подразделен и:
План работы подразделения
Рис. 1. Диаграмма последовательности по созданию и утверждению плана работы
Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами.
В табл. 1 показаны этапы и роли, используемые в Диаграмме последовательности по созданию и утверждению плана работы.
Таблица 1
Процесс создания плана работы
Этапы Пользователи роли «Исполнитель», Система
Предусловия -
Постусловия Рабочий план
Основной сценарий 1. «Исполнитель» вносит свои предложения к мероприятиям плана 2. Начальник согласовывает предложения 3. Сотрудник, с правами объединения, агрегирует предложения сотрудников отдела 4. Начальник подразделения согласовывает / отправляет на доработку предложения 5. Начальник подразделения утверждает предложения 6. Министр утверждает предложения 7. Система изменяет статус плана работы, план работы переходит в исполнение
Альтернативные сценарии 1 -
Одна роль может объединять ряд сотрудников и много операций, а один сотрудник может быть участником нескольких ролей, при этом управление ролями и распределение участников в общем случае оказывается нетривиальной задачей.
Одна роль может объединять ряд сотрудников и много операций, а один сотрудник может быть участником нескольких ролей, при этом управление ролями и распределение участников в общем случае оказывается нетривиальной задачей.
Заключение. Описание предметной области с использованием иМЬ хорошо воспринимается экспертами предметной области и для понимания представленных им на рассмотрение моделей не требует никакой специальной подготовки [5].
Список литературы:
1. https://ru.wikipedia.org/wiki/UML.
2. Вендров А.М. Современные технологии создания программного обеспечения [Электронный ресурс]. - Режим доступа: http://citforum.ru/pro-gramming/application/program/1.shtml (дата обращения: 26.11.2014).
3. Пашкевич А.П., Чумаков О.А. Современные технологии программирования [Электронный ресурс]. - Режим доступа: http://www.bsuir.by/rn/12_ 100229_1_65759.pdf.
4. Золотухина Е.Б., Алфимов Р.В., Красникова С.А. Моделирование предметной области с использованием Enterprise Architect [Электронный ресурс]. - Режим доступа: http://www.twirpx.com/file/1371899/ (дата обращения: 29.11.2014).
5. Алфимов Р.В., Золотухина Е.Б. Описание предметной области с использованием UML при разработке программных систем [Электронный ресурс]. - Режим доступа: http://compress.ru/article.aspx?id=10359 (дата обращения: 30.11.2014).
АНАЛИЗ ОСНОВНЫХ ХАРАКТЕРИСТИК СТЕНОВЫХ БЛОКОВ В ЗАВИСИМОСТИ ОТ ВИДА МАТЕРИАЛА И ИХ ВЛИЯНИЕ НА СТОИМОСТЬ ИЗДЕЛИЯ
© Семененкова Ю.Ю.*
Смоленский государственный университет, г. Смоленск
В статье проведен анализ изменения ценового диапазона стеновых блоков в зависимости от вида материала.
Ключевые слова стеновой блок, стоимость.
На сегодняшний день довольно трудно себе представить малоэтажное строительство жилых зданий без применения стеновых блоков. Большой спрос на данный вид строительной продукции привел к стремительному росту производителей, и, как следствие повлек появление различных технологических инноваций, связанных с ее производством. Все виды стеновых блоков обладают более или менее схожими эксплуатационными характеристиками. Однако существуют особенности, обусловленные технологиями изготовления, выделяющие конкретный вид стеновых блоков на фоне остальных [1].
В основном виды стеновых блоков отличаются друг от друга по составу используемых в производстве смесей и технологии изготовления. На данный момент наибольшим спросом пользуются такие виды стеновых блоков, как: пеноблоки, газосиликатные (газобетонные) и керамзитобетонные (по-листиролбетонные) [1].
* Студент. Научный руководитель: Дюндин А.В., заведующий кафедрой Строительства, кандидат педагогических наук, доцент.
