2.2.Краткая справка о методологии моделирования UML
Язык UML ориентирован для применения в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач объектно-ориентированнного анализа и проектирования (ООАП). При этом термин "унифицированный" в названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.
В настоящее время разработаны средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.
Язык UML предназначен для решения следующих задач:
Поддержка легко воспринимаемого выразительного языка визуального моделирования, предназначенного для разработки и документирования моделей сложных систем самого различного целевого назначения.
Обеспечение возможностью расширения исходных понятий языка UML и специализации для более точного представления моделей систем в конкретной предметной области.
Описание языка UML, поддерживающее не зависящую от конкретных языков программирования и инструментальных средств проектирования программных систем, спецификацию моделей.
Описание языка UML, включающее в себя семантический базис для понимания общих особенностей ООАП.
Развитие рынка объектных инструментальных средств.
Распространение объектных технологий и соответствующих понятий ООАП.
Интеграция новейших достижения практики ООАП.
Из перечисленных выше диаграмм некоторые служат для обозначения двух и более других подвидов диаграмм. При этом в качестве самостоятельных представлений в языке UML используются следующие диаграммы:
В качестве самостоятельных представлений в языке UML используются следующие диаграммы:
диаграмма вариантов использования;
диаграмма классов;
диаграмма состояний;
диаграмма деятельности;
диаграмма последовательности;
диаграмма кооперации;
диаграмма компонентов;
диаграмма развертывания.
Рис. 1 Интегрированная модель сложной системы в нотации UML
2.3.Содержание пояснительной записки
Пояснительная записка оформляется на листах формата А4 в соответствии с требованиями ЕСКД и должна содержать:
Титульный лист.
Введение.
Глава 1. Анализ предметной области проектирования.
Глава 2. Выбор и обоснование средств и методов разработки.
Глава 3. Проектирование логической структуры программного средства.
Глава 4. Разработка физической структуры программного средства.
Глава 5. Разработка интерфейсных компонентов программного средства.
Глава 6. Формирование тестовых наборов данных.
Заключение.
Приложения.
Список литературы.
Титульный лист должен содержать название темы курсового проекта, указание фамилии и инициалов, номера группы и номера зачётки студента.
Между титульным листом и Введением следует подшивать задание на курсовое проектирование, полученное у преподавателя.
При нумерации параграфов каждой главы в номер следует включать номер главы. Например, для второго параграфа второй главы должен формироваться номер «2.2».
2.3.1.Введение
Во введении необходимо дать краткое описание предметной области, сформулировать цель проекта и показать актуальность решаемой в проекте задачи (не более 1 стр.).
2.3.2.Постановка задачи
В главе 1 необходимо описать стандарты, которые применяются для оформления программных документов и осуществить обоснованный выбор наиболее приемлемых из них для задачи, для решения которой разрабатывается программное средство. На этом этапе формируется описание существующего процесса, являющегося базой для последующих этапов.
Содержание главы:
Входные, выходные и внутренние данные процесса, включающие документы, сведения, информационные и управляющие воздействия, которые поступают в процесс, формируются в процессе или передаются из процесса в другие процессы. Следует отметить, что перечень документов данного параграфа должен соответствовать документам, передаваемым в мнемосхеме, выводам по главе 1, схеме модулей и алгоритма.
Пример 1:
Рис. 2 Пример таблицы входных, выходных и внутренних данных процесса
Нормативные документы, устанавливающие требования к процессу.
Пример 2:
Налоговый кодекс РФ, кодекс РФ об административных правонарушениях, закон РФ «О защите прав потребителя», трудовой кодекс РФ, закон «О товарных знаках»;
Участников процесса, структуру их подчинённости и описание основных функций, представляющие собой схему подчинённости и перечень функций участников.
Пример 3:
Рис. 3 Пример структуры участников процесса
Пример 4:
Начальник отдела снабжения выполняет следующие функции:
принятие решения о выборе поставщика;
администрирование работ отдела;
согласование договоров;
решение сложных вопросов с поставщиками.
Инженер отдела снабжения выполняет следующие функции:
обсуждение с поставщиками условий поставки;
организация согласования договоров на закупку;
контроль по целостности упаковок материалов при внешнем осмотре;
контроль за хранением материалов на складе.
Формирование пирамиды требований, содержащей уровень потребностей и уровень функциональных особенностей проектируемой системы.
На данном этапе формируется, как минимум, 3 потребности заказчика, для реализации которых предназначена разрабатываемая система. Для каждой потребности формируется 2 – 4 функциональные особенности. Всего их должно быть не менее 9.
Пример
В качестве первой потребности заказчик выдвинул…
Последняя потребность связана с необходимостью формирования печатного отчёта о затратах проекта. Функциональные особенности показаны в таблице:
Потребность
|
Функциональные особенности
|
…
|
…
|
Наличие отчёта о затратах
|
14) Работа с принтером
|
15) Загрузка данных из таблиц в текстовый редактор по заранее определённому алгоритму в определённые разделы
|
16) Формирование на экране диалога по настройке отчёта перед печатью
|
…
|
Вербальное и графическое описание функционального назначения системы, включающее графическую схему (диаграмму вариантов использования) и текстовых комментариев, поясняющих на схеме как выполняется процесс. Следует учесть в диаграмме в виде актёров всех участников, перечисленных в структуре участников процесса.
Пример 5:
Рис. 4 Пример диаграммы вариантов использования для примера
системы продажи товаров по каталогу
Покупатель обращается к продавцу и совместно с ним оформляет заказ на покупку товара. При этом продавец обеспечивает покупателя информацией, согласовывает условия оплаты, заказывает товар со склада. Заказ на покупку товаров осуществляется после выбора покупателем товара из каталога товаров, запрошенного продавцом.
Рекомендации по выполнению диаграммы вариантов использования:
вариантов использования должно быть несколько (не менее 5);
следите за логикой процесса: графическое отображение должно быть исчерпывающим, понятным и соответствующим текстовому описанию;
диаграмма должна быть связана с пирамидой требований, сформированной на предыдущем уровне: функциональные особенности должны быть раскрыты вариантами использования диаграммы вариантов;
диаграмма вариантов использования должна содержать актёров, варианты использования, интерфейсы, примечания и отношения.
Формирование диаграммы кооперации.
Диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи — потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений.
Пример 6:
Рис. 5 Пример диаграммы кооперации для моделирования телефонного разговора
Следует отметить, что основная задача диаграммы кооперации – показать роли и функции участников.
В рамках поставленной задачи необходимо построить не менее 5 диаграмм кооперации для различных вариантов использования.
Выводы о недостатках в рамках выполняемой задачи и предложения по разработке программных средств для их преодоления.
Пример 7:
Анализ процесса показал, что важнейшими недостатками являются:
недостаточная эффективность использующейся технологии учёта информации при помощи бумажного журнала;
…
Для устранения недостатков предлагается разработать программное средство, реализующее следующие функции:
хранение сведений о ежедневных отгрузках с товарного склада;
…
При этом необходимо создать следующие объекты, обладающие поведением:
формы ввода (функция ввода информации):
ввод отгруженной продукции;
…
отчётные формы (функция вывода информации на принтер):
справка об отгрузке поставщику;
…
вычислительные модули (функция расчёта параметров):
процедура расчёта остатков на складе:
…
прочие объекты (…):
…
Примечание:
Форм ввода и отчётных форм должно быть не менее, чем по 3. Необходим хотя бы один вычислительный модуль.
Форма авторизация не является формой ввода информации документа, но должна присутствовать в проектируемом программном средстве.
2.3.3.Выбор и обоснование средств и методов разработки
В главе 2 необходимо обосновать выбор метода разработки, языка программирования и СУБД, используемой для хранения промежуточных результатов.
Содержание главы:
Выбор метода разработки
В данном разделе студент должен указать обоснование и причины использования UML в данном проекте.
Выбор и обоснование языка программирования
На этом этапе экспертными или расчётными методами выбирается язык или среда программирования.
Пример 8:
Для выбора языка программирования методом морфологического анализа произведён выбор из следующих альтернатив:
Язык программирования
|
Вес
критерия
|
Язык 1
|
Язык 2
|
Язык 3
|
Дороговизна лицензии
|
3
|
3
|
2
|
1
|
Сложность освоения
|
2
|
2
|
…
|
…
|
Оптимальность кода
|
1
|
2
|
|
|
…
|
|
|
|
|
Суммарный
приоритет
|
-
|
15
|
|
|
Суммарный приоритет рассчитывается методом построчного суммирования произведений значений ячеек и соответствующих весов.
Описание языка программирования или среды разработки, включающее наименование языка (среды), основные особенности и причины выбора.
Пример 9:
Для автоматизации процесса снабжения использован язык программирования Visual Basic for Application, входящий в состав СУБД Microsoft Access, представляющий собой алгоритмический язык программирования …
Пример 10:
Для выбора СУБД произведён выбор из следующих альтернатив:
Вид СУБД
|
Вес
критерия
|
СУБД 1
|
СУБД 2
|
СУБД 3
|
Сложность освоения
|
1
|
…
|
…
|
…
|
Аппаратные требования
|
3
|
|
|
|
Скорость работы
|
3
|
|
|
|
…
|
|
|
|
|
Суммарный
приоритет
|
…
|
|
|
|
Описание СУБД, содержащее наименование СУБД и причины её выбора.
На этом этапе экспертными или расчётными методами выбирается СУБД, либо доказывается отсутствие необходимости в её использовании.
Пример 11:
Для автоматизации процесса снабжения выбрана СУБД Microsoft Access 2003, которая позволяет создать персональную базу данных и формы для работы с ней. Выбор СУБД обусловлен …
2.3.4.Проектирование логической структуры программного средства
В главе 3 на основе диаграммы использования и диаграммы кооперации определяется логическая структура программного средства, заданного темой проекта.
Содержание главы:
Разработка диаграммы классов, описывающей логическую модель системы.
Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений.
В рамках проекта следует разработать логическую структуру информации в виде диаграммы классов. Хранимая в базе данных информация обычно также представляется в виде диаграммы классов.
Пример 12:
Рис. 6 Пример диаграммы классов кадрового учёта
Список вводимых реквизитов и ограничений, представляющих собой таблицы, в которых содержится информация о наименовании, типе и ограничениях на значения полей сущностей, упомянутых в диаграмме классов. В таблицах должны быть выделены ключевые реквизиты.
Пример 13:
Название реквизита
|
Обозначение
|
Тип
|
Размерность
|
Табельный номер (PK)
|
ID
|
Счётчик
|
8 симв.
|
ФИО составителя
|
A_Name
|
Текст
|
50 симв.
|
Материал
|
Matirial
|
Текст
|
50 симв.
|
Срок хранения
|
CondData
|
Дата
|
8 симв.
|
…
|
|
|
|
Рис. 7 Пример фрагмента таблицы реквизитов входящего документа «ведомость материалов»
Разработка диаграммы состояний
Главное предназначение этой диаграммы — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.
Рис. 8 Простейший пример диаграммы состояний
При проектировании следует выявить все возможные состояния и варианты их возникновения, а также построить диаграмму состояний для жизненного цикла одного из разрабатываемых объектов.
Пример 14:
Рис. 9 Пример диаграммы состояний жизненного цикла объекта «телефона»
Следует учитывать, что в некоторых вариантах логично использовать диаграмму состояний с переходами, построенную на основе сетей Петри как, например, показано на рисунке:
Рис. 10 Пример диаграммы состояний подготовки строительного участка
При разработке диаграммы состояний нужно постоянно следить, чтобы объект в каждый момент мог находиться только в единственном состоянии.
Диаграмма строится для отдельного класса, варианта использования, отдельной операции класса или целой подсистемы. В рамках данного проекта необходимо построить диаграмму состояний для всех выбранных объектов, для которых будет описано поведение. Для получения удовлетворительной оценки их должно быть не менее 5.
Разработка алгоритма работы программного средства, представляющего собой последовательность выполняемых программой команд. Алгоритм оформляется по ГОСТ 19.701-90. Следует использовать схему работы программы.
Пример 15:
Рис. 11 Пример фрагмента алгоритма
Алгоритм должен быть явно увязан с диаграммой использования, диаграммой классов и диаграммой состояний.
В алгоритме должно быть отражено: как, на каком этапе заполняются формы ввода и формируются документы для печати, осуществляются необходимые расчёты, используется база данных или файловые хранилища для сохранения данных и загрузки их в печатные отчёты.
Допускается строить общий алгоритм для всех выбранных для автоматизации функций.
Формирование диаграммы деятельности
Графическая нотация диаграммы деятельности во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами — переходы от одного состояния действия к другому.
Рис. 12 Пример фрагмента диаграммы деятельности для алгоритма нахождения корней квадратного уравнения
Достоинством диаграммы деятельности является возможность развёртывания её в виде дорожек, т.е. с привязкой к исполнителям конкретных операций алгоритма.
Пример 16:
Рис. 13 Пример фрагмента диаграммы деятельности для торговой компании с дорожками
Строится для отдельного класса, варианта использования, отдельной операции класса или целой подсистемы. В рамках данного проекта необходимо построить диаграмму деятельности для всех выбранных функций, которые следует автоматизировать.
Разработка диаграммы последовательности
На диаграмме последовательности изображаются объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является динамика взаимодействия объектов во времени.
Диаграмма последовательности имеет два измерения:
Одно – слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни.
Второе измерение – вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы.
Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».
Пример 17:
Рис. 14 Пример диаграммы последовательности для моделирования телефонного разговора
В рамках данного проекта диаграмма последовательности строится для вычислительного модуля задачи, показывая на каких этапах и какие объекты выполняют необходимые в проекте действия.
2.3.5.Проектирование физической структуры программного средства
В главе 4 на основе логической определяется физическая структура программного средства, заданного темой проекта.
Содержание главы:
Разработка диаграммы компонентов
Диаграмма компонентов описывает особенности физического представления системы и позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
визуализации общей структуры исходного кода программной системы;
спецификации исполнимого варианта программной системы;
обеспечения многократного использования отдельных фрагментов программного кода;
представления концептуальной и физической схем баз данных.
Компонент – основной элемент диаграммы компонентов, реализующий набор интерфейсов и служащий для общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный символ — прямоугольник со вставленными слева двумя более мелкими прямоугольниками.
Рис. 15 Графическое изображение компонента в языке UML
Зависимости могут отражать связи модулей программы на этапе компиляции и генерации объектного кода. В другом случае зависимость может отражать наличие в независимом компоненте описаний классов, которые используются в зависимом компоненте для создания соответствующих объектов. Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой. Отношения реализации показывают сплошными стрелками, а зависимости – пунктирными.
Пример 18:
Рис. 16 Пример изображения отношения зависимости между компонентами в диаграмме компонентов
В данном проекте следует построить диаграмму компонентов разрабатываемого программного средства и описать каждый её элемент.
Разработка диаграммы развертывания
Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Диаграмма развертывания применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений — маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения.
Пример 19:
Рис. 17 Пример диаграммы развертывания для системы удаленного обслуживания клиентов банка
В данном разделе проекта следует определить комплекс технических средств, которые необходимы для работы системы, описать их и обобщить в виде диаграммы развёртывания.
2.3.6.Визуальный интерфейс программного средства
В главе 5 описываются элементы визуального интерфейса программного средства с указанием перечня всех полей для ввода данных с ограничениями на эти данные, а также перечень документов, формируемых подсистемой с полным перечнем всех их реквизитов.
Содержание главы:
Проекты экранных форм, которые могут быть как готовыми экранными формами работающей программы, так и проектами (шаблонами) документов, представляющих собой графические схемы, демонстрирующие порядок отображения на экране различных реквизитов проектируемых документов.
Пример 20:
 
Рис. 18 Пример экранной формы и шаблона документа
2.3.7.Тестовые наборы
В главе 6 должны анализироваться методы оценки работоспособности и функциональной пригодности разрабатываемого программного средства и формироваться для него тестовые наборы. Тестовые наборы должны быть связаны с пирамидой требований и выступать в роли тестовых сценариев по правилу: входные данные – условия на них – результат, выдаваемый программным средством.
Один из участников проекта должен разработать программу-методику испытаний программного средства.
2.3.8.Заключение
В заключении должны быть подведены итоги проделанной работы. В качестве итогов указывается объём проделанной работы, решённая задача и практическая польза, которую принесло её решение.
Пример 21:
В рамках выполненной курсовой работы на тему «Закупка материалов для машиностроительной компании»:
проведён анализ предметной области, сформированы мнемосхема, функциональные и информационная модели процесса;
разработана схема взаимодействия модулей, алгоритм работы и проект выходных экранных форм программы, реализующих автоматизацию процесса закупки материалов;
разработаны тестовые наборы для оценки корректности программы.
В ходе исследования выяснилось, что на данный момент задача определения дефицита решалась без использования компьютера по журналу учёта материалов на складе, что приводило к большим затратам времени и высокой вероятности ошибки. Для решения этой проблемы был использован язык программирования VBA и СУБД Microsoft Access, с помощью которых была разработана локальная программа, позволяющая хранить данные о материалах на складе, оценивать по вводимым данным их достаточность для производства в предстоящем году и формировать заявку на закупку недостающих материалов у поставщиков.
Ожидаемый эффект по экспертной оценке должен состоять в сокращении на xxx% времени определения дефицита и на xxx% вероятности возникновения ошибок.
2.3.9.Приложения
В приложении должны быть приложены следующие документы, разрабатываемые участниками группы проекта:
техническое задание, сформированное по ГОСТ 19.201-78;
программа-методика испытаний, сформированная по ГОСТ 19.301-79;
руководство оператора ГОСТ 19.505-79.
2.3.10.Список литературы
Список использованной литературы должен содержать ссылки на основные источники, использованные при выполнении курсового проекта (8-10 источников, издания – не старше 5 лет от текущего года). В тексте проекта должны быть ссылки на использованные источники. Например, в следующей форме – [7], где 7 – номер источника в списке литературы.
|
