Файл: Разработка регламента выполнения процесса «Проведение оценки качества» (Предлагаемые мероприятия по улучшению технологии решения задачи).pdf
Добавлен: 19.06.2023
Просмотров: 29
Скачиваний: 3
Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.
Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:
- структурные модели, описывающие структуру системы, классы, компоненты, подсистемы и т.д.;
- модели поведения, отражающие функциональные возможности системы, логику выполнения процессов обработки данных, взаимодействие объектов в ходе выполнения процессов и т.д.
В дальнейшем язык UML стал применяться не только и не столько для создания информационных систем (ИС), сколько для анализа и перепроектирования бизнес-процессов. Вместо моделей процессов, реализуемых информационной системой, строятся модели бизнес-процессов, даже если они и не будут подвергнуты автоматизации, вместо объектов ИС (программных объектов) в моделях отражаются объекты бизнес-процессов (исполнители, продукция, услуги и т.д.), вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса (поставщики, партнеры, клиенты).
Моделирование бизнеса с помощью UML предполагает по-следовательное построение двух видов моделей:
прецедентной модели (аналога модели поведения), описывающей функциональность — бизнес-процессы (прецеденты), их взаимодействие с окружением;
объектной модели (аналога структурной модели), описывающей внутреннее устройство бизнеса - объекты, участвующие в выполнении бизнес-процессов, их взаимодействие.
Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:
– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);
– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;
- диаграммы поведения системы (behavior diagrams):
- диаграммы взаимодействия (interaction diagrams):
- диаграммы последовательности (sequence diagrams) и
- кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
- диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
- диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):
- диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
- диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.
Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.
Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.
На завершении проектирования программного обеспечения, представленного как набор модели, режим Обзор схемы позволяет пользователю видеть сразу представление полного решения перед завершением.
Для создания профессиональных моделей UML со следованием через возможность создания кодированного решения этот пакет трудно разбить, если Вы не готовы заплатить за коммерческий инструмент. Однако это не инструмент, нацеленный на новичка, просто схватившегося с UML, несмотря на то, что это - вероятно, самое удобное для пользователя введение для тех, кто должен понять, что полный вес UML базировал методы разработки. Неудачно, что этот инструмент в настоящее время неактивен с точки зрения разработки новых выпусков. Тем не менее, любой, кому нужно воздействие понятиям UML, особенно для помощи в понимании различия между схемой программного обеспечения, базовой моделью и различными взглядами той модели, тогда этот инструмент адаптации та цель.
Из прочих достоинств можно выделить:
- Генерация кода в языки: C#, Java, С++
-Поддержка работы с фреймворками
-Удобный графический редактор
-Полное соответствие стандарту UML 2.0
- Возможность расширения функционала (про это написано отдельное руководство разработчика)
-Экспорт документации в форматы: DOC, PPT, TXT, XLS…
- Поддержка паттернов
- Импорт проектов Rational Rose
- Приятный размер дистрибутива
2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию
Диаграмма вариантов использования системы
Разработка диаграммы вариантов использования преследует цели:
• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
• Сформулировать общие требования к функциональному поведению проектируемой системы.
• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
.
Рисунок 1 – Диаграмма вариантов использования для системы «Оценка качества»
Диаграмма деятельности системы
Диаграммы деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.
Диаграммы деятельности можно использовать для моделирования динамических аспектов поведения системы. Как правило, они применяются, чтобы промоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса. С помощью диаграмм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления. Диаграммы деятельности могут использоваться самостоятельно для визуализации, специфицирования, конструирования и документирования динамики совокупности объектов, но они пригодны также и для моделирования потока управления при выполнении некоторой операции. Если в диаграммах взаимодействий акцент делается на переходах потока управления от объекта к объекту, то диаграммы деятельности описывают переходы от одной деятельности к другой. Деятельность (Activity) - это некоторый относительно продолжительный этап выполнения в автомате. В конечном итоге деятельность сводится к некоторому действию (Action, см. главу 15), которое составлено из атомарных вычислений, приводящих к изменению состояния системы или возврату значения.
Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.
Рисунок 2 – Диаграмма деятельности системы
Диаграмма последовательности системы
Диаграмма же последовательностей отображает взаимодействие объектов в динамике. Что значит "в динамике"? Как раз с этим нам и предстоит разобраться.
В UML взаимодействие объектов понимается как обмен информацией между ними. При этом информация принимает вид сообщений. Кроме того, что сообщение несет какую-то информацию, оно некоторым образом также влияет на получателя. Как видим, в этом плане UML полностью соответствует основным принципам ООП, в соответствии с которыми информационное взаимодействие между объектами сводится к отправке и приему сообщений.
Диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательностей отображает временные особенности передачи и приема сообщений объектами.
Искушенный читатель, возможно, скажет, что нечто подобное делает и диаграмма прецедентов. Да, действительно, диаграммы последовательностей можно (и нужно!) использовать для уточнения диаграмм прецедентов, более детального описания логики сценариев использования. Это отличное средство документирования проекта с точки зрения сценариев использования! Диаграммы последовательностей обычно содержат объекты, которые взаимодействуют в рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты, связанные с сообщениями. Впрочем, часто возвращаемые результаты обозначают лишь в том случае, если это не очевидно из контекста.
Теперь о том, какие обозначения используются на диаграмме последовательностей. Как и ранее, объекты обозначаются прямоугольниками с подчеркнутыми именами (чтобы отличить их от классов), сообщения (вызовы методов) - линиями со стрелками, возвращаемые результаты - пунктирными линиями со стрелками. Прямоугольники на вертикальных линиях под каждым из объектов показывают "время жизни" (фокус) объектов. Впрочем, довольно часто их не изображают на диаграмме, все это зависит от индивидуального стиля проектирования.
.
Рисунок 3 – Диаграмма последовательности системы
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа «классификатор», которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.
В результате анализа предметной области были выявлены следующие классы (рис 4.):
Рисунок 4 – Классы системы
Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes) или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения: