Переходы (transition) и ветвление (decision)

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

Если из блока выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то сработать может только один из них. Именно в этом случае для каждого из таких переходов должно быть явно записано сторожевое условие в квадратных скобках. При этом для всех выходящих из некоторого состояния переходов должно выполняться требование истинности только одного из них. Такая ситуация получила название ветвления и для ее обозначения нужно использовать специальный символ ветвления. Он обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 11.73). В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Принято входящую стрелку присоединять к верхней или левой вершине символа ветвления. Если выходящих стрелок 2, то допускается использовать вместо одного сторожевого условия слово «иначе», указывающее на тот переход, который должен сработать в случае невыполнения сторожевого условия ветвления.

Рисунок 11.73 – Алгоритм нахождения корней квадратного уравнения

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

В языке UML для этой цели используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Таким символом является прямая черточка, аналогично обозначению перехода в формализме сетей Петри. Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы деятельности. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих (рис. 11.74, а). Слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (рис. 11.74, б). Также допустимо использовать эту конструкцию и в вертикальном положении.

Рисунок 11.74 – Разделения и слияния параллельных потоков управления

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

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

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

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

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

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

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

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

3) Проанализируйте предложенную диаграмму и установите последовательность действий, которую она выполняет.

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

4) Перестройте предложенную диаграмму на использование растворимого кофе без кофеварки.

1) Назовите этапы создания пользовательского интерфейса.

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

На следующем этапе мы готовим подробный перечень функциональности (user stories).

Теперь мы начинаем непосредственно проектирование. Основной документ, который по-лучается в итоге этого процесса – детальные схемы (wireframes), которые показывают, какая ин-формация и элементы управления должны располагаться на страницах системы.

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

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

2) Раскройте понятие «структурные схемы страниц».

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

Это основной результат работ по проектированию интерфейса. Они в деталях показывают, какая информация и элементы управления должны выводиться на каждой странице системы. А также расставляют акценты – какие из элементов страницы более, а какие – менее важны. Wireframes также описывают поведение динамических и AJAX-элементов страниц – как они должны реагировать на действия пользователя.

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

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

3) Охарактеризуйте такой способ взаимодействия с заказчиком, как пользовательские истории.

Пользовательские истории (User Story) – способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований. Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке, что гарантирует её малый размер. Разработчик может использовать серию вопросов, чтобы подтолкнуть клиента и выяснить необходимость некоторых специфических функций. Пользовательская история остается неофициальным определением требований с ограничениями:

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

· они требуют постоянного контакта с клиентом на протяжении всего проекта;

· они полагаются на компетентность разработчиков;

Текст самой истории должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которую пользователь получит после того как история случится. К примеру:

Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то целью>.

Пожелание пользователя представляет собой карточку с заголовком и несколькими строчками текста. Примеры: «Как администратор сайта я хочу управлять рекламными объявлениями, чтобы удалять устаревшие или ошибочные объявления»; «Как рекламодатель, я хочу, чтобы у меня была возможность фильтровать объявления для поиска лучших предложений рынка».

Практические советы по написанию пользовательских историй:

· Лучше написать много историй поменьше, чем несколько громоздких.

· Каждая история в идеале должна быть написана избегая технического жаргона.

· Истории должны быть написаны так, чтобы их можно было протестировать.

· Как можно дольше стоит избегать UI. История должна выполняться без привязки.

· История должна иметь концовку – т.е. приводить к конкретному результату.

4) Спроектируйте набросок wireframe по представленной диаграмме use case.

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: