1) Выбрать три наиболее значимых прецедента на диаграмме прецедентов, для каждого из них создать диаграмму взаимодействий.
2) Для каждой диаграммы определить объекты, участвующие во взаимодействии, расположить их на диаграммах.
3) Определить сообщения между объектами на диаграммах, создайте необходимые операции для классов.
1) Цель работы.
2) Задание по лабораторной работе.
3) Диаграмма классов.
4) Описание всех этапов построения диаграмм.
5) Выводы по проделанной работе.
1) Что общего и в чем различие понятий класса и объекта?
2) Что такое классификатор объекта, какие значения он может принимать?
3) Какие элементы UML обычно присутствуют на диаграмме последовательностей?
4) Почему при добавлении объекта на диаграмму последовательностей он не появляется в проводнике по модели UML?
5) С операцией какого элемента связывается сообщение?
6) Каким образом можно указать аргумент для операции в сообщении?
7) Назовите все типы динамических диаграмм, поддерживаемых Visio и их названия по книге [3].
Цель работы: получение навыков сопоставления различных точек зрения на информационную систему, разработки нескольких диаграмм, рассматривающие различные аспекты информационной системы, проведение рефакторинга системы.
Существует много различных методов проектирования, которые акцентируются на различных аспектах информационной системы. Так, функциональный анализ разбивает систему на отдельные функции, а объектно-ориентированный анализ на объекты. Каждый из подходов имеет свои преимущества, но все они не лишены и недостатков – не основным чертам уделяется меньшее внимание.
В объектно-ориентированном анализе в первую очередь строится структурная схема. При ее построении динамические аспекты поведения системы не учитываются, однако они могут оказать существенное влияние.
Например, при проектировании структуры системы составления расписания мы можем выделить сущности «студенты», «преподаватели» и «аудиторий». Однако начав расписывать диаграммы последовательностей для прецедентов «ввод данных», «выбор свободной пары» или другие, мы обнаружим, что над этими сущностями осуществляются одинаковые действия, например, просматривается их расписание. При этом можно значительно упростить диаграммы последовательностей, введя абстрактную сущность «участник пары» и сделав имеющиеся сущности наследниками.
Хотя в рассмотренном примере «участник пары» мог появиться уже на этапе построения диаграммы классов, тем не менее, выявление общих свойства классов при построении диаграммы последовательностей встречается довольно часто. В общем случае, при построении любых диаграмм могут открываться свойства системы, которые желательно учесть на ранее созданных диаграммах.
Изменение структуры системы (без изменения ее внешних свойств) называется рефакторингом. Основная цель рефакторинга – упростить систему, сделать ее более понятной. В общем случае рефакторинг может проводиться даже на стадии программирования, когда часть системы уже реализована.
Изменение уже частично спроектированной системы требует дополнительной работы. Не всегда результат оправдывает затраты на эту работу. Однако, во многих методиках проектирования и разработки информационных систем рекомендуется проводить рефакторинг как можно чаще и раньше, во всех случаях когда есть возможность упростить систему, поскольку это позволит значительно сэкономить на последующих стадиях – программирование, тестирование, отладка, внедрение.
В текущей лабораторной работе нужно попытаться упростить структурную схему (диаграмму классов) после построения диаграмм взаимодействий (последовательностей).
Некоторые динамические свойства системы отображаются на структурной схеме средствами Visio – в классах появятся операции, введенные на диаграммах последовательностей. Если количество операций в различных классах сильно отличается, то это может говорить о несбалансированности нагрузки на классы. Также нужно обратить внимание на частоту использования объектов на диаграмме последовательностей – если объекты какого-либо класса используются слишком часто, то, возможно, класс имеет слишком много обязанностей.
Проанализировав все диаграммы можно попытаться перераспределить обязанности между классами (или создать/сократить какие-либо классы). Главная цель и критерий необходимости всех изменений – упрощение системы, т.е. улучшение понимания диаграмм их читателем, уменьшение количество связей между элементами, приведение количество элементов к удобному для восприятия числу (от 3 до 5).
1) Проанализировать диаграммы взаимодействий, выявить функционально недогруженные или перегруженные, имеющие общие свойства объекты и классы.
2) Провести перераспределение обязанностей между классами, переделать таблицы «сущность-связь-ответсвенность».
3) Переделать диаграммы классов и взаимодействий в соответствии с внесенными изменениями
1) Цель работы.
2) Задание по лабораторной работе.
3) Переделанные диаграмма классов и взаимодействий.
4) Описание всех этапов переделки диаграмм.
5) Выводы по проделанной работе.
1) Какое количество элементов одного уровня на диаграмме считается оптимальным для восприятия?
2) Что такое рефакторинг, и в каких случаях его нужно проводить?
3) Как связанны между собой диаграммы классов и последовательностей?
4) Как связанны между собой объекты и классы UML?
5) Какие виды диаграмм UML относятся к статическим? динамическим?
6) Какие диаграммы могут быть изменены в процессе рефакторинга?
7) Каким образом удалить или добавить класс в модель UML?
Цель работы: изучение элементов UML, присутствующих на диаграммах компонентов и развертывания, и их расширений, получение навыков построения диаграмм компонентов и развертывания.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.