Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Иващенко А. В., Сталькин А. А., Калышенко У. М.
В работе приводится результат исследования объектно-ориентированного метода проектирования при реинжиниринге бизнес-процессов. Производится моделирование системы управления производственными заданиями на этапе конструкторско-технологической подготовки производства по методологии UML.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Иващенко А. В., Сталькин А. А., Калышенко У. М.
Современные информационные технологии в ТПП приборостроительного предприятия
Концепция комплексной подготовки специалистов по CALS-технологиям и ее апробация на базе УГАТУ
Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурногои объектно-ориентированного подходов
Методика управления научными исследованиями и подготовкой специалистов в области CALS/ИПИ-технологий
Комплекс средств разработки проблемно-ориентированных визуальных языков
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры?
Использование нотации UML для описания бизнес-процессов
Вы всегда можете отключить рекламу.
UML in workflow managenent automation
In this paper the result of the object-oriented method of the designing in business-processes reengineering study is presented. The model of the workflow system in product lifecycle management is developed using the UML
Текст научной работы на тему «Применение методологии UML при автоматизации управления бизнес-процессами »
Применение методологии UML при автоматизации управления бизнес-процессами
Самарский государственный аэрокосмический университет
Понятие реинжиниринга бизнес-процессов вызывает активный интерес в самых различных областях, в том числе в промышленном производстве [1]. Реинжиниринг рассматривают как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в наиболее важных показателях их деятельности» [2]. Под бизнес-процессом понимается набор логически связанных действий, выполняемых для достижения определенной производственной цели. Необходимость реинжиниринга обосновывается высокой динамичностью современного мира, его применение сегодня особенно актуально для отечественной промышленности, так как является средством резкого повышения эффективности работы предприятия [1].
Управление технологической подготовкой производства строится на основе хранения и использования информации об изделии на определенных стадиях его жизненного цикла. Компьютерная поддержка жизненного цикла изделия осуществляется с использованием CALS (Computer Acquisition and Lifecycle Support) технологий, представленных на этапах конструкторского и технологического проектирования системами управления инженерными данными — PDM (Product Data Management) системами. Управление производственными заданиями является одной из ключевых функций управления жизненным циклом изделия, которые должна поддерживать подобная система. Для этой цели применяются workflow-системы, которые должны обеспечивать маршрутизацию документов, взаимодействие пользователей, наблюдение за ходом документооборота.
23 Практика применения UML для проектирования бизнес процессов и информационных систем Сергей Наумов
Для построения информационных моделей систем данного класса можно использовать различные методологии. В настоящее время наиболее широкое распространение получила методология функционального проектирования SADT (Structured Analysis Design Technique), тем не менее наиболее современным и продуктивным считается объектно-ориентированный подход, который в наибольшей мере отвечает потребностям разработки [1].
К недостаткам объектно-ориентированного проектирования принято относить тот факт, что он в большей степени ориентирован на системных аналитиков и программистов, чем на других участников проекта (например, конструкторов или технологов). Однако этот подход все чаще используется в машиностроении и поддерживается в современных САПР, например, при построении трехмерной модели изделия. В связи с этим актуальным следует считать использование объектно-ориентированных методов реинжиниринга бизнес-процессов. Одной из наиболее известных методологий объектно-ориентированного проектирования является UML (Unified Modelling Language) [3].
Цель данной работы состоит в исследовании методов объектно-ориентированного проектирования системы управления бизнес-процессами на этапе конструкторско-технологической подготовки производства. Основными ее функциями являются: создание схем бизнес-процессов, контроль и управление ходом бизнес-процессов, учет используемых документов, распределение операций бизнес-процессов между участниками с учетом их должностей и обеспечение взаимодействия между ними. В методологии UML функции системы представляются на диаграмме прецедентов (диаграмме вариантов использования) (см. рис. 1). Для системы были выделены следующие актеры (типы пользователей): участник бизнес-процесса, аудитор, инициатор, администратор и дизайнер (администратор и дизайнер на данной диаграмме не представлены).
В системе должна храниться информация о схемах и течении бизнес-процессов, пользователях системы, их правах доступа, используемых документах. Структура хранимых данных представляется с помощью диаграммы классов (см. рис. 2). На диаграмме отображена внутренняя структура бизнес-процесса, модель хранения организационной структуры предприятия и связь бизнес-процессов и участников с другими объектами системы (письма, базы данных). Роль, выполняемая пользователем в бизнес-процессе, определяется только семантикой связи между ними и не зависит от должности пользователя, в разных бизнес-процессах она может быть различной.
(from Use Chttps://cyberleninka.ru/article/n/primenenie-metodologii-uml-pri-avtomatizatsii-upravleniya-biznes-protsessami» target=»_blank»]cyberleninka.ru[/mask_link]
Зачем нам UML? Или как сохранить себе нервы и время
Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
- начну писать код, а в процессе пойму, что да как;
- почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
- поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
- начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.
Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.
Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.
Что такое UML
Официальное определение из википедии.
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.
Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.
Плюсы и минусы UML проектирования
- трата времени;
- необходимость знания различных диаграмм и их нотаций.
- возможность посмотреть на задачу с разных точек зрения;
- другим программистам легче понять суть задачи и способ ее реализации;
- диаграммы сравнительно просты для чтения после достаточно быстрого ознакомления с их синтаксисом.
Все представленные ниже диаграммы связаны между собой. Комбинируя их, мы можем добиться необходимого уровня декомпозиции отдельно взятых задач.
Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.
Сначала я , а потом , а потом… Диаграмма последовательностей
Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?
Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.
В чем недостаток данного подхода? Он не нагляден.
Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.
Альтернативой данному подходу является использование диаграммы последовательностей, представленной на рисунке ниже.
Сверху отображены действующие лица, а каждая стрелка это конкретное действие, связанное с ними. Подробнее о данной диаграмме можно узнать здесь
Диаграмма состояний. Настраиваем старые электронные часы
Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Предположим, мы программируем советские электронные часы.
Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.
Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.
Подробнее о диаграмме состояний можно прочитать здесь.
Диаграмма классов, или как рассказать о своем коде без кода
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?
Предположим, вам нужно спроектировать систему. Прежде чем приступить к реализации нескольких классов, вы захотите иметь концептуальное понимание системы, — какие классы мне нужны? Какая функциональность и информация будет у этих классов? Как они взаимодействуют друг с другом? Кто может видеть эти классы?
И так далее.
Вот где появляются диаграммы классов. Диаграммы классов — это отличный способ визуализировать классы в вашей системе, прежде чем вы начнете их кодировать. Они представляют собой статическое представление структуры вашей системы.
Именно диаграмма классов дает нам наиболее полное и развернутое представление о структуре и связях в программном коде. Понимание принципов построения данной диаграммы позволяет кратко и прозрачно выражать свои мысли и идеи.
Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».
«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.
Самыми значимыми достоинствами этой диаграммы являются:
- экономия времени при объяснении задачи другим программистам;
- более точное и наглядное представление структуры основных элементов системы.
Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.
Диаграмма деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельные процессы.
Если говорить кратко, то диаграмма деятельности помогает нам описать логику поведения системы. Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри нее.
Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.
Подробнее о диаграмме деятельности можно прочитать здесь.
Заключение
Надеюсь, что после этой статьи вы по-другому посмотрите на UML. Теперь при прочтении литературы или сайтов, посвященных данной теме, вам будет проще понять, какую цель преследует UML, и найти возможности для его применения. Попробуйте начать применять его и вы почувствуете всю силу и мощь, скрываемую за набором стрелок и квадратиков.
Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.
- программирование
- uml
- проектирование
- Программирование
- Анализ и проектирование систем
- UML Design
Источник: habr.com
Как язык UML помогает организовать работу IT-проекта
Дмитрий Приймак — эксперт по системному бизнес-анализу Luxoft Training и евангелист языка UML. В своей статье на tproger.ru он рассказал о том, чем полезен UML и почему этот язык точно не «умер».
«UML устарел»… «UML умер»… Статьи с вариациями на эту тему то и дело всплывают в Сети. Используя эту нотацию для построения моделей уже более 14 лет, я в корне не согласен с такой позицией. Наоборот, в противовес скептикам скажу, что язык жив и, вероятно, ещё долго будет жить. В этом материале постараюсь раскрыть, почему я так думаю.
Unified Modeling Language (UML) был разработан тремя известными сотрудниками Rational Software в начале 90-х и принят в качестве стандарта Object Management Group в 1997 году. Потребность в создании подобного языка ощущалась к тому времени довольно остро, так как программное обеспечение становилось всё сложнее. Обсуждать, описывать и продумывать его работу было всё труднее.
Понимание важности стандартных нотаций для построения моделей пришло ко мне лет 20 назад. На тот момент, еще будучи разработчиком, я искал способ донести до руководства компании предложения по улучшению бизнес-процессов. Презентовать свои идеи я решил в виде диаграмм, а поскольку на тот момент не пользовался никакими нотациями, просто изобразил всё в виде аккуратных кружочков, прямоугольников и треугольников, соединённых стрелками.
На подготовку этих диаграмм у меня ушло довольно много энергии и времени, но презентация вместо ожидаемого триумфа принесла лёгкое разочарование. Руководитель компании, просмотрев диаграммы и прослушав мою презентацию, сказал, что видит в моих предложениях рациональное зерно, но совершенно не может ухватить детали. Откровенно говоря, я списал это на счёт самого руководителя, ведь в правильности диаграмм и прорывном характере идей я был уверен. Поэтому записи свои сохранил – до лучших времен.
Спустя год, решив воплотить в жизнь одну из этих идей, я оказался ровно в таком же положении, что и руководитель компании во время моей презентации. В диаграммах явно чувствовалось рациональное зерно, но им не хватало понятной системы, а назначение «кружков», «прямоугольников» и «треугольников» к этому времени уже забылось. Именно в тот момент я и решил обратить внимание на стандартные нотации.
Когда же через несколько лет в моё поле зрения попали UML-диаграммы, они привлекли меня своей простой, но выразительной формой, хоть мне и не сразу удалось в них разобраться.
Для кого подходит UML
Как только начинаются споры о применимости UML в современных условиях, на ум приходят две известные шутки. Первая говорит о том, что в интернете на любой вопрос можно найти любой ответ. И не только в интернете, должен заметить. Книги, статьи, выступления на конференциях, мнения коллег и обсуждения на форумах демонстрируют полный спектр эмоций – от полного отрицания до фанатичной приверженности. Так кому же верить?
И тут всплывает в памяти другой диалог: «- Не люблю я котов… — Да вы их просто готовить не умеете!». На мой взгляд, секрет полезности (или неполезности) UML кроется именно в этом – в умении правильно «приготовить» диаграммы. Если человек говорит, что какая-то нотация не работает, возможно, он просто не потрудился разобраться в ней.
Может быть, эта нотация не соответствует его стилю мышления. Так и с UML: одни специалисты пользуются и получают от этого удовольствие, другие нет. Это просто выбор каждого.
В нашем мире не существует абсолютных истин. В IT-сфере тем более не стоит искать правила, которые были бы одинаково применимы и эффективны для любого проекта или ситуации. Каждый проект, команда, заказчик выбирают для себя то, что удобно им. Поэтому всё, что говорится о UML или других нотациях, – всегда частное мнение.
К тому же, для разных ролей в проектной команде UML имеет различную степень применимости. Например, UML отлично справляется с описанием технической стороны системы: архитектуры, алгоритмов, протоколов обмена, процессов и пр. Но руководителям проекта, техническим писателям и дизайнерам интерфейсов пользователя он, скорее всего, не пригодится.
Казалось бы, разработчики должны знать и использовать UML лучше и чаще всех. Но нет, довольно часто они говорят, что проще сразу начать писать код, не тратя время на рисование диаграмм. И в простых случаях такой подход действительно оказывается более выгодным.
Но при разработке больших систем с разветвлённой архитектурой и сложными структурами данных лучше сначала подумать, а потом уже кодить. Код, написанный без глубокого понимания задачи, потом будет много раз переделываться. В ходе переделок меняется логика функционирования системы, её структура становится более запутанной. Вносить очередные изменения становится всё сложнее и сложнее.
А полезен ли UML для аналитиков? Вполне! Например, системные аналитики, будучи ближе к технической реализации системы, могут использовать UML для моделирования структур данных или взаимосвязей между компонентами системы. Хотя для системных аналитиков придуманы и другие нотации, например, SysML, знание UML представляется для них ценным навыком.
Для бизнес-аналитиков применимость UML кажется заметно меньшей. Но опять-таки, это зависит от ситуации. Мне, например, UML помогает анализировать предметную область, продумывать некоторые задачи, описывать требования, проектировать структуры данных.
Чем может помочь UML
Во-первых, UML – это формальный язык, который подчиняется чётко определенным правилам. Каждая его диаграмма, каждый элемент или связь на диаграмме подчинены определённой логике, несут определённый смысл. А это означает, что следование таким правилам дисциплинирует сознание автора модели, направляет процесс его мышления по определённому руслу.
Здесь можно было бы посетовать на ограничение творческого самовыражения автора модели. Но разве это является нашей целью в ходе проекта? Пожалуй, гораздо важнее для нас донести свои идеи, открытия и решения до коллег. Донести так, чтобы не пришлось потом долго отвечать на дополнительные вопросы, а реализация в итоге соответствовала задумке.
Именно формализация позволяет создавать диаграммы, понятные другим людям (тоже знающим UML, разумеется) и не теряющие своей понятности с течением времени (как это было с моими доморощенными диаграммами годы назад).
Во-вторых, стандарт UML содержит почти полтора десятка диаграмм, что позволяет покрыть потребности разных ролей в проекте. Благодаря UML можно создать информационный фундамент для описания различных аспектов системы – начиная с верхнеуровневых требований до решений, непосредственно реализованных в коде.
К примеру, диаграмма классов (class diagram) помогает лучше понять, как распределить обязанности между разными частями системы. Причем речь идёт не только о тех классах, которые разработчик описывает в исходном коде программы. Через классы можно выразить даже понятия предметной области, что позволит лучше понять потребности заказчика и нюансы его работы.
Давайте в качестве иллюстрации попробуем описать часть системы для проведения онлайн-конференций. Судя по диаграмме ниже, встречу может создать только зарегистрированный пользователь, а участвовать в ней могут пользователи двух типов: простые участники и один или несколько ведущих (хостов). Если встреча является повторяющейся, тогда для неё задаются параметры периодичности.
На диаграмме присутствуют и английские названия, и русские, типы данных у одного класса выглядят стандартными, а у другого названы в свободной форме, у пары классов показаны атрибуты, у одного – только операции. Не очень аккуратно, да? Но если знакомый разработчик скажет вам, что это не классы, не верьте.
Это пример диаграммы концептуальных классов, с помощью которой мы можем описать предметную область на очень высоком уровне. Разработчики, конечно же, будут использовать другие классы, таблицы базы данных тоже будут выглядеть по-другому, но эта концептуальная диаграмма позволит аналитику и лучше разобраться в проблеме, и чётче описать требования к ее решению.
Диаграмма деятельности (activity diagram) описывает процесс, в котором одна операция следует за другой, подчиняясь определённой логике. Она позволяет изобразить алгоритмы принятия решений, бизнес-процессы или выполнение пользователями тех или иных действий в системе. Как правило, диаграммы этого типа бывают понятны даже далеким от IT-сферы людям.
Диаграмма вариантов использования (use case diagram) описывает сервисы, предоставляемые системой внешнему миру, и действующих лиц, которые имеют доступ к этим сервисам. Эта диаграмма бывает полезна в самом начале проекта, когда еще нет чёткого представления о том, как именно должна работать разрабатываемая система. Такое понимание как раз и формируется в ходе построения, обдумывания и обсуждения диаграммы.
Ещё одним важным результатом являются вопросы, которые неминуемо возникают у аналитика при построении диаграммы вариантов использования. Эти вопросы позволяют глубже изучить предметную область и потребности заказчика, уточнить требования к системе и в результате предложить наиболее подходящее для заказчика решение.
Эта статья не предполагает знакомство с каждым типом диаграмм UML, приведённые примеры стоит рассматривать лишь как очень поверхностную иллюстрацию возможностей UML и его пользы на различных этапах проекта.
Например, диаграмма состояний (state machine diagram) позволяет описать жизненный цикл объекта в виде графа, вершинами которого являются состояния, а дугами – события или действия, ведущие к смене состояния.
В-третьих, UML – это наглядный способ для поддержки процесса мышления. Он позволяет разбить задачу на части, продумать их по отдельности, а потом склеить в комплексное финальное решение.
Когда мы описываем что-либо с помощью текста, информация воспринимается последовательно. И не важно, о каком тексте идет речь: это может быть и текст требований, написанный на естественном (человеческом) языке, и исходный текст программы, написанный на алгоритмическом языке. В любом случае, чтобы понять смысл текста, мы должны читать его символ за символом, слово за словом, строку за строкой. А значит, часть информации, прочитанная раньше, может забыться или исказиться. Плюс к этому, чтобы найти какой-то определённый фрагмент, приходится затрачивать время на повторный просмотр текста.
Но если информацию представить в виде диаграммы, вся картина будет видна полностью (разумеется, если диаграмма построена правильно и не перегружена деталями). В таком случае сразу видны все элементы и связи между ними, а взгляд без труда находит нужный фрагмент диаграммы. Такую диаграмму можно использовать в качестве «карты», помогающей ориентироваться в большом количестве проектных артефактов.
Какие подводные камни могут омрачить впечатление об UML
UML изучают в институтах, но довольно часто это процесс не привязывают к жизни, не подкрепляют реальными примерами. И вместо того, чтобы стать для IT-специалиста родным языком, UML начинает казаться языком мертвым, похожим на латынь.
Главная сложность в освоении UML состоит в том, что для построения диаграмм требуется определенный стиль мышления. Например, классы – это достаточно абстрактная концепция. Если приучить себя мыслить классами, видеть примеры во внешних предметах и событиях, построение диаграммы не вызовет больших затруднений. Если же человек не обладает стилем мышления, созвучным логике UML, моделирование будет казаться занятием непонятным, трудным и не очень полезным.
Критики, говоря о недостатках UML, упоминают:
- Сложность. Если конкретному человеку трудно постичь суть языка UML, этот язык будет казаться сложным для этого человека. Но не обязательно для всех.
- Избыточность. UML содержит много типов диаграмм, каждая диаграмма – много разных элементов. Разные диаграммы и разные элементы нужны в разных ситуациях и едва ли одному человеку потребуется весь объём возможностей UML. Выучить UML целиком, во-первых, довольно сложно, а во-вторых, польза от этого знания сомнительна. Зачастую достаточно взять на вооружение всего несколько диаграмм и превратить их в удобный инструмент для продумывания и донесения своих идей.
- Попытка «быть всем для всех». UML изначально был задуман как максимально универсальный язык моделирования, содержащий набор возможностей на все случаи жизни. Но, как уже было сказано выше, никто ведь не заставляет нас использовать его в полном объёме и во всех ситуациях. И если что-то из UML нам не потребовалось на практике, это не значит, что весь язык мы должны признавать неприменимым.
Получается, что трудности в работе с UML – штука очень субъективная. Главное, что все эти трудности преодолимы (в основном) и управляемы. Если UML в целом нравится и человеку кажется, что он может применить его в своей практике, аргументы «за» найдутся легко. В противоположной ситуации доводы «против» подобрать также не составит особого труда.
Я не считаю, что нужно бороться за повсеместное внедрение UML, чтобы все айтишники его знали на 100%. На мой взгляд, нужно просто использовать UML разумно и рационально в тех случаях, когда он уместен.
Неочевидные случаи: опыт применения UML в Agile-проекте
Этот случай в моей практике был уникальным, но достаточно показательным. Он произошел лет 10 тому назад, когда UML уже стал для меня привычным инструментом анализа и продумывания решений.
Работая коучем с начинающими Agile-командами, я получил от одной из команд запрос на помощь в планировании. Суть проблемы состояла в том, что коллеги разработали 130 user stories, но описали их в виде простого линейного списка. Поэтому при планировании каждого спринта им приходилось весь этот список просматривать, что c каждым разом становилось всё труднее и труднее.
Поскольку в суть проекта я глубоко не вникал, пришлось попросить команду немного рассказать о том, какая система разрабатывается и для чего. Пока коллеги рассказывали, я рисовал на доске картинки – просто чтобы не упустить ничего важного. Сначала это были абстрактные рисунки, но как только идея системы стала проясняться, я совершенно автоматически перешел к рисованию вариантов использования (use case diagram). Вот тут-то я впервые услышал вопрос «А что, UML ещё жив?». Оказалось, что не только жив, но и достаточно бодр.
Как правило, в технологии Agile-разработки не находится места долгим медитациям над UML-диаграммами, поэтому коллеги сначала приняли мои художества как кощунство и приверженность устаревшим технологиям. Но всё оказалось проще. Благодаря диаграмме вариантов использования мы выделили главных действующих лиц, затем определили основные функциональные блоки и разбили их на фичи.
А потом всё это обозвали эпиками и организовали в виде дерева. После этого осталось лишь распределить все user stories по узлам этого дерева (т.е. по эпикам). И чудо свершилось – вместо громоздкого и неудобного линейного списка мы получили удобную и логичную структуру, работать с которой стало несоизмеримо проще.
Кстати, как только мы распределили user stories по дереву, стало видно, что одна из трёх подсистем уже практически готова – оставалось доделать лишь одну стори. Раньше об этом никто и не подозревал, так как структура требований отсутствовала и, как следствие, было трудно понять, к чему относится каждая user story. Поэтому команда и «буксовала», не понимая, куда двигаться дальше.
Ту диаграмму вариантов использования я безжалостно с доски стёр – свою задачу она уже выполнила, сохранять её в документах проекта просто не было смысла.
Таким образом, UML нужен не только для того, чтобы нарисовать красивую диаграмму и внести её в какой-то документ или опубликовать на сайте. UML является отличным инструментом для продумывания технических проблем и обсуждения их с коллегами. Диаграммы UML позволяют увидеть картину в целом, структурировать её, найти недостающие звенья, сформулировать вопросы заказчику или разработчикам. А потом обогатить диаграммы полученными ответами.
Источник: techrocks.ru