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

План:

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

 

Скачать:

ВложениеРазмер
Файл plan_zanyatiya.docx986.34 КБ

Предварительный просмотр:

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

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

План:

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

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

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

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

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

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

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

C:\Users\golovina\Desktop\148654870613636841.png

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

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

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

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

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

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

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

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

https://intuit.ru/EDI/23_04_17_1/1492899714-28128/tutorial/356/objects/1/files/01_01.gif

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

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

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

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

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

НОУ ИНТУИТ | Лекция | Виды диаграмм UMLНОУ ИНТУИТ | Лекция | Диаграмма активностей: крупным планом

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

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

https://intuit.ru/EDI/23_04_17_1/1492899714-28128/tutorial/356/objects/2/files/02_03.gif

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

Объекты:

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

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

Актер

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

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

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

Рис_03_6

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

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

Рис_03_8

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

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

Рис_03_9

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

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

Рис_03_13

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

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

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

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

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

Прецеденты

Действующее лицо

  1. Подготовить банк вопросов

Экзаменатор

  1. Подготовка вопросов по Java

Экзаменатор

  1. Подготовка вопросов по С#

Экзаменатор

  1. Запустить экзамен

Экзаменатор

  1. Отменить экзамен

Экзаменатор

  1. Сдать экзамен

Студент

  1. Загрузить результат своей работы

Студент

  1. Просмотр результатов

Студент

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

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

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

C:\Users\golovina\Downloads\Практикум Мастер-класс.png

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

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

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

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

Вариант использования

Актер (действующее лицо)

Разместить меню

Секретарь

Ознакомиться с меню

Сотрудник, секретарь, офис-менеджер

Сделать заказ

Сотрудник, секретарь, офис-менеджер

Сформировать счет

офис-менеджер

Оплатить счет

офис-менеджер

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

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

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

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

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

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

Критерий

Баллы

Актеры определены верно  – 1 балл
(сотрудник, секретарь, офис-менеджер)

На диаграмме присутствуют все варианты использования – 1 балл 

(5 вариантов использования в соответствии с таблицей)

Связи (отношения) определены верно – 1 балл

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

На диаграмме определены варианты использования «Регистрация», «Авторизация» – 2 звездочки

На диаграмме отражена возможность просмотра разделов меню с помощью связи «обобщение» - 3 звездочки

3 балла – оценка «5»

2 балла – оценка «4»

1 балла – оценка «3»

C:\Users\golovina\Downloads\Итоговый результат.png

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

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

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

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


По теме: методические разработки, презентации и конспекты

План-конспект урока по произведению М.Булгакова с использованием ЭОР

В разработку данного урока включены электронные образовательные ресурсы...

Методические рекомендации для преподавателей "Варианты использования компьютерных и мультимедиа технологий на уроках литературы"

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

Конспект урока. Гимнастика с основами акробатики (вариант 1).

Конспект урокаю Гимнастика с основами акробатики (вариант 1)....

Конспект урока. Баскетбол (вариант 2).

Конспект урока. Баскетбол (вариант 2)....

Конспект урока по теме "Имя существительное" (с использованием технологии сотрудничества)

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

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

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

Конспект урока предметно-практического обучения по теме Аппликация "Ваза с цветами" (2 класс, вариант 1.2)

Данный конспект разработан к уроку предметно-практического обучения (вариант 1.2) во 2 классе по теме Аппликация "Ваза с цветами". Конспект урока подходит для учителей начальной школы для об...