Диаграмма последовательности

Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательности.

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

Линия жизни объекта (objectlifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе. В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия, или состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focusofcontrol). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а его нижняя сторона - окончание фокуса управления (окончание активности).

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

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

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

· Вызвать

· Возвратить

· Создать

· Уничтожить

· Послать

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

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

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

Диаграмма кооперации для снятия объектом 20$

Диаграмма последовательности

15. Задачи прототипирования пользовательского интерфейса информационной системы. Виды прототипов. Критерии выбора инструмента для прототипирования пользовательского интерфейса информационной системы

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

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

Задачи прототипирования:

· определение и формулировка задач, которые решает данный интерфейс и функций, которые он выполняет.

· сокращение цикла разработки продукта

· минимизация доработок и, соответственно, уменьшение временных и трудовых затрат

Прототипы могут быть статическими и динамическими.

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

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

В качестве основных критериев выбора инструмента прототипирования (ИП) принимаются следующие критерии:

Ø Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.

Полный жизненный цикл ИС должен поддерживаться "сквозной" технологической цепочкой средств разработчика, обеспечивающей решение следующих задач:

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

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

· проектирование моделей приложений (логики приложений и пользовательских интерфейсов);

· прототипирование приложений;

· проектирование баз данных;

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

· разработка распределенных баз данных (с выбором оптимальных вариантов распределения);

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

· адаптация к различным системно-техническим платформам и СУБД;

· тестирование и испытания;

· сопровождение, внесение изменений и управление версиями и конфигурацией ИС;

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

· администрирование ИС (оптимизация эксплуатационных характеристик);

· управление разработкой и сопровождением ИС (планирование, координация и контроль за ресурсами и ходом выполнения работ);

· прогнозирование и оценка трудоемкости, сроков и стоимости разработки.

Ø Обеспечение целостности проекта и контроля за его состоянием.
Данное требование означает наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность базы проектных данных (репозитория).

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

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

Помимо перечисленных основных критериев, предварительный анализ при выборе СП должен учитывать следующие аспекты:

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

Ø Открытая архитектура и возможности экспорта/импорта.
Открытая и общедоступная информация об используемых форматах данных и прикладных программных интерфейсах должна позволять интегрировать инструментальные средства третьих фирм и относительно безболезненно переходить от одной системы к другой.

Ø Простота использования.

Учитываются следующие характеристики:

· Доступность пользовательского интерфейса;

· Время, необходимое для обучения;

· Простота инсталляции;

· Качество документации.

Ø Обеспечение качества проектной документации.
Это требование относится к возможностям СП анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам (включая ГОСТ, ЕСПД).

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

16. Статический и динамический прототипы системы: основные отличия и особенности создания прототипов. Примеры статичеких прототипов. Примеры динамических прототипов

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

Различают два типа прототипов: статические и динамические.

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

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

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

Статические и динамические прототипы также различаются по среде реализации, так например статические прототипы чаще всего выполняются в бумажном виде, виде быстрых скетчей в графическом формате. Динамические прототипы чаще всего реализуются в виде html+css (для web), линкованных страницах pdf (что достаточно удобно), различных специальных средствах прототипирования, обладающих своими возможностями, а также часто применяют flash.

Некоторые устоявшиеся способы статического и динамического прототипирования:

§ Бумажное прототипирование

Скорость создания: высокая

Детализация: высокая

Повторная отрисовка: да

Возможность изменений: нет

Интерактивность: нет

Дополнительные характеристики: возможность для респондентов при тестировании прототипа производить пометки на прототипе с целью улучшения

§ HTML+CSS

Скорость создания: средняя

Детализация: высокая

Повторная отрисовка: нет

Возможность изменений: да

Интерактивность: да

Дополнительные характеристики: возможность предоставления доступа к прототипу большого числа разработчиков и респондентов

§ Доска для прототипирования

Скорость создания: средняя

Детализация: средняя

Повторная отрисовка: да

Возможность изменений: зависит от способа работы, в общем случае изменения ограничены технически

Интерактивность: нет

Дополнительные характеристики: возможность командной разработки и обсуждения

17. Характеристика и назначение различных видов прототипов пользовательского интерфейса информационной системы

Прототипи́рование (англ.prototyping) – это быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом. После этапа прототипирования обязательно следуют этапы пересмотра архитектуры системы, разработки, реализации и тестирования конечного продукта.

Интерфейс пользователя, он же пользовательский интерфейс (UI — англ.userinterface) — разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая — машиной/устройством. Представляет собой совокупность средств и методов, при помощи которых пользователь взаимодействует с множеством различных, чаще всего сложных, элементов, машин и устройств.

Виды прототипов: структурные схемы страниц, интерактивный или кликабельный прототип, функциональный прототип.

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