Лабораторная работа Бумажное прототипирование пользовательских интерфейсов 6
Скачать 144.48 Kb.
|
Лабораторная работа № 4. Исследование сред взаимодействияПорядок выполнения работы1 Изучить основы построения use case-диаграмм и диаграмм деятельности. 2 Построить use case-диаграммы. Построить диаграммы деятельности для каждого варианта использования. Оформить отчет. Осуществить защиту работы. Краткие теоретические сведенияКарты элементов use case. Элементы use case не существуют отдельно от внешнего мира. Полноценная программная система должна обеспечивать поддержку десятков, а то и сотен элементов use case, причем внутри каким-то образом связанного с ней приложения должна существовать связь между этими элементами. Отображение взаимосвязи между приложениями дает возможность описать общую структуру задачи, решаемой приложением и его интерфейсом. Карта элементов use case для данной задачи разбивает все функциональные возможности системы на множество взаимосвязанных сущностных элементов use case. Выделив все различающиеся и важные взаимодействия и показав отношения между ними, можно создать упрощенную общую модель задач, решаемых системой, и возможностей, которые она обязана предоставить. Полноценная модель use case представляет собой множество описаний, определяющих суть всех элементов use case, и карту этих элементов, показывающую отношения между ними. Между сущностными элементами use case могут существовать отношения разных типов, включая специализацию, расши рение, композицию, а также сходство. Знание этих отношений позволяет ана литику или разработчику выделить общие элементы задачи и в итоге создать более простую модель задачи. Специализация. Некоторые элементы use case могут являться специализированными версиями других элементов. Например, при разработке приложения «банкомат» элементы use case «получение Денег», «размещениеСредств» и «запросСостояния» являются субклассами, или специализированными вариантами абстрактного класса взаимодействий, который может быть назван «использованиеБанкомата». Что касается отношения между элементами «получениеДенег» и «использованиеБанкомата», то его можно охарактеризовать как классификацию, или специализацию. Такой тип отношения означает, что один элемент use case «является» («ts-а») специализацией другого. В объектно-ориентированном анализе и проектировании такое отношение соответствует отношению класс-подкласс. Специализация дает возможность упростить общую модель use case путем отделения общих или универсальных форм взаимодействия от специфических форм, адаптированных для более узкого применения. Таким образом, нет необходимости переписывать заново самые общие паттерны применения. Достаточно написать их один раз, а затем лишь «повторно использовать» («reuse»), ссылаясь на них. Для отображения отношения специализации используется двойная стрелка. Рядом со стрелкой можно встретить подпись «is-а» или «specialize» в зависимости от контекста. Расширение. Одной из инноваций в объектно-ориентированной программной инженерии, навеянных идеями Якобсона, стало признание расширения одним из возможных отношений между элементами use case. Говорят, что один элемент «расширяет» другой, когда он содержит вставляемые или альтернативные паттерны взаимодействия, которые войдут в расширяемый элемент. Например, при отработке элемента use case для изменения внешнего вида какой-то части экрана пользователю необходимо заниматься поиском по всей системе файла, содержащего нужную картинку или значок. Нормальное, или ожидаемое, развитие событий (обеспечивается базисом, или базисным элементом use case) тем не менее вовсе не подразумевает поиск каких-то дополнительных графических файлов. Расширение – это удачная концепция, позволяющая значительно упростить сущностные модели use case. На карте элементов use case отношение расширения изображается в виде пунктирной линии со стрелкой и имеет подпись «extend». Если для расширения дается дополнительное описание, в него может быть включено примечание, показывающее, какие элементы use case расширяются. Композиция. Элементы use case можно декомпозировать на составные части, или подэлементы. являющиеся подчиненными или включенными паттернами взаи- модействия. Отношение композиции обозначается на карте элементов use case пунктирной стрелкой, указывающей на подэлемент use case и имеющей метку «include». Взаимодействие, описываемое суперэлементом use case, осуществляется при помощи взаимодействий, входящих в подэлемент или подэлементы. Причем описание суперэлемента будет ссылаться на все используемые подэлементы. Например, элемент use case под названием «началоПротоколированияЗадачи», созданный для программы, отслеживающей ход выполнения задач, может использовать элементы «авторизацияДоступа» и «вводПараметровЗадачи». Такой способ моделирования взаимодействий позволяет разделить независимые и почти никак не связанные между собой подзадачи «авторизацииДоступа» и «вводаПараметровЗадачи». Диаграммы деятельности. Для описания функциональных требований, помимо диаграмм вариантов использования, применяются диаграммы деятельности: для описания поведения, включающего большое количество параллельных процессов; для анализа варианта использования (описывают последовательность действий и их взаимосвязь); для анализа потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельности являются средством представления и анализа их поведения. Контрольные вопросыЧто такое карта элементов use case? Что означает роль на use case-диаграмме? В чем заключается суть отношения специализации? Приведите пример. В чем заключается суть отношения расширения? Приведите пример. 5 В чем заключается суть отношения композиции? Приведите пример. Чем отличается отношение специализации от расширения? Что собой представляет диаграмма деятельности? В чем заключаются отличия use case-диаграммы от диаграммы деятельности? |