Моделирование программного обеспечения в методологии uml модуль Математические модели проектирования программного обеспечения Лекция Объектноориентированное моделирование программного обеспечения Задание
 Скачать 1.28 Mb.
|
Практическое задание 3Моделирование программного обеспечения в методологии UML Модуль 1. Математические модели проектирования программного обеспечения Лекция 1.3. Объектно-ориентированное моделирование программного обеспечения Задание Для предметной области практического задания 2: 1. Провести описание своей предметной области в ключе объектно-ориентированного подхода. 2. Выполнить построение диаграммы прецедентов в StarUML. 3. Выполнить документирование элементов модели в StarUML. 4. Добавить описание потока событий одного прецедента. Рекомендации по выполнению задания В работе используется свободное средство моделирования StarUML. Ссылка для скачивания последней официальной версии с официальным неограниченным пробным периодом http://staruml.io Руководство пользователя StarUML – https://docs.staruml.io/ Руководство пользователя на русском языке: StarUNL : The Open Source UML/MDA Platform : version 5.0.2.1570 : руководство пользователя / пер. Д. В. Летуновского. – [Б. м. : б. и.], 2007. – 207 с. – URL: staruml.sourceforge.net/docs/user-guide(ru)/user-guide.pdf (дата обращения: 06.06.2022). Образец выполнения задания 3Цель работы: получить практические навыки анализа бизнес-процессов в методологии UML. Описание предметной области Для описания был выбран процесс закупок строительной компании. Оформлением заявки занимается прораб. Он проверяет наличие материалов на объекте и в случае отсутствия каких-либо из списка он отправляет заявку в отдел по закупкам. Менеджер по закупкам производит обработку заявки и затем отправляет заказы поставщикам. Поставщик получает заявку от менеджера и после проведения внутренних процессов отправляет материалы на объект, где их принимает прораб (рис. 3.1).  Рис. 3.1. Диаграмма вариантов использования На диаграмме прецедентов выделены три действующих лица: прораб, менеджер по закупкам и поставщик. В потоке закупки у прораба существует несколько прецедентов. В первую очередь ему необходимо обработать информацию о расходе материалов на объекте. В случае необходимости он реализует прецедент подготовки списка материалов на закупку. Данный прецедент является обязательным для прецедента оформления заявки, который включает подготовку списка. Еще одним прецедентом является получение информации о заявке. Заключающим прецедентом является принятие материалов от поставщика. У менеджера по закупкам есть пять прецедентов. Первый – получение заявки от прораба. Второй прецедент – обработка одной из принятых заявок. На основании поступивших заявок менеджер оформляет заявку поставщику, а также при этом изменяет информацию о статусе заявки. Менеджер получает информацию от поставщиков, после чего вносит изменения в информацию о заявке. Поставщик не является объектом предприятия, поэтому были описаны только прецеденты, при которых он непосредственно контактирует с остальными объектами предприятия. Поставщик принимает заявку, уведомляет менеджера об изменениях в процессе работы над заказом и отвечает непосредственно за доставку материалов на объект. Примеры документирования всех элементов диаграммы представлены на рис. 3.2 и 3.3.  Рис. 3.1. Документирование элемента диаграммы «Получить отчет о расходе материалов»  Рис. 2.3. Документирование элемента диаграммы «Изменить информацию о поставщиках» Поток событий Поток событий для прецедента «Оформить заявку» Основной поток событий Прецедент начинается с аутентификации в системе управления закупками. E1. У пользователя нет прав на просмотр. Система открывает страницу просмотра заявок. A1. Пользователь находит существующую заявку на необходимые материалы. Пользователь открывает форму создания заявки. Пользователь заполняет поля формы и нажимает «Отправить». Система производит валидацию введенных данных. E2. В данных есть ошибка. Данные отправляются на сервер. Для пользователя отображается сообщение об успешном создании заявки. Заявка появляется в списке заявок. Вариант использования завершается. Альтернативные потоки A1. Пользователь находит существующую заявку на необходимые материалы. Пользователь переходит на страницу заявки. Пользователь проверяет данные. A2. Пользователь замечает некорректное количество материала. Вариант использования завершается. A2. Пользователь замечает некорректное количество материала. Пользователь переходит на страницу редактирования заявки. Пользователь вводит обновленные данные. Поток возвращается на 4-й этап основного потока. Потоки ошибок E1. У пользователя нет прав на просмотр. Система выводит сообщение о недостаточности прав доступа. Вариант использования завершается. E2. В данных есть ошибка. Отправка заявки прерывается. Система выводит сообщение об ошибке в введенных данных. Поток возвращается на 4-й этап основного потока. Вывод: в данной работе были получены практические навыки анализа бизнес-процессов в методологии UML. Была разработана диаграмма прецедентов с использованием программы StarUML, произведена документация элементов диаграммы, а также было произведено документирование потока событий. Практическое задание 4Детализация объектно-ориентированных моделей программного обеспечения Модуль 1. Математические модели проектирования программного обеспечения Лекция 1.3. Объектно-ориентированное моделирование программного обеспечения Задание Для предметной области практического задания 2: 1. Выполнить построение диаграммы деятельности одного прецедента практического задания 3. 2. Построить диаграмму классов с атрибутами, операциями и отношениями своей предметной области. 3. Выполнить документирование классов. 4. Сгруппировать классы в 2–3 пакета, построить диаграмму пакетов. 5. Построить диаграмму состояний одного объекта модели. Рекомендации по выполнению задания В работе используется свободное средство моделирования StarUML. Ссылка для скачивания последней официальной версии с официальным неограниченным пробным периодом http://staruml.io Руководство пользователя StarUML – https://docs.staruml.io/ Руководство пользователя на русском языке: StarUNL : The Open Source UML/MDA Platform : version 5.0.2.1570 : руководство пользователя / пер. Д. В. Летуновского. – [Б. м. : б. и.], 2007. – 207 с. – URL: staruml.sourceforge.net/docs/user-guide(ru)/user-guide.pdf (дата обращения: 06.06.2022). Образец выполнения задания 4Цель работы: получить практические навыки детализации моделей UML. В данной работе рассмотрен процесс обучения в учебном центре. К процессу обучения подключаются кураторы, преподаватели и студенты. Во время учебы преподаватели проводят лекции и готовят вопросы к тесту по занятию. Кураторы дают задания, проводят семинары, следят за успехами студентов, ставят им оценки. Студенты посещают лекции, выполняют задания, проходят тесты и смотрят их результаты. В проектируемой системе можно создавать конференции на проведение лекций и семинаров, а также тестов. С помощью неё можно следить за посещаемостью и успеваемостью по тестам. В приложении А изображена диаграмма деятельности. Куратор создает семинар в ИС, система создает конференцию и рассылает приглашения. Студент видит и принимает приглашение, после этого куратор проводит семинар. В ИС создается тест по этой теме, рассылаются уведомления студентам. Когда студенты проходят тест, система формирует отчет для куратора и показывает результат прохождения теста. ИС отправляет отчет куратору, который впоследствии может его посмотреть. В приложении Б представлена диаграмма классов. Класс Human содержит поля и методы, которые необходимы при работе как с сотрудниками, так и со студентами. Класс содержит персональную информацию (имя, телефон, почту), а также методы для создания, просмотра и изменения объекта. Класс Student – студент учебного центра – наследует свойства и методы Human, добавляется дата приема и принадлежность к учебной группе. Класс Employee – сотрудники компании – наследует свойства и методы Human, добавляется дата начала работы, департамент, менеджер и зарплата. Tutor – куратор учебного центра. Класс наследует свойства и методы Employee, добавляется принадлежность к группе, которую он курирует. Тeacher – преподаватель учебного центра. Класс наследует свойства и методы Employee, добавляется принадлежность к группам и курсам, за которые он отвечает. Group – учебная группа студентов. Класс связан с классом Student композицией «один ко многим». Содержит ID студентов, куратора, преподавателей и курсов, методы по управлению этими данными. Course – учебный курс. Связан с классами Group и Teacher ассоциацией и агрегацией. Несколько групп проходят несколько курсов. Один преподаватель назначен на несколько курсов. Содержит поля «Имя», «Время на выполнение», «Доступ», ID и методы для управления этими данными. Test – тест в рамках учебного курса. Связан с классом Course агрегацией «многие к одному». Содержит название, время выполнения, список вопросов, результат и методы для управления этими данными. Question – вопросы для тестов. Связан с классом Test агрегацией «многие к одному». Содержит название, ответ, ID теста и методы для управления этими данными. Answer – ответы к вопросам теста. Связан с классом Question агрегацией «многие к одному». Содержит название, ID вопроса и методы для управления этими данными. Marks – оценки за тесты. Связан с классом Test ассоциацией «одна оценка за один тест». Содержит название, ID теста и методы для управления этими данными. Report – отчеты для сотрудников. Связан с классом Marks композицией «один ко многим». Связан также с классом Employee ассоциацией. Содержит ID студентов, список их оценок, методы по управлению этими данными. Controller – контроллер для реализации модели MVC (Model-View-Controller), выполняется на стороне сервера. Menu – запускает контроллер с пользовательского интерфейса. В приложении В изображена диаграмма пакетов. В модели MVC сначала мы получаем данные с отображения (пользовательского интерфейса), передаем их контроллеру. Далее есть модели студентов и сотрудников, которые взаимодействуют с курсами, тестами, отчетами. В приложении Г изображена диаграмма состояний объекта «Тест». Сначала создается тест и привязывается к учебному курсу. Далее тест заполняется вопросами и проверяется. Если он неправильный, то считается недоработанным. Как только его заполнят корректно, он станет одобренным. Тест добавят к элементам курса, и он будет готовым к прохождению студентами. Как только его выполнит студент, он станет пройденным. Вывод: в результате выполнения данной работы получены практические навыки детализации бизнес-процессов в методологии UML. Приложение АДиаграмма деятельности  Приложение БДиаграмма классов  Приложение ВДиаграмма пакетов  Приложение ГДиаграмма состояний объекта «Тест»  |