Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой.
Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).
В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии.
Те кто читал предшествующие статьи, не удивится утверждению, что проектирование начинается с маркетинга. Даже если программа заказана в рамках одного предприятия, подход описанный в книгах о маркетинге поможет сделать первые шаги в правильном направлении. Программы пишутся для пользователей, и никакие прорывные или модные IT технологии не сделают её удачной. Приложение должно решать проблемы пользователя, делая его жизнь проще.
Рассматриваемые в данной статье диаграммы Деятельности и Состояний, показывают, действительно ли вы проектируете, что-то ценное или просто повторяете существующий порядок вещей.
Как и в предыдущем случае, проектирование с помощью этих диаграмма начинается не с пустого места. Диаграмма Прецедентов разделила планируемый функционал на отдельные модули, и теперь, можно приступить к описанию того как они будут работать.
Идеальным источником знаний для начала проектирования с использованием этих диаграмм являются задокументированные схемы бизнес-процессов. Но в реальности так не бывает. В тех редких случаях, когда они все таки есть, они уже устарели и не отражают реальность. Разработчики не должны руководствоваться бизнес-процессами заказчика, слепое их повторение только усложнит этап внедрения.
Диаграммы Деятельности и Состояний это первый шаг на пути погружения в технические детали проекта. Продолжая аллегорию, эти диаграммы помогут вам по колено зайти в озеро технических деталей. Именно на этом этапе вы сможете сами разобраться в том, как будет работать будущая программа и показать заказчику все ее планируемые особенности.
Для того, чтобы проект представлял техническую ценность придется провести сложный, иногда нудный, но необходимый анализ действий подлежащих автоматизации.
С данного момента, вынужден погрузить вас в теоретические особенности построения описываемых диаграмм. Если вы знакомы с теорией автоматов, то понять описываемое будет достаточно просто, если нет, придется приложить чуть больше усилий, так как эта статья не о самой теории, а о практике ее применения.
Автоматом называют абстрактную модель в виде некоторого «черного ящика», осуществляющего преобразование входных данных в выходные с помощью алгоритма. Возьмем наглядный пример. Необходимо вымыть руки, берем воду, мыло и так далее, процесс понятен. Объединим все описанное понятием автомата.
В качестве входных параметров, кроме грязных рук, нам необходима вода и мыло, а на выходе мы получаем чистые руки. Теперь, мы имеем абстрактную модель, которую можем использовать в других процессах. После работы мы можем вымыть руки или сделать это перед едой.
Автомат для которого известны все входные и выходные параметры, называется конечным автоматом. Собственно наша задача, на данном этапе, заключается в том, чтобы перевести весь функционал проектируемой программы в набор конечных автоматов. Неопределенное поведение всегда выливается в проблемы с безопасностью.
Пример. В некоей организации было принято, что оплату товара отмечали путем установки галочки на форме выдачи заказа. При этом не проверялось, кто это сделал, так как оплату могли подтвердить сотрудники разных подразделений. Догадаться не сложно. Появилась схема кражи, делается обычный заказ, внутри кто-то подтверждает без оплаты, товар выдается, продается, деньги делятся.
Еще один пример, более технический. Криптографический протокол SSL 2.0. При получении данных в ответ на запрос, они помещаются в буфер без проверки размера. В результате возникает риск переполнения буфера, с возможностью нарушить работу или даже захватить управление удаленным компьютером. Пришлось срочно разрабатывать версию SSL 3.0. С марта 2011 года, клиенты не должны использовать протокол SSL 2.0 при запросе подключения к серверу, а серверы должны отклонять такие запросы.
Помимо входящих и исходящих данных конечные автоматы содержат конечное количество состояний. Состояние автомата — это внутреннее состояние устройства, которое определяет его поведение при получении входных данных. Таким образом, существуют более сложные автоматы, реакция которых зависит не только от входных данных, как у функций. Но и от того, что было раньше, то есть каждой паре «состояние – входной сигнал» соответствует однозначно определенное состояние.
Соберем все возможные пары в одну таблицу переходов.
Давайте рассмотрим, что же можно понять с помощью такой таблицы.
Самое важное, мы можем смоделировать все возможные варианты поведения. Выявить варианты которые не были учтены при описании бизнес-процессов. Учесть их в проекте или просто оповестить заказчика о возможном неопределенном поведении. Если бы разработчики из примеров выполнили подобный анализ, возможно никакой проблемы с безопасностью и не возникло.
Второй целью анализа состояний является задача минимизации. Построить программный продукт с наименьшим числом компонентов модели и при этом функционально эквивалентным заданному.
В примере с мытьем рук очевидно, что мыть руки стоит только когда они грязные, у нас есть вода и мыло. Получается логическое выражение:
грязные руки и вода и мыло = чистые руки
Все остальные варианты можно проигнорировать. Для такого бытового примера, это очевидно, но если мы проектируем что-то сложное, таким методом можно выявить потенциальные ошибки еще на этапе проектирования или рассмотреть дополнительные возможности.
Например. В проектируемой игре герой может прыгать, перепрыгивая препятствия. Если игрок одновременно нажимает кнопку прыжка и движения в бок, его можно ограничить. Заставить героя «скатиться» по стене, а можно сделать так что герой запрыгнет на второй этаж. Главное знать что такая возможность существует, и не «потерять» героя в текстурах.
Завершим рассмотрение примера из теоретической части, построением диаграммы состояний.
Диаграмма состояний в графическом виде представляет собой построенную ранее таблицу. Графическое представление более универсально и читабельно. Легко интерпретируется людьми не имеющими технической подготовки, например заказчиком.
Однако здесь стоит учитывать, что диаграмма состояний, это не диаграмма конечного автомата. Для моделирования конечных автоматов существуют свои диаграммы. В диаграмме состояний необходимо отразить только важные для нашего проекта состояния и переходы.
Если же вас захватила теория автоматов, то существует специальная парадигма программирования, называемая «Автоматное программирование». Где весь функционал рассматривается как набор конечных автоматов, но такая парадигма применяется в довольно узких областях.
Осталось только описать часто допускаемые ошибки при составлении диаграммы состояний.
Смешение понятий, состояние и действие. Понятие состояния достаточно абстрактное, к тому же оно зависит от контекста. Например, грузить уголь — вымыть руки — обедать. С одной стороны, это последовательность действий, если рассматривать это с личной точки зрения грузчика. Для внешнего наблюдателя, это переходы из одного стабильного состояния в другое. Диаграмма состояний отражает возможности и направление перехода из одного состояния в другое, при этом, над стрелкой указывается триггер, который приводит к переходу в указанное состояние. Для смены состояния грузить уголь, триггером является время обеда, для вымыть руки — грязные руки. Следовательно на такой диаграмме не может быть условий, ветвления переходов или их слияния.
Слишком много состояний на одной диаграмме. По неопытности, составители такой диаграммы часто помещают на неё множество элементов, однако восприятие человека не в состоянии оценить их все одновременно. По опыту, оптимально когда на листе помещены 5-6 состояний и их переходов, большее количество усложняет чтение, а если состояний больше 10, делает ее не читаемой.
Составим диаграмму состояний для сквозного примера, с электронной библиотекой. Рекомендую, начинать составление с определения состояний, «накидаем» прямоугольники и опишем их.
Рабочий экран. Открывается при запуске приложения. На нем расположен список литературы с которой мы работали, то есть читаемые и прочитанные книги. На данном этапе лучше не погружаться в детали. Деталями может заниматься UX/UI дизайнер, необходимо помнить, что эти диаграммы необходимы для согласования с заказчиком.
Каталог книг. Представляет систему поиска книг в библиотеке. И теперь мы не погружаемся в технические детали. Очевидно, что поиск книг является сложным компонентом и его следует рассматривать отдельно, на отдельной диаграмме состояний.
Книга. Пространство для чтения. В этом окружении предполагается чтение текста выделение цитат и дополнение комментариями. Это главный, самый часто используемый экран приложения, как и в предыдущих случаях, не стоит погружаться в детали. UX/UI дизайнер и заказчик выберут оптимальную стратегию работы с ним. Мы в дальнейшем, опираясь на согласованную и утвержденную раскадровку дизайна сможем детализировать техническую реализацию.
Конспект. Пространство отображающее выбранные нами цитаты и комментарии из указанной книги. Без основного текста.
Когда состояния описаны можно проследить переходы из состояния в состояние и определить триггеры которые приводят к переходу.
Взаимодействие с программным продуктом начинается с рабочего экрана. Пользователь может выполнить переход в каталог книг для выбора книги, либо выбрать книгу для чтения, либо конспект для ознакомления. Между отображением книги и конспекта можно переключиться или вернуться на рабочий экран. Выйти из приложения можно из любого состояния.
Диаграмма состояний построена, теперь от частных случаев перейдем к общему пониманию.
Обобщим все описанное выше и ответим на вопрос, когда и зачем необходимо строить диаграмма состояний.
Основным назначением диаграммы является выявление и описание всех возможных зависимостей между данными и реакцией проектируемой системы. Проследить зависимости и определить кратчайшие пути движения данных. Именно так получилось, что раньше для платежа необходимы были отделения банка, специальные бланки, наличные деньги, паспорт, помещение с инфраструктурой, начиная от сейфа и до кассира. Теперь, стало достаточно двух мобильных устройств.
Построение диаграммы состояний дает наибольшую отдачу в момент переноса бизнес-процессов в проектную документацию. Как правило, проектировщик может взглянуть на устоявшиеся процессы со стороны, и при необходимости использовать математический аппарат, из раздела теории графов, чтобы оптимизировать процессы. На более техническом уровне, помогает избежать неопределенного поведения, но эту часть лучше переносить на команду разработчиков, за счет дополнительной подготовки и расширения знаний по теории автоматов и теории графов.
Когда с диаграммами состояний разобрались, перейдем к диаграмме действий. Как правило, её построение не вызывает сложностей, каждый кто учился программированию сталкивался с ними. Они помогают графически выразить последовательность действий.
Диаграммы действий строятся совместно с диаграммами состояний. Описывая последовательность действий при смене состояний, от триггера до триггера. При этом диаграмма может содержать элементы, которые также интерпретируются как состояния и на следующем уровне детализации описывают алгоритмы.
Стоит учитывать, что излишняя детализация только усложняет чтение диаграмм. Оптимальное количество элементов на одной диаграмме действия обычно располагается в диапазоне от 10 до 20 фигур. Алгоритм описываемый меньшим количеством элементов кажется очевидным, а большое количество элементов усложняет понимание диаграммы. При построении диаграмм следует не забывать, что они строятся для заказчика. Заказчик должен не только просмотреть их, но и понять, и по возможности поправить разработчика, если он допустил расхождения с бизнес-процессами.
Завершая описание диаграммы действий, в качестве примера, опишем алгоритм действий при работе с книгой, из сквозного примера электронной библиотеки.
Выполнение алгоритма начинается из состояния работы с книгой. У нас нет UX/UI дизайна для нашего приложения, поэтому ограничимся очевидными моментами. Текст книги отражается на экране. Цитаты выделяются в виде блоков. Способ выделения не важен, так как это может быть веб, мобильное или настольное приложение, мы заранее не ограничиваемся.
Если после выделения блока текста пользователь решает ввести текст, то выделение становится комментарием. Разница в определении обуславливает поведение, перекрывание областей выделения, расширяет конечную область при цитировании. Комментирование не влияет на область выделения, комментарии могут перекрываться.
В качестве заключения обобщим все выше сказанное. Основное назначение диаграмм состояния и действий является, отражение бизнес-процессов заказчика в технически адаптированный вид. Трансформация бизнес-процессов должна способствовать выявлению неточностей и неопределенного поведения, акцентировать внимание на местах, когда принятие решений зависит от внешних, относительно программного продукта, факторов. При возможности, упрощать бизнес-процессы за счет применения теоретических и технических приемов.
Эти диаграммы служат своеобразным переводом с технического в язык бизнеса, поэтому должны быть в достаточной мере понятны всем сторонам проекта.
В конце статьи, хотелось бы дать совет. Впрочем если вы читаете все статьи подряд, вам он известен. До конца проектирования не принимайте технологических решений. Когда, в самом начале, определяете удобные вам фреймворки, языки программирования, программные интерфейсы, в ходе проектирования, невольно подгоняете все решения под них, ограничивая поле для выбора.
Думаю все пользовались решениями у которых веб приложение значительно отличается от мобильной версии. Например как в некоторых банках. Почему они такие разные, когда опыт подсказывает, что если интерфейс обоих вариантов подобен, пользователям проще использовать приложение. Весь User Experience (UX) построен на этом.
Это не связанно с техническими требованиями, как многие утверждают. В большинстве случаев это обусловлено тем, что перед проектированием, сразу были выбраны технические решения, а все последующие действия были подогнаны под них. Если сомневаетесь, проанализируйте, почему у популярных программ обмена сообщениями, на всех платформах, внешний вид подобен.