Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
lp_IPOVS_TP.doc
Скачиваний:
237
Добавлен:
13.08.2019
Размер:
2.88 Mб
Скачать

2. Шаг второй

Для лучшего понимания структуры программы строится диаграмма вариантов использования, (диаграмма прецедентов):

Пример диаграммы прецедентов системы «Банкомат» изображен на рис. 1.

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

Рис. 1. Диаграмма вариантов использования «Банкомат»

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

3. Шаг третий

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

Придумать можно много (таймер, счетчик купюр, карточка и т.д.).

Далее оформляются CRC-карты. Это листки бумаги 10x15. Они разделены на 3 части и выглядят следующим образом:

Рис. 2. Оформление CRC-карты

Ниже приведен набор СРС-карт для примера с банкоматом:

  1. Шаг четвертый

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

  • диаграммы последовательности событий;

  • диаграммы кооперации.

4.1. Диаграмма последовательности событий

Диаграмма последовательности событий – графическая модель, которая для определенного сценария варианта использования показывает динамику взаимодействия объектов во времени.

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

  • идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 3). Правее изображается другой объект, который непосредственно взаимодействует с первым и т.д.;

  • из описания варианта использования определить множество системных событий и их последовательность;

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

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

4.1.1. Линия жизни объекта

Линия жизни объекта (object lifeline) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на рис. 3).

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. 3). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

4.1.2. Фокус управления

Объекты на диаграмме последовательности могут находиться в двух состояниях: активном – непосредственно выполняя какие-либо действия и пассивном – ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 3), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

4.1.3. Сообщения

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

Графически сообщения изображаются горизонтальными стрелками, соединяющими линии жизни или фокусы управления двух объектов на диаграмме последовательности (рис. 3).

Рис. 3. Графические примитивы диаграммы последовательности

Диаграмма последовательности событий для нашего примера (Система банкомата) приведена на рис. 4.

Рис. 4. Диаграмма последовательности событий

4.2. Диаграмма кооперации (сотрудничества)

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

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

Пример 2. Разработать диаграмму коопераций, иллюстрирующую взаимоотношения компании с составляющими ее отделами и сотрудниками.

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

Решение приведено на рис. 5.

Рис. 5. Пример диаграммы кооперации

Заметим, что на приведенной диаграмме объекты классов «Отдел» и «Сотрудник» реализованы мультиобъектами.

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

Порядок выполнения работы:

  1. В соответствии с вариантом задания, предложенным преподавателем, определить действующих лиц (акторов) системы.

  2. Определить варианты использования системы и описать их в краткой или полной форме.

  3. Построить диаграмму вариантов использования системы (использовать MS Office или MS Visio).

  4. Определить классы проектируемой системы.

  5. Создать CRC-карты для всех классов системы (использовать MS Office или MS Visio).

  6. Построить диаграммы взаимодействия (использовать MS Office или MS Visio).

  7. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

  1. Постановку задачи.

  2. Описание действующих лиц и прецедентов системы.

  3. Диаграмму прецедентов.

  4. CRC-карты.

  5. Диаграммы взаимодействия.

Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.

Контрольные вопросы:

  1. Проектирование ПО при объектном подходе.

  2. Моделирование предметной области при проектировании ПО.

  3. Язык UML. Его назначение, преимущества и недостатки.

  4. Варианты использования ПО.

  5. Диаграммы в языке UML.

  6. Диаграммы прецедентов.

  7. Диаграммы взаимодействия.

  8. Назначение и использование CRC-карт.

Варианты заданий:

  1. Заказ билетов в аэропорту.

  2. Электронный магазин.

  3. Отправка sms.

  4. Система охраны частного дома.

  5. Пропускная система.

  6. Система безопасности тюрьмы.

  7. Система безопасности полета самолета.

  8. Компьютерная система тестирования для оценки знаний студентов.

  9. Заказ билетов в театральной кассе.

  10. Телефонный коммутатор.

  11. Система учета успеваемости студентов деканатом.

  12. Записная книжка.

  13. Пропускная система биоконтроля.

  14. Автомат платежной системы.

  15. Электронная почта.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]