Конспект урока МДК 02.01 Диаграмма вариантов использования
план-конспект урока

Здравствуйте ребята, меня зовут Екатерина Алексеевна. Сегодня я проведу вам мастер класс на тему проектирование предметной области.

Целью нашего сегодняшнего занятия является практическое построение диаграммы вариантов использования.

План:

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

1. Жизненный цикл информационных систем.
2. UML. Историческая справка. Понятие.
3. Диаграмма вариантов использования.
4. Практическое построение диаграммы вариантов использования.
5. Задание для самостоятельного выполнения.

План 1. Жизненный цикл информационных систем.

Смотрите к примеру, с какого момента начинается жизнь человека? С момента его рождения. А как вы думаете, с чего начинается жизненный цикл информационной системы? С Идеи? Да действительно, когда в голове, какого-нибудь юного или не очень программиста рождается идея о создании программного продукта, тогда можно сказать что его жизненный цикл начался.

И далее как человеку, который проходит различные этапы в своей жизни и программный продукт тоже в свою очередь проходит эти этапы. Как думаете какие? И в каком порядке? (Идея. Математическая модель. Проектирование. Разработка кода. Тестирование. Внедрение.)

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

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

Именно с помощью проектирования можно добиться понимания и реальной детальной реализации программного средства. А для того, чтобы и заказчик, и команда разработчиков могли разговаривать на одном языке и был разработан язык UML. (потому что как известно программисты разговаривают на своем специфическом языке, который обычные люди не совсем понимают, едва ли вы, спросив свою маму или бабушку «В чем отличие «фичи» от «бага»?» получите исчерпывающий ответ. В лучшем случае на вас посмотрят с удивлением, в худшем попытаются изгонять из вас демонов)  

План 2. UML. Историческая справка. Понятие.

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

UML - унифицированный язык моделирования. Из этих трех слов главным является слово " язык ". Что же такое язык? Язык - система знаков, служащая средством передачи информации. Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику).

Второе слово в фразе, которой расшифровывается аббревиатура UML - слово " моделирование ". Да, UML - это язык моделирования, то есть средство построения описательных моделей.

Третье слово в названии UML - слово " унифицированный ". UML как раз и стал таким единым универсальным стандартом для объектно-ориентированного моделирования.

Откуда взялся UML? Если говорить коротко, то UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других.

В 80-е годы было множество различных методологий моделирования. Каждая из них имела свои достоинства и недостатки, а также свою нотацию. То смутное время получило название "войны методов". Проблема в том, что разные люди использовали разные нотации, и для того чтобы понять, что описывает та или иная диаграмма, зачастую требовался "переводчик". Один и тот же символ мог означать в разных нотациях абсолютно разные вещи! На рисунке ниже можно увидеть лишь малую часть многообразия методов, которые существовали в то время и в какой-то мере повлияли на UML.

К 1994-му существовало 72 метода. Как уже говорилось выше, чувствовалась острая потребность, объединить в одном унифицированном средстве все лучшее, что было создано в области моделирования. Это как сейчас, мы задаемся вопросом «Почему же нельзя придумать единую зарядку для телефонов» так и появился UML.

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

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

Какой напрашивается вывод, зачем вообще строить какие-то диаграммы? Разработка модели любой системы (не только программной) всегда предшествует ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри команды разработчиков, и для взаимопонимания с заказчиком. Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства.

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

План 3. Диаграмма вариантов использования.

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

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

Объекты:

Вариант использования (use case)

• Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?»
• Имена – отглагольное существительное или глагол в неопределенной форме

Актер

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

Отношение ассоциации

• Служит только для обозначения взаимодействия актера с вариантом использования.

Отношение включения

• Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента
• Отношение включения (include) специфицирует тот факт, что некоторый вариант использования содержит поведение, определенное в другом варианте использования

Отношение расширения

• Отношение расширения (extend) определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.

Отношение обобщения

• Отношение обобщения (generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели

План 4. Практическое построение диаграммы вариантов использования.

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

Задание: Создать Use Case диаграмму для системы онлайн-экзаменов. Описание системы:

• Экзаменатор перед запуском экзамена должен сперва подготовить банк вопросов (в частности, вопросы по Java и вопросы по C#)
• Когда экзаменационные вопросы готовы, он может запустить экзамен, а также впоследствии отменить его в любой момент
• Студент может сдать экзамен. Сдача экзамена включает в себя загрузку выполненной работы в систему
• Студент может в любое время посмотреть результаты своих прошедших экзаменов

Полученная таблица:

Теперь приступим к непосредственному построению за ПК. Не забывайте о безопасном расстоянии для глаз при работе за монитором и положении тела.

• У вас  на сервере 15.04…. есть папка 01_UML_Мастер-класс, в документе Ссылки для доступа есть ссылка на веб сервис в котором мы будем строить нашу диаграмму.
• Войдите в систему по логинам и паролям, которые я вам раздала. 
• В процессе мы с помощью данного веб сервиса Createlly это быстро и просто создадим UML диаграммы онлайн, у данного сервиса широкие профессиональные возможности, в будущем вам как разработчикам, этот опыт будет полезен, так как здесь есть возможность для работы в команде. Построение диаграммы на веб-сервисе createlly.

Ребята, как вы считаете все ли правильно? Проверяем совместный полученный результат на наличие ошибок.

План 5. Задание для самостоятельного выполнения.

Теперь давайте представим, что вы профессионалы, и вам поступило кейс-задание, которое у вас есть на раздаточном материале и вам необходимо самостоятельно построить модель по предметной области от заказчика.

Предметная область:

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

Задание со звездочкой:

1. Перед ознакомлением с меню сотрудникам необходимо авторизоваться. Предусмотрите и реализуйте на вашей диаграмме регистрацию и авторизацию сотрудников на сервере.
2. Меню включает в себя разделы с напитками, первыми блюдами, вторыми блюдами. Отразите это на реализованной диаграмме.

Перед вами представлена таблица с актерами и действиями,  спроектируйте диаграмму вариантов использования. На выполнение этого задания вам 5 минут.

И наверняка вы слышали о чемпионате молодые профессионалы WSR, где ребята демонстрируют свои знания и навыки во всех отраслях в том числе и в программировании.  А теперь давайте представим себя в роли эксперта WSR, который участвует в оценке. Для этого по часовой стрелке пересядьте на место соседа. Тот кто на крайнем месте пересаживается на первое.

Перед вами критерии оценки, по которым вы должны проверить результат работы ваших одногруппников.

Критерии оценки:

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

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

Проголосуйте, как вы считаете «Пригодятся ли полученные знания на сегодняшнем уроке в профессиональной деятельности» Используем бинарную систему где 1-это да, а 0-нет.

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