Методические указания к лабораторным работам

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ
ФГБОУ ВПО «СЕВЕРО-КАВКАЗСКИЙ ГОРНО-МЕТАЛЛУРГИЧЕСКИЙ ИНСТИТУТ»
(ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ)
Кафедра автоматизированной обработки информации
Методические указания к
лабораторным работам
дисциплины:
«ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ»
для направления подготовки:
230100 Информатика и вычислительная техника
Квалификация (степень) выпускника : магистр
Составители:
к.т.н. Соколова Е.А.
асс. Гречаный С.В
Владикавказ, 2013 г.
Содержание
Введение ......................................................................................................................................... 4
Лабораторная работа 1.Объектно- ориентированный анализ предметной области и
прототипа оболочки ДЭС на языке среды Visual C++ 6.0 ......................................................... 5
Лабораторная работа 2.Разработка технического задания на
проектирование прототипа оболочки ДЭС .............................................................................. 17
Лабораторная работа 3.Разработка диаграммы вариантов
использования для прототипа оболочки ДЭС .......................................................................... 31
Лабораторная работа 4. Разработка диаграммы классов
для прототипа оболочки ДЭС ................................................................................................... 37
Лабораторная работа 5. Разработка диаграммы состояния
для прототипа оболочки ДЭС ................................................................................................... 41
Лабораторная работа 6. Разработка диаграммы деятельности
для прототипа оболочки ДЭС ................................................................................................... 44
Лабораторная работа 7. Разработка диаграммы
последовательности для прототипа оболочки ДЭС ................................................................ 49
Лабораторная работа 8. Разработка диаграммы кооперации
для прототипа оболочки ДЭС ................................................................................................... 54
Лабораторная работа 9. Разработка диаграммы компонентов
для прототипа оболочки ДЭС ................................................................................................... 61
Лабораторная работа 10. Разработка диаграммы развертывания
для прототипа оболочки ДЭС ................................................................................................... 67
Введение
Современный рынок программного обеспечения диктует жесткие
требования на разрабатываемые информационные системы. Системы
должны быть надежными, высокопроизводительными, обладать гибкостью
к любого рода изменениям в предъявляемых ей требованиям, обеспечивать
возможность масштабирования и наращивания функциональности. Кроме
того, разработка должна вестись быстро, качественно и с минимальными
затратами.
В связи с этим одной из важнейших задач разработки становится
качественное
проведение
этапов
анализа
и
проектирования,
обеспечивающих создание модели функционирования программной
системы, которая может заложить твердый фундамент для дальнейшей ее
программной реализации с целью выполнения вышеперечисленных
требований. Разработка модели сложной программной системы перед
непосредственной ее реализацией является такой же неотъемлемой частью
всего проекта, какой чертеж является основой для постройки большого
здания. Хорошая модель является основой для беспрепятственного
взаимодействия в команде разработчиков и гарантирует общий успех
начатого проекта. Построение модели необходимо, потому что
невозможно охватить с первого взгляда как всю систему в целом, так и
отдельные ее функциональные части. По мере роста разрабатываемых
систем все больше проявляется необходимость в наличии хорошего
средства моделирования. Существует большое число факторов, влияющих
на общий успех разработки, но присутствие строгого стандарта на язык
моделирования является первостепенным фактором и основой для
создания CASE-средств таких, как Visio 2000 ,базирующихся на
промышленном объектно-ориентированном стандарте моделирования –
Унифицированном Языке Моделирования UML (Unified Modeling
Language)..
В учебном пособии дано описание лабораторных работ по объектно-ориентированному
анализу
и
проектированию
сложных
программных систем с использованием унифицированного языка
моделирования UML.На примере оболочки диагностической экспертной
системы рассмотрены все этапы разработки – от определения требований к
создаваемой системе до построения диаграмм ее компонент и физического
размещения на аппаратных средствах пользователя. Для успешного
выполнения лабораторных работ студентам предлагается действующий
прототип оболочки, реализованный в объектно-ориентированной среде
4
Visual C++ 6.0,и обучающая система по этой оболочке, написанная на
JavaScript.
Лабораторная работа № 1
Изучение возможностей среды моделирования Visio 2000
Цель работы – анализ современных методологий программирования
и изучение возможностей визуальной объектно–ориентированной среды
моделирования Visio 2000.
Общие сведения
Методология процедурно-ориентированного
программирования
Основой данной методологии разработки программного обеспечения
является процедурная или алгоритмическая организация структуры
программного кода. Это было естественно для вычислительных задач,
которые превуалировали на ранних этапах вычислительной техники.
Исходным понятием этой методологии является понятие “алгоритма”, а
языки программирования называли алгоритмическими.
Первое графическое средство документирования программ получило
название “блок-схема алгоритма” (ГОСТ 19.701-90). Однако потребности
практики не всегда требовали установления вычислимости конкретных
функций или разрешимости конкретных задач.
В языках программирования возникло и закрепилось новое понятие
“процедуры”, которое конкретизировало общее понятие алгоритма
применительно к решению задач на компьютерах. Также как и алгоритм
процедура представляет собой законченную последовательность действий
или операций, направленных на решение отдельной задачи. В языках
программирования появилась специальная синтаксическая конструкция,
которая получила название процедуры, а языки стали называться
процедурно-ориентированными.
Со временем разработка больших программ превратилась в
серьезную проблему и потребовала их разбиения на более мелкие
5
фрагменты с тем, чтобы можно было ее разрабатывать коллективом
разработчиков. Основой для такого разбиения стала процедурная
декомпозиция, при которой отдельные части программы или модули
представляют собой совокупность процедур для решения некоторой задач
того или иного класса.
Главная особенность процедурного программирования заключается
в том, что программа всегда имеет начало и окончание (начальную и
конечную процедуру). При этом вся программа может быть представлена
визуально в виде направленной последовательности примитивов или
блоков.
Все эти идеи способствовали становлению системы взглядов на
процесс разработки программ и написание программных кодов, которая
получила название методологии структурного программирования.
Основой данной методологии является процедурная деком-позиция
программной системы и организация отдельных модулей в виде
совокупности выполненных процедур.
В рамках методологии получило развитие нисходящее проектирование ПО и программирование “сверху - вниз”.
Период наибольшей популярности структурного програм-мирования
приходится на конец 70-х – начало 80-х годов. В этот период основным
показателем сложности разрабатываемых программ стал её размер –
количество строк, а трудоёмкость оценивали в “человеко-месяц”.
Методология объектно-ориентированного
программирования
В 80-е годы в связи с широким распространением ЭВМ и
усложнением разрабатываемых программных систем стало очевидным, что
традиционные методы процедурного программирования не способны
справиться с возникшими проблемами. Нужна была новая методология,
которая решила бы проблемы сложности и надёжности – методология
ООП.
Фундаментальным понятием в ней является понятие класса и
объекта. При этом под классом понимают некоторую абстракцию
совокупности объектов, которые имеют общий набор свойств и обладают
одинаковым поведением. Каждый объект в этом случае рассматривается
как экземпляр соответствующего класса.
6
Важнейшей особенностью класса является возможность их
организации в виде некоторой иерархической структуры, которая по
внешнему виду напоминает схему классификаций понятий формальной
логики в соответствии с их объёмом и содержанием.
Такая иерархия классов обеспечивает наследование кодов (предков).
Экономия времени разработки и повышение надёжности, а также
возможность дальнейшего развития (и наследования). Это достигается
механизмами наследования и полиморфизма. Надёжность программного
кода поддерживается механизмом инкапсуляции.
Появились языки программирования, которые обеспечивают
поддержку новой методологии (С++, Паскаль). На базе этих языков были
созданы визуальные объектно-ориентированные среды программирования
с библиотеками классов (MFC, VCL).
Широкое распространение методологии ООП оказало влияние на
процесс
разработки
программ.
Процедурно-ориентированная
декомпозиция программ уступила место объектно-ориентированной
декомпозиции, при которой отдельными структурными единицами
программы стали классы и объекты со свойствами и методами. Как
следствие этого подхода, программа перестала быть последовательностью
предопределенных на этапе кодирования действий, а стала событийноуправляемой.
Наиболее существенным обстоятельством в развитии ООП явилось
осмысление того факта, что процесс написания программного кода может
быть отделен от процесса проектирования структуры программы.
В самом деле, до того как начать программирование классов, их
свойств и методов, необходимо определить, чем являются классы, сколько
их в программе, каковы их свойства и методы. Эта совокупность задач не
столько связана с написанием кода, сколько с общим анализом требований
к будущей программе, а также с анализом конкретной предметной области,
для которой разрабатывается программное обеспечение.
Все эти свойства привели к появлению специальной методологии
программирования – объектно-ориентированного анализа и проектирования.
Методология объектно-ориентированного анализа и
проектирования
7
Современное разделение процесса разработки программных
приложений на отдельные этапы способствовало становлению адэкватной
концепции жизненного цикла программ. Под “жизненным циклом”
программы понимается совокупность взаимосвязанных и следующих во
времени этапов, начиная от разработки требований к ней и заканчивая
полным отказом от ее исполнения. Международный стандарт ISO\IFC
12207 описывает структуру жизненного цикла, включающего следующие
этапы:
1)
Анализ предметной области и формулировка требований к
программе: осуществляется определение функций программы и
концептуализация предметной области аналитиками и специалистами
предметной области и заканчивается выработкой концептуальной схемы.
2)
Проектирование структуры программы: разрабатывается
детальная схема программы, классы с их свойствами и методами,
взаимосвязи
между
классами
аналитиками,
архитекторами
и
квалифицированными программистами; заканчивается разработкой
детализированной схемы программы, на которой указываются все классы
и взаимосвязи между ними в процессе функционирования программы.
3)
Реализация программы в кодах (программирование) с
использованием средств автоматизации.
4)
Тестирование программы.
5)
Внедрение программы.
6)
Сопровождение программы.
7)
Отказ от использования программы.
Технология ООАП автоматизирует первый и второй этап
жизненного цикла. Исторически второй этап был автоматизирован раньше
других, при этом были использованы CASE - средства (Computer Aided
Software Engineering).
В настоящее время созданы CASE - средства на базе UML (Unified
Modeling Language), который предоставляет пользователю мощную
формализованную графическую нотацию, которая приближается к языкам
представления знаний.
UML предназначен для описания проектных моделей, их визуализации и документирования.
Язык UML основан на некотором числе базовых понятий, которые
могут быть изучены и применены большинством программистов,
желающих эффективно внедрять методы ООАП. При этом базовые
8
понятия могут расширятся, чтобы разрабатывать модели сложных систем в
различных областях приложений.
Рассмотрим основные принципы построения моделей сложных
систем, которые используются в ООАП и реализованы в языке UML.
1.
Принцип абстрагирования, который предписывает включать в
модель только те аспекты, которые имеют непосредственное отношение к
выполняемым функциям этой системы, при этом все второстепенные
детали опускаются, чтобы не осложнять процесс анализа.
2.
Принцип многомодельности – никакая единственная модель не
может в достаточной степени адекватно описать различные аспекты
сложной системы. Это означает, что достаточно полная модель сложной
системы допускает некоторое число взаимосвязанных представлений,
каждая из которых адекватно отражает некоторый аспект структуры или
поведения системы. При этом наиболее общими представлениями сложной
системы принято считать статическое и динамическое представления,
которые могут подразделяться на другие более частные представления.
3.
Принцип иерархического представления модели – процесс
построения модели рассматривается на разных уровнях абстрагирования и
детализации в рамках фиксированного представления, при этом исходная
модель системы должна быть наиболее общей (метопредставлением).
Таким образом, процесс ООАП можно представить как поуровневый
спуск от наиболее общих моделей представления концептуального уровня
к более частным логического и физического уровня. При этом на каждом
этапе ООАП данные о модели последовательно дополняются все большим
количеством деталей.
Логическое
представление:
конечный
пользователь,
внешние
и
внутренние структурные представления.
Представление
реализации:
программист,
отно-шения
между
компонентами ПО
Модель
сложной
Представление процессов
Представление размещефункционирования:
ния компонентов: системный
системный
интегратор,
администратор,
топология
производительность
и
взаимосвязи и коммуникация
масштабируемость
компокомпонентов системы.
нентов системы
9
В языке UML процесс ООАП имеет специальное назначение
“рационально унифицированный процесс” Rational Unified Process (RUP).
Суть концепции RUP заключается в последующей декомпозиции на
отдельные этапы, на каждом из которых осуществляется разработка
соответствующих типов канонических диаграмм модели систем. При этом
на начальных этапах RUP строятся логические представления статической
модели структуры и затем логическое представление модели поведения,
физическое представление модели системы. В результате процессе
строятся канонические диаграммы:
‰
Диаграмма вариантов использования (use case diagram);
‰
Диаграмма классов (class diagram);
‰
Диаграммы поведения (behavior diagram);
ƒ Диаграмма состояний (statechart diagram);
ƒ Диаграмма деятельности (activity diagram);
ƒ Диаграммы взаимодействия (interaction diagrams);
• Диаграмма последовательности (sequence diagram);
• Диаграмма кооперации (collaboration diagram);
‰
Диаграммы реализации (implementation diagrams);
ƒ Диаграмма компонентов (component diagram);
ƒ Диаграмма развертывания (deployment diagram).
Совокупность этих диаграмм является самодостаточным в том
смысле, что в них содержится вся информация, которая необходима для
реализации проекта сложных систем.
Диаграммы вариантов использования
Техника вариантов использования - была впервые предложена
Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за
счет простоты и легкости восприятия и применения. Суть ее состоит в
следующем: проектируемая система представляется в виде наборов
актеров, взаимодействующих с системой с помощью так называемых
вариантов использования. Актером является любая сущность,
взаимодействующая с системой извне. Им может быть человек,
оборудование, другая система, т. е. мы определяем, что взаимодействует с
10
системой. В свою очередь вариант использования описывает, что система
предоставляет актеру, т. е. определяет некоторый набор транзакций,
совершаемый актером при диалоге с системой, при этом ничего не
говориться о том, каким образом будет реализовано взаимодействие.
Диаграмма вариантов использования несет в себе высокий уровень
абстракции, что позволяет еще на ранних этапах проекта определить и
зафиксировать функциональные требования к системе и обеспечить
гибкий и эффективный механизм взаимодействия между разработчиком и
заказчиком проекта.
Диаграммы классов
Диаграмма классов показывает статическую структуру части
системы. Таким образом, составляющими данного типа диаграмм
являются классы, объекты и отношения между ними. Нотация классов и
объектов проста и интуитивно понятна всем, кто когда-либо имел опыт
работы с разного рода CASE-инструментариями. Класс представлен
прямоугольником с тремя разделами, в которых соответственно
помещаются имя класса, атрибуты и операции. Схожая нотация
применяется и для объектов - экземпляров класса, с тем различием, что к
имени класса добавляется имя объекта и вся надпись подчеркивается.
Нотация UML предоставляет широкие возможности для отображения
дополнительной (и зачастую очень важной) информации (абстрактные
операции и классы, стереотипы, общие и частные методы, интерфейсы,
параметризованные классы и т.д.). Ассоциации, т. е. статические связи
между классами, изображаются в виде связующей линии, на которой
может указываться мощность ассоциации, ее направление, название и
возможное ограничение, реализующее механизм расширения UML.
Существует возможность отразить специфические свойства ассоциации,
например: отношение агрегации, когда составными частями класса могут
выступать другие классы. Такое отношение изображается в виде ромба,
расположенного рядом с агрегирующим классом. Отношение обобщения
также имеет собственную графическую нотацию в виде треугольника и
связующей линии, позволяя представить иерархию наследования: от
суперкласса к подклассам.
Диаграммы взаимодействия
Диаграммы взаимодействия описывают взаимодействие объектов
системы, выполняемое ими для получения некоторого результата. Под
получением результата подразумевается выполнение законченного
действия, например, описание в терминах взаимодействующих объектов
смоделированного ранее варианта использования системы или некоторого
11
сервиса системы, объявленного как операция класса на соответствующей
диаграмме. Диаграммы взаимодействия представляются в двух формах:
диаграмма последовательности и диаграмма кооперации. И та, и другая
описывают потоки сообщений (вызовы методов или сигналы) между
объектами, участвующими во взаимодействии.
Диаграмма последовательности
Диаграмма последовательности делает упор на временную
последовательность передаваемых сообщений, важен порядок, вид и имя
сообщения, на диаграмме изображаются исключительно те объекты,
которые непосредственно участвуют во взаимодействии и не
показываются возможные статические ассоциации с другими объектами.
Таким образом, для диаграммы последовательности ключевым моментом
является динамика взаимодействия.
Диаграмма последовательности имеет два измерения. Одно - слева
направо в виде вертикальных линий, изображающих объекты,
участвующие во взаимодействии. Верхняя часть линий дополняется
прямоугольником, содержащим имя класса объекта или имя экземпляра
объекта. Второе измерение - вертикальная временная ось. Сообщения,
посылаемые одним объектом другому, изображаются в виде стрелок с
именем сообщения и упорядочены по времени возникновения.
Диаграмма кооперации
Для диаграммы кооперации главным является возможность
отобразить не столько последовательность взаимодействия, сколько все
окружение объектов, участвующих в нем. То есть показаны не только
посылаемые и принимаемые сообщения, но и косвенные связи между
ассоциированными объектами. Говорят, что диаграммы кооперации
описывают полный контекст взаимодействия и представляют собой
своеобразный временной "срез" конфигурации сети объектов,
взаимодействующих для выполнения определенной бизнес - цели программной системы.
Диаграмма кооперации изображает объекты, участвующие во
взаимодействии в виде прямоугольников, содержащих имя объекта, его
класс и, возможно, значение атрибутов.
Ассоциации между объектами, как и на диаграммах классов,
изображаются в виде соединительных линий. Возможно указание имени
ассоциации и ролей, которые играют объекты в данной ассоциации.
Динамические связи - потоки сообщений представляются также в виде
12
соединительных линий между объектами, сверху которых располагается
стрелка с указанием направления и имени сообщения.
Диаграммы состояний
Диаграммы состояний описывают поведение объекта во времени,
т. е. моделирует все возможные изменения в состоянии объекта,
вызванные внешними воздействиями со стороны других объектов или
извне. Диаграммы состояний применяются для описания поведения
объектов и для описания операций классов. В отличие от диаграмм
взаимодействия данный тип диаграмм описывает изменение состояния
только одного класса или объекта. Каждое состояние объекта
представляется на диаграмме состояний в виде прямоугольника с
закругленными углами, содержащего имя состояния, и, возможно,
значение атрибутов объекта в данный момент времени. Переход
осуществляется при наступлении некоторого события: получении
объектом сообщения или приемом сигнала и изображается в виде стрелки,
соединяющей два соседних состояния. Имя событие указывается на
переходе. Кроме того, на переходе могут указываться действия,
производимые объектом в ответ на внешние события (при переходе из
одного состояния в другое или при нахождении в определенном
состоянии). Надо отметить, что диаграмма состояния описывает, в
основном, реакцию объекта на асинхронные внешние события, для
описания реакции на внутренние события предназначены диаграммы
активности. Срабатывание перехода может зависеть не только от
наступления некоторого события, но и от выполнения определенного
условия, называемого пусковым условием. Объект перейдет из одного
состояние в другое только, если произошло указанное событие и пусковое
условие приняло значение "истина".
Диаграммы активности
Диаграммы активности - частный случай диаграмм состояний.
Каждое состояние - это суть выполнение некоторой операции, и переход в
следующее состояние срабатывает только при завершении операции в
исходном состоянии. Таким образом, реализуется принцип процедурного,
синхронного управления, обусловленного завершением внутренних
действий. Описываемое состояние не имеет внутренних переходов и
переходов по внешним событиям.
Графическая нотация практически не отличается от нотации
диаграмм состояний, с той разницей, что на переходах отсутствует
13
сигнатура события и добавлен символ "синхронизации" переходов для
реализации параллельных алгоритмов.
Основным направлением использования диаграммы активности
является описание операций классов, когда необходимо представить
алгоритм ее реализации, при этом каждый шаг является выполнением
операции некоторого класса.
Диаграммы реализации
Диаграммы компонентов и размещения в отличие от ранее
рассмотренных диаграмм вариантов использования, классов, состояния и
следования, являющихся логическим представлением системы в процессе
ее разработки, описывают физическое представление системы. Диаграмма
компонентов позволяет определить архитектуру разрабатываемой
системы, устанавливая зависимости между программными компонентами,
в роли которых могут выступать исходный, бинарный и исполняемый коды. Во многих средах разработки модуль (или компонента) соответствует
файлу. Пунктирные стрелки, соединяющие модули, показывают
отношения взаимозависимости, аналогичные тем, которые имеют место
при компиляции.
Диаграммы размещения
Диаграммы
размещения
используются
для
представления
конфигурации компонент, процессов и объектов, присутствующих в
системе на этапе выполнения. Кроме того, диаграммы размещения
показывают
физическую
зависимость
аппаратных
устройств,
задействованных в реализации системы, а также соединений между ними маршрутов передачи информации.
Для построения диаграммы на UML используют 4 вида
графических конструкций:
1.
Значки (или пиктограммы) – графическая фигура фиксированного размера и формы, они не могут увеличивать свои размеры,
чтобы размещать внутри себя дополнительные символы. Значки могут
размещаться как внутри, так и вне графической конструкции.
2.
Графические символы на плоскости – геометрические фигуры
с изменяемыми размерами для размещения других символов.
14
3.
Пути – последовательности из отрезков линий, соединяющие
отдельные графические символы, при этом концевые точки пути
обязательно соприкасаются с геометрическими фигурами.
4.
Строки текста – служат для представления разной информации
в некоторой грамматической форме, которая допускает разбор.
При графическом изображении диаграмм следует руководствоваться следующими правилами:
1.
Диаграмма должна быть законченным представлением
рассматриваемого фрагмента предметной области.
2.
Все сущности на диаграмме одного концептуального уровня.
3.
Вся информация реальна на диаграмме.
4.
Минимальность пояснительного текста.
5.
Нет противоречивой информации.
6.
Самодостаточной должна быть диаграмма.
7.
Количество типов диаграмм для конкретной модели не
является строго фиксированным.
Практическая часть работы
1. Ознакомиться с главным меню и его командами визуальной
объектно-ориентированной среды Visio 2000.
2. Сравнить главное меню и команды Visio 2000 с главными меню и
командами других приложений Windows и выявить специфические
средства для моделирования и проектирования сложных
программных систем.
3. Найти в справочной системе примеры диаграмм UML и
скомпоновать их в документе Word 2000.
4. Найти в справочной системе описания диаграмм UML, скопировать
их в буфер, включить их в документ Word 2000 для последующего
использования и перевести их на русский язык, используя
автоматический переводчик.
5. Исполнить команду File/Save As и в открывшемся диалоговом окне
определить типы файлов, поддерживаемых средой Visio. Используя
справочную систему, выяснить назначение всех типов файлов.
15
6. Ознакомиться с номенклатурой визуальных средств, имеющихся в
среде Visio, и создать эскизы диаграмм, используемых в
программном обеспечении.
7. Для прототипа оболочки ДЭС разработать схему данных, схему
программы, схему работы системы, схему взаимодействия программ
и схему ресурсов.
8. Разработать схему алгоритма логического вывода оболочки ДЭС.
9. Разработать диаграммы интерфейсов, используемых в оболочке
ДЭС.
16
Лабораторная работа № 2
Разработка технического задания на проектирование
прототипа оболочки ДЭС
Цель работы – овладение основными принципами объектноориентированного анализа предметной области и приобретение навыков
разработки технического задания на проектирование сложной
программной системы.
Общие сведения
Анализ предметной области и формулировка требований к
программе
Предметная область – это часть реального мира, где в той или иной
степени проявляется деятельность человека. Для её успешного
осуществления практически везде в настоящее время требуется
использовать вычислительную технику, создавая всё более сложные
программные системы. Естественно, создание таких систем начинается с
детального анализа соответствующей области, в результате которого
вырабатываются требования к системе. Каждое требование – это
желательное свойство, характеристика или поведение системы, которые
можно реализовать программно на данном уровне развития
вычислительной техники.
Предметная область характеризуется множеством понятий и
терминологией, понятной специалистам в этой предметной области.
Поэтому произвести анализ предметной области и построить её модель,
которая необходима для реализации программной системы, а также
выявить, что должна делать система, далеко не просто. Для этих целей в
ООАП есть целый арсенал средств. Рассмотрим применение этих средств
для создания диагностической экспертной системы. Мы выполним
необходимые этапы создания системы: сформулируем требования к
системе, сделаем объектно-ориентированный анализ предметной области,
проведем проектирование и выполним реализацию на Visual C++.
Объектно-ориентированный анализ и проектирование применяются к
диагностической экспертной системе в процессе реализации двух
последовательных циклов разработки. В первом цикле разрабатывается
17
функционально неполная оболочка с небольшой базой знаний, во втором
цикле расширяется функциональность и база знаний системы, выделяется
оболочка экспертной системы как независимый унифицированный
программный продукт, который может использоваться для построения
диагностических экспериментальных систем любого назначения. На этом
примере будут показаны возможности применения языка UML и
шаблонов, которые представляют собой именованные описания проблем,
их решений, областей применения этих решений и способов
использования в новых ситуациях.
Пусть экспертная система помогает врачу при распознавании и
лечении простудных заболеваний. Проанализируем данную предметную
область, собирая и создавая необходимые для проектирования артефакты,
представляющие собой семантически законченные информационные
фрагменты, которые затем будут оформляться в канонические диаграммы
UML. Естественно, при анализе потребуется помощь врача-эксперта,
которого мы не собираемся заменять, при этом мы не должны слишком
глубоко уходить в предметную область. Наша цель – создать экспертную
систему, которая объединила бы возможности компьютера со знаниями и
опытом врача в такой форме, чтобы система могла предложить разумный
ответ и осуществить разумное решение поставленной задачи, а также
могла пояснить по требованию врача ход своих рассуждений в понятной
для него форме. В соответствии с этим определением проектируемая
экспертная система должна иметь четыре существенные компоненты:
Компонента формирования знаний
Компонента базы знаний
Компонента логического вывода
Компонента объяснения вывода
18
Теперь следует определить уровень создаваемой экспертной системы.
Экспертная система, которая может лишь повторить логический вывод
эксперта, является экспертной системой первого поколения. Если
экспертная система выступает в роли полноценного помощника и
советчика и способна производить анализ нечисловых данных, выдвигать
и отбрасывать гипотезы, оценивать достоверность фактов, самостоятельно
пополнять свои знания, контролировать их непротиворечивость, делать
заключения на основе прецедентов, т.е. ранее примененных правил, и даже
порождать решения новых, ранее не рассматривавшихся задач, то такую
экспертную систему относят ко второму поколению.
В первом цикле проектирования мы ограничимся первым уровнем. Во
втором цикле дополним экспертную систему некоторыми компонентами
второго уровня.
К настоящему времени создано огромное количество экспертных
систем, которые по выполняемым функциям можно разделить на
следующие классы: системы интерпретации, системы диагностики и
ремонта, системы проектирования и планирования, системы управления и
контроля,
прогнозирующие
системы
и
обучающие
системы.
Проектируемая система относится к классу экспертных систем
диагностики, которые работают в условиях большой неопределенности
исходных данных и способные производить степень достоверности
производимых заключений, что позволяет эксперту сделать окончательный
диагноз и выполнить необходимые действия по его реализации.
При построении экспертной системы любого класса очень важно
правильно построить модель знаний и рационально выбрать систему
правил логического вывода или рассуждений. Практика использования
диагностических экспертных систем показала высокую эффективность
модели знаний, основанной на импликациях трех видов (см. книгу
Марселлуса “Программирование экспертных систем на ТУРБО ПРОЛОГЕ
”/ Пер. с англ. – М.: Финансы и статистика, 1994 – 300 с.): импликациях с
одной посылкой, импликациях с двумя посылками, связанных операцией
AND(или) и импликациях с двумя посылками, связанных операцией
OR(и). Во всех трех вариантах любая посылка может входить в
импликацию как без отрицания, так и с отрицанием. При этом для
поддерживающих правил. Каждая посылка и каждая импликация
характеризуется в модели числом из диапазона [-1, 1], которое
характеризует степень определенности посылки или импликации: от
19
полной определенности (1) до неправдоподобности (-1). Логический вывод
в модели заменяется процедурой вычисления коэффициентов определенности для заключений по эмпирически введенным и проверенным
правилам. Сама модель строится в виде логической сети вывода.
Например, для простудных заболеваний она выглядит следующим
образом:
20
Правила для вычисления коэффициентов определённости в
рассматриваемой модели таковы:
1.Коэффициент определённости отрицания посылки равен взятому с
обратным знаком коэффициенту определённости самой посылки.
2.Коэффициент определённости для импликации с одной посылки
(простая
импликация)
равен
произведению
коэффициентов
определённости посылки (с учётом знака) и импликации.
3.Коэффициент определённости для импликации с двумя посылками,
связанными операцией AND, равен произведению коэффициента
определённости наименее надёжной посылки (с меньшим коэффициентом
определённости) на коэффициент определённости импликации.
4.Коэффициент определённости для импликации с двумя посылками,
связанными операцией OR, равен произведению коэффициента
определённости наиболее надёжной посылки (с большим коэффициентом
определённости) на коэффициент определённости импликации.
5.Если для оного заключения имеется несколько поддерживающих
правил, то произвольно выбирается два из них, и определяются по
правилам 1-4 два коэффициента определённости Ct1 и Ct2, а
результирующий коэффициент Ct для этих двух правил рассчитывается по
формулам:
а) Ct=(Ct1+Ct2)-Ct1*Ct2, если Ct1>0 и Ct2>0;
б) Ct=(Ct1+Ct2)+Ct1*Ct2, если Ct1<0 и Ct2<0;
в) Ct=(Ct1+Ct2)/(1-min(|Ct1|,|Ct2|)), если Ct1 и Ct2 имеют разные знаки.
Затем рассматривают Ct следующее правило, для которого вычислено
Ct3, используя эти же выражения а, б и в. Процесс продолжается до
исчерпания правил и определения результирующего коэффициента
определённости Ct.
6. При расчётах коэффициентов определённости в модели
знаний учитывают необратимые правила, которые не могут применяться,
если какая – либо из посылок имеет отрицательный коэффициент
определённости. В этом случае коэффициент определённости заключения
для этого правила принимается равным нулю. Для обратимых правил,
расчёты ведутся по формулам 1-5.
Определившись в основных подходах создания экспертных
систем подобного класса, приступим к выработке требований к
проектируемой программной системе и
построению необходимых
артефактов этого этапа. Здесь очень важно:
1. Сформулировать задачу.
21
2.
3.
4.
5.
6.
7.
Выявить потребителей системы.
Определить цели проектирования.
Регламентировать функции экспертной системы.
Описать атрибуты системы и ограничения.
Сформировать словарь терминов (тезаурус).
Используя многоуровневый принцип, описать процессы
использования системы – это так называемые прецеденты.
Для снижения риска разработки необходимо также учесть и
организационно-технические факторы. Для этого необходимо:
1. Определить группу разработчиков требований на проект.
2. Сформировать группу разработчиков программной системы.
3. Охарактеризовать предположения и допущения.
4. Учесть форсмажорные факторы.
5. Оценить зависимости от других фирм и организаций.
6. Решить вопросы с финансированием проекта.
Этот этап весьма желательно завершить в построении
приблизительной концептуальной схемы.
Общая формулировка задачи
Задачей проекта является создание экспертной системы для оказания
эффективной помощи врачу при распознавании и лечении простудных
заболеваний.
Потребители
Общественные частные лечебные учреждения, районные, городские
и областные поликлиники должны составить круг потенциальных
потребителей.
Цели проекта
Основная цель проекта – это освобождение лечащего врача от
рутинной работы по сбору симптоматической информации о заболевании
пациентов, её хранению и быстрому анализу, а также по
документированию этого процесса. Система должна автоматизировать
следующие процессы:
1. Опрос пациентов.
2. Оценку возможных заболеваний (гипотез) обследуемых.
3. Оформление и закрытие бюллетеней больных.
22
4. Выдачу рекомендаций по эффективным методам лечения
простудных заболеваний.
5. Запрос на дополнительное обследование.
6. Накопление и анализ сведений по эффективности использованных
лекарственных препаратов и методов лечения.
Функции системы
Функции системы – это её основные аспекты работы. Они должны
быть определены и систематизированы в логически связанные группы.
Они обычно формулируются в следующей форме: “ Система должна
выполнять…”.
Существует три категории функций:
1. Очевидные функции, выполнение которых очевидно для
пользователей, например, печать бюллетеней.
2. Скрытые функции, выполняемые незаметно для пользователя.
Это, например, функция по сохранению данных в системе.
Скрытые функции зачастую необоснованно упускаются в
*процессе определения требований к системе.
3. Дополнительные функции, добавление которых не приводит к
существенному удорожанию проекта и не влияет на выполнение
остальныхфункций, например, функции по упаковке данных.
Определим функции проектируемой экспертной системы, разобьём
их на классы, сделаем их ранжировку по важности, результаты представим
в виде таблицы классов функций.
23
Таблица 1
Функции поддержки базы знаний
№
п/п
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
Название функции
Категория
Создание базы знаний по предметной области
Ввод фактов в базу знаний по предметной области
Ввод правил в базу знаний по предметной области
Отображение фактов предметной области
Отображение правил предметной области
Редактирование фактов базы знаний
Редактирование правил базы знаний
Тестирование базы знаний по предметной области
Отображение списка баз знаний
Удаление базы знаний по предметной области
Поддержание целостности баз знаний
Обеспечение сохранности баз знаний
Разграничение доступа к базам знаний
Очевидная
Очевидная
Очевидная
Очевидная
Очевидная
Очевидная
Очевидная
Скрытая
Дополнительная
Дополнительная
Скрытая
Скрытая
Дополнительная
24
Таблица 2
Функции постановки диагноза заболевания
№ п/п
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Название функции
Категория
Проведение обследования пациента
Отображение
текущего
состояния
дерева вывода
Отображение результирующего состояния дерева вывода
Занесение
результатов
опроса
и
логического вывода в базу данных
пациента
Печать результирующего дерева вывода
Проведение
дополнительного
обследования пациента
Проведение повторного обследования
пациента
Очевидная
Очевидная
Очевидная
Скрытая
Дополнительная
Очевидная
Очевидная
Таблица 3
Функции выбора лечебных средств и методов
№ п/п
3. 1
3.2
Название функции
Категория
Выдача
рекомендаций
по
применению Очевидная
лекарственных препаратов и лечебных процедур
для лечения выявленного заболевания
Занесение
в
базу
данных
выданных Скрытая
рекомендаций по лечению заболевания пациента
25
Таблица 4
Функции оформления бюллетеней больных
№ п/п
4.1
4.2
4.3
4.4
4.5
4.6
Название функции
Оформление бюллетеня заболевшего
Продление бюллетеня больного
Закрытие бюллетеня выздоровев-шего
пациента
Оформление
документов
для
направления
больного
в
другое
лечебное учреждение
Оформление документов для случая
летального исхода заболевшего
Занесение в базу данных результатов
посещений лечебных учреждений и
оценок эффективности применения
лекарственных препаратов и лечебных
процедур
26
Категория
Очевидная
Очевидная
Очевидная
Дополнительная
Дополнительная
Скрытая
Таблица 5
Функции сброса и анализа статистических данных
№ п/п
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Название функции
Создание базы данных для сбора и
анализа по лечению и профилактике
заболеваний
Ввод и редактирование данных о
пациентах, заболеваниях и методах их
лечения и профилактики
Реализация запросов к базе данных по
выдаче специальных сведений о
пациентах и заболеваниях
Статистический анализ накапливаемых
данных по различным временным
периодам
Поддержание целостности базы данных
Обеспечение
надежного
хранения
данных
Обмен данными по сетевым каналам с
другими лечебными учреждениями
Категория
Очевидная
Очевидная
Очевидная
Скрытая
Скрытая
Скрытая
Дополнительная
Атрибуты системы
Атрибуты системы – это нефункциональные качества системы,
например, простота в использовании. Очень часто атрибуты путают с
функциями. Атрибут не может быть подставлен в приложение: “Система
должна выполнять…”. Они всегда определяются в отдельном документе.
Значение и ограничение атрибутов обычно формулируются в
повелительном, а не в сослагательном наклонении и записываются в
27
отдельную таблицу с указаниями категорий: обязательные, желательные и
т. д. и с привязкой к соответствующей функции.
Атрибуты системы могут относиться ко всем функциям одновременно,
как, например, аппаратная платформа, либо к одной или нескольким
функциям.
Атрибуты системы характеризуются допустимым набором значений и
могут принимать дискретные, нечеткие или смысловые значения,
например:
время опроса пациента = психологически приемлемое;
стиль интерфейса оболочки = графический, цветной, оконный;
качество идентификации заболеваний = высокое;
Некоторые атрибуты могут иметь ограничения или ограниченные
условия, задаваемые, как правило, в виде числового значения атрибута,
например:
степень достоверности распознавания заболевания = более 0.9.
Приведем еще несколько атрибутов проектируемой системы:
надежность системы = не менее 99,9% ;
форма ввода базы значений = табличное .
форма опроса = диалоговая панель;
способ ввода коэффициентов неопределенности = грубой - с
помощью радиокнопок и точный - с помощью полосы прокрутки ;
носить документов = съемные магнитные диски, компакт диски и
бумага ;
тип СУБД = Microsoft Access ;
язык реализации = Visual C++ или Visual Java ++ 6.0;
операционная система = Windows NT;
возможность использования в сети = рассматривается.
Очень удобно описывать атрибуты системы вместе с функциями в
функциональной классификацией, используя таблицу:
№
п/п
Функция
2.1
Проведение об- Очевидная
Категория
Атрибут
Значения
и Категория
ограничения
Психологически Обязатель
приемле-мое
ная
Время
опроса
28
служиван
ия
пациента
пациента
29
Теперь
необходимо
построить
диаграмму
использования
проектируемой системы, которая должна выполнять требуемые функции.
Актерами диаграммы являются:
1. Эксперт предметной области.
2. Инженер по знаниям предметной области.
3. Специалист по базам данных.
4. Системный программист.
5. Системный аналитик.
6. Лечащий врач.
7. Оператор ПЭВМ.
8. Пациент.
Практическая часть работы
1. Внимательно изучите проектные материалы (артефакты) по созданию
экспертной системы для диагноза простудных заболеваний.
2. Определите этапность создания диагностической экспертной системы и
набор функций, реализуемых на каждом этапе.
3. Выделите функции диагностической экспертной системы, которые не
зависят от предметной области и могут быть реализованы в виде
независимой программной системы, называемой оболочкой ДЭС.
4. Изучите функциональное поведение прототипа ДЭС, реализованного на
Visual C ++.
5. Изучите логическую и физическую структуру прототипа ДЭС,
используя исходные файлы и обучающую систему по реализации на
Visual C++.
6. Разработайте техническое задание на проектирование оболочки ДЭС и
оформите это задание в соответствии с ГОСТами на структуру и
содержание технических заданий на проекты программных систем.
30
Лабораторная работа № 3
Разработка диаграммы вариантов использования для
прототипа оболочки ДЭС
Цель работы – овладение навыками построения диаграммы
вариантов использования на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
(USE CASE DIAGRAM)
Диаграмма
вариантов
использования
является
исходным
концептуальным представлением (моделью) системы в процессе её
проектирования и разработки. Она описывает функциональное назначение
системы и завершает анализ предметной области, когда определились
требования к функциональному поведению проектируемой системы. Эта
диаграмма будет в дальнейшем детализироваться в форме логических и
физических моделей. Она также станет основой взаимодействия
разработчиков и заказчика и войдёт в состав документации по системе.
При построении диаграммы фиксируется множество сущностей или
актёров, взаимодействующих с системой по установленным правилам,
которые называют теперь вариантами использования. Актёром может быть
человек, техническое устройство, программа или какая-либо другая
система. Все они являются источниками взаимодействия. В свою очередь,
вариант использования служит для ожидания сервисов, которые система
предоставляет актёру, т.е. наборов действий, совершаемых системой при
диалоге с актёром. Способ реализации действий не уточняется. Визуально
диаграммы вариантов использования представляет собой граф
специального вида с указанием актёров, вариантов использования,
интерфейсов и отношений между ними. Диаграмма вариантов может
дополняться пояснительным текстом, который раскрывает смысл
составляющих её компонентов, и называется примечанием или сценарием.
Отдельный вариант использования обозначается на диаграмме
эллипсом, внутри которого содержится его краткое название или
выполняемое действие в форме глагола с необходимыми уточнениями:
31
Провести обследование
Цель варианта использования заключается в том, чтобы определить
законченный аспект или фрагмент поведения некоторой сущности без
раскрытия её внутренней структуры. Это означает, что после выполнения
этого действия, система должна возвратиться в исходное состояние для
выполнения следующих запросов. Каждый выполняемый вариантом
использования метод реализуется как неделимая транзакция. При
дальнейшей детализации модели возможны изменения в том или ином
варианте использования, т.е. может иметь место обратная связь.
Стандартным графическим обозначением актёра на диаграммах
является следующая фигура с надписью:
Пациент
Актёры взаимодействуют с системой посредством передачи и
приёма сообщений от вариантов использования. Сообщение представляет
собой запрос актёра на сервис системы. Это взаимодействие отображается
на диаграмме в виде ассоциации актёра и варианта использования. Кроме
этого с актёрами могут быть связаны интерфейсы, которые определяют,
каким образом другие элементы взаимодействуют с актёрами.
Таким образом, интерфейс служит для спецификации параметров
модели. Которые видимы извне без указания их внутренней структуры. Он
не может содержать ни атрибутов, ни состояний, ни направленных
ассоциаций. В нём перечисляются только операции без указания
особенностей их реализации. Формально интерфейс эквивалентен
абстрактному классу без атрибутов и методов с наличием только
абстрактных операций. Графически представляются малым кругом с
надписью:
Термометр
Вопрос пациенту
Прибор анализа
32
Анализ спирта
и ответ пациента
состава крови
Интерфейс связывается с вариантом использования сплошной
линией без стрелок или пунктирной линией со стрелкой. В последнем
случае вариант использования предназначен для спецификации только
того сервиса, который необходим для реализации данного интерфейса. В
первом случае интерфейс может иметь и другие функции.
Провести
обследование
Установить
личность
Форма общения
Сведения о пациенте
Важность интерфейсов заключается в том, что они определяют
стыковочные узлы в проектируемой системе, что необходимо для
коллективной работы над проектом, при этом они не зависят от способов
реализации системы.
Любой элемент диаграммы может иметь пояснения, которые
помещаются в прямоугольник на диаграмме с загнутым верхним правым
уголком. Этот прямоугольник соединяют пунктирной линией с
соответствующим элементом диаграммы. Для записи ограничений на
проектируемую систему используется ключевое слово constract, после
которого в фигурных скобках на языке OCL записывают требуемое
ограничение:
Это
пояснение
-
Это
-
тоже
Constrain
t {отклик < Se}
Между компонентами диаграммы могут существовать различные
отношения, которые описывают взаимодействие экземпляров одних
актеров и вариантов использования с экземплярами других актеров и
вариантов. Один актер может взаимодействовать с несколькими
вариантами использования. В свою очередь один вариант использования
может взаимодействовать с несколькими актерами, представляя для всех
них свой сервис.
33
В языке UML имеются следующие виды отношений между актерами
и вариантами использования:
1.
Отношение ассоциации, которое определяет специфическую
роль актера в отдельном варианте использования. На
диаграмме оно обозначается сплошной линией с названием.
На концах линии может указываться кратность. Кратность
характеризует общее количество конкретных экземпляров
данного компонента, которые могут выступать в качестве
элементов данной ассоциации: 5; 1…5; 2…*; *.
2.
Отношение расширения, которое определяет взаимосвязь
экземпляров отдельного элемента использования с более
обширным вариантом. На диаграмме оно обозначается
пунктирной линией со стрелкой от более общего варианта к
менее общему с надписью “расширяет”.
3.
Отношение обобщения, которое служит для указаний того
факта, что некоторый вариант использования А может быть
обобщен до варианта использования В. Например, вариант
использования
“Оформить
заказ
на
приобретение
компьютера” может быть обобщен до варианта “Оформить
заказ на приобретение товара”. На диаграмме отношение
обозначается сплошной линией со стрелкой, указывающей
на родительский, т.е. более общий вариант использования.
Здесь возможно множественное наследование свойств и
поведения отчуждений
предков. Такое отношение
обобщения может существовать и между отдельными
актерами.
4.
Отношение включения, которое определяется между двумя
вариантами использования и указывает, что некоторое
заданное поведение для одного варианта использования
включается в качестве составного компонента в
последовательность
поведения
другого
варианта
использования. На диаграмме обозначается пунктирной
линией со стрелкой и надписью “включает”. Например,
варианты использования “Оформить заказ на приобретение
компьютера” включает вариант “Выписать счет на оплату
компьютера”. Это отношение не следует путать с
отношением расширяет, например, вариант использования “
Запросить каталог всех товаров” расширяет вариант
“Оформить заказ на приобретение товара”.
34
В качестве примера приведем диаграмму использования для
системы продажи товаров по каталогу. На диаграмме приведены все
актеры, варианты использования и отношения между компонентами
диаграммы.
Главное назначение диаграммы использования заключается в
формализации функциональных требований к системе и возможности
согласования полученной модели с заказчиком на ранней стадии
проектирования. Не более 20 актеров и 50 вариантов
Система продажи товаров
Согласовать
Прода
1
условия
По
Заказ
товаров со
Обеспечить
Вк
Оформить
заказ
на
Расши
Про
давец
Запросит
ь каталог товаров
Оформить заказ на
35
По
купатель
Практическая часть работы
1. Ознакомиться с примером диаграммы вариантов использования,
приводимой в приложении.
2. Внимательно изучить графическую нотацию для построения
диаграмм вариантов использования.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы вариантов использования
оболочки ДЭС.
5. Дополнить модель интерфейсами и используемыми базами данных с
необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
вариантов использования и предоставить преподавателю.
36
Лабораторная работа № 4
Разработка диаграммы классов для прототипа оболочки ДЭС
Цель работы – овладение навыками построения диаграммы классов
на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА КЛАССОВ
(CLASS DIAGRAM)
Диаграмма классов служит для представления статической
структуры
модели
системы
в
терминах
классов
объектноориентированного программирования. Она представляет собой некоторый
граф, вершинами которого являются элементы типа “классификатор”,
которые связаны различными типами структурных отношений. На
диаграмме могут быть также интерфейсы, пакеты и даже объекты классов,
при этом пакеты используются для представления более общей модели
системы.
Графически класс изображается в виде прямоугольника с указанием
имени класса и возможно списка атрибутов, а также операций. Атрибуты и
операции образуют секции и отделяются друг от друга и от имени
горизонтальными линиями. При проектировании в прямоугольнике
сначала записывается имя класса, а атрибуты и операции записываются по
мере проработки программной системы. Иногда используется и четвёртая
секция для указания исключительных ситуаций или определения
семантики класса.
Имя класса должно отражать назначение класса и записываться на
английском или русском языке с большой буквы. Имя абстрактного класса
записывается курсивом. Каждый атрибут класса имеет определённую
область видимости:
+ общедоступный (public);
# защищённый (ptotected);
- закрытый (private).
Иногда область видимости совсем не указывается. Квантор
видимости ставится перед именем атрибута. После имени атрибута
37
указывается его кратность в классе и тип. Кратность задаётся диапазоном
целых чисел, разделённых двумя точками. Верхняя граница диапазона
может быть звёздочкой, которая означает произвольное целое число. Тип
атрибута соответствует типу языка реализации.
Операция класса представляет некоторый сервис, представляемый
данным классом. В записи операции указывается квантор видимости, имя
операции, список параметров в круглых скобках, а также тип
возвращаемого значения. В фигурных скобках далее можно указать тип
операции:
{ concurreney = sequential } - последовательная;
{ concurrency = concurrent } - возможно распараллеливания;
{ concurrency = guarded }
- охраняемая.
Между классами могут быть отношения зависимости (---Æ),
ассоциации (-), агрегации(<>-), обобщения(<-).
38
Пример диаграммы классов:
39
Практическая часть работы
1.
Ознакомиться с примером диаграммы классов, приведённой в
Приложении А.
2.
Внимательно изучить графическую нотацию для построения
диаграмм классов.
3.
Используя справочную систему ДЭС и приложение В,
определить используемые в оболочке классы, их атрибуты и методы, а
также установить имеющиеся между ними и объектами зависимости и
отношения.
4.
Разработать структуру диаграммы классов оболочки ДЭС.
5.
Дополнить каждый класс необходимыми атрибутами и
операциями.
6.
Нанести на диаграмму взаимосвязи и отношения между
классами и объектами.
7.
При необходимости использовать дополнительные стереотипы,
механизмы расширения, помеченные значения и интерфейсы.
8.
Произвести проверку правильности построения диаграммы
классов.
9.
Сгенерировать реализацию классов прототипа оболочки ДЭС
на языке С++.
10. Создать приложение на Visual C++ 6.0 и включить в него
сгенерированные исходные коды классов.
11. Отладить приложение в среде Visual C++ 6.0.
40
Лабораторная работа № 5
Разработка диаграммы состояния для прототипа оболочки
ДЭС
Цель работы – овладение навыками построения диаграммы
состояния на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА СОСТОЯНИЙ
(STATECHART DIAGRAM)
Диаграмма состояний описывает процесс изменения состояния
только одного класса, а точнее – одного экземпляра определенного класса,
т. е. моделирует все возможные изменения в состоянии конкретного
объекта, вызванные внешними воздействиями со стороны других объектов
или даже извне. Она позволяет определить возможные последовательности
состояний и переходов, которые в совокупности характеризуют поведение
элемента модели в течении его жизненного цикла.
Графически
диаграмма
состояний
представляется
графом
специального вида – автоматом. Вершинами графа являются состояния
или псевдосостояния, изображаемые прямоугольником со скруглёнными
углами, внутри которого записывается имя состояния и возможно список
внутренних действий, выполняемых объектом в этом состоянии. Список
действий отделяется от имени горизонтальной линией. Дуги графа служат
для обозначения переходов из состояния в состояние. Диаграммы
состояний могут быть вложенными друг в друга для более детального
описания элементов модели. Дуги на графе являются ориентированными и
снабжены надписями, указывающими причины перехода (событий).
Главное различие между состоянием и переходом заключается в том, что
длительность нахождения системы в отдельном состоянии существенно
превышает время, которое затрачивается на переход из одного состояния в
другое. Считается, что этот переход осуществляется мгновенно.
На диаграмме выделяются два специальных состояния начальное- “
” и конечное “
“ (псевдосостояние). Каждое внутреннее действие
записывается в виде строки, состоящей из метки действия и следующего за
ним через “ / ” выражения действия. Метками могут быть:
41
entry – для обозначения действия, выполняемого в момент входа в
данное состояние;
exit
– для обозначения действия, выполняемого при выходе из
состояния;
do – для обозначения действия, выполняемого в течении всего
времени пребывания объекта в данном состоянии;
include – для обращения к подавтомату.
По своему назначению диаграмма состояния не является
обязательным представлением в модели и присоединяется к тому
элементу, который имеет нетривиальное поведение в течении своего
жизненного цикла.
42
Практическая часть работы
1. Ознакомиться с примером диаграммы состояний, приводимой в
приложении.
2. Внимательно изучить графическую нотацию для построения
диаграмм состояний.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы состояний оболочки ДЭС.
5. Дополнить модель интерфейсами и используемыми базами данных
с необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
состояний и предоставить преподавателю.
43
Лабораторная работа № 6
Разработка диаграммы деятельности для прототипа оболочки
ДЭС
Цель работы – овладение навыками построения диаграммы
деятельности на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА ДЕЯТЕЛЬНОСТИ
(ACTIVITY DIAGRAM)
Диаграмма деятельности используется для моделирования процесса
выполнения операций в проектируемой системе. Графически она
представляется в форме графа, вершинами которого являются состояния
действия, а дугами – переходы от одного состояния к другому. Состояние
действия соответствует выполнению некоторой элементарной операции, а
переход в следующее состояние срабатывает только при завершении этой
операции. Диаграммы деятельности можно считать частным случаем
диаграмм состояний. Отличие заключается в семантике состояний и в
отсутствии на переходах названий событий, с соответствующими
аргументами(сигнатур событий).
Основным направлением использования диаграмм деятельности
является визуализация особенностей реализации операций классов, когда
необходимо представить алгоритмы их выполнения. Традиционно для этой
цели использовались блок-схемы или структурные схемы алгоритмов, в
которых основное внимание акцентировалось на последовательности
выполнения элементарных алгоритмических и логических операций,
приводящих в совокупности к получению желаемого результата. Сам же
результат мог привести к изменению состояния системы или возвращению
некоторого значения. Время в явном виде отсутствовало на этих
диаграммах несмотря на то, что они предназначались для моделирования
поведения систем.
Графически состояние действия изображается овалом, внутри
которого записывается действие в виде глагола на естественном языке с
необходимыми пояснительными словами или в виде совокупности
44
операторов на том языке программирования, на котором предполагается
реализовывать конкретный проект:
Открыть выходной файл
r := r+1
Никаких дополнительных или неявных ограничений при записи действий
не накладывается.
Иногда возникает необходимость представить на диаграмме
деятельности некоторое сложное действие, которое, в свою очередь,
состоит из нескольких более простых действий. В этом случае
используется специальное обозначение:
Отсортировать
массив
Такое состояние называется состоянием поддеятельности (subactivity state).
Каждая диаграмма деятельности должна иметь единственное
начальное и единственное конечное состояния, которые обозначается
окружностями:
начальное
конечное
При этом каждая деятельность начинается в начальном состоянии и
заканчивается в конечном состоянии.
Диаграммы деятельности принято располагать таким образом, чтобы
действия следовали сверху вниз. В этом случае начальное состояние будет
находиться в верхней части диаграммы, а конечное – в её нижней части.
Переходы на диаграмме изображаются сплошными линиями со стрелками.
Если из состояния действия выходит единственный переход, то он не
помечается. Если таких переходов несколько, то срабатывать может только
один из них. Для этих целей на переходах записываются сторожевые
условия в квадратных скобках. Само состояние называется ветвлением и
обозначается небольшим ромбом без текста. В этот ромб может входить
только одна стрелка. Принято входящую стрелку присоединять к верхней
или левой вершине символа ветвления. Выходящих стрелок может быть
две или более, но для каждой из них явно указывается сторожевое условие
в форме булевского выражения:
Вместо
сторожевого
условия
допускается
использовать слово “иначе”.
[d=0]
d<0]
45
Знак ромба может использоваться и для объединения ветвлений. В
этом случае в ромб входят две или более стрелок, а выходит одна.
Для представления параллельных процессов используется прямая
чёрточка, толщина которой несколько шире основных линий диаграммы.
При этом разделение (concurrent fork) имеет один входящий переход и
несколько выходящих. Слияние (concurrent join) имеет несколько
входящих переходов и один выходящий.
Разделение
Слияние
Диаграммы деятельности используются для моделирования бизнес
процессов, где выполнение каждого действия ассоциируется с конкретным
подразделением компании. Для этих целей используется специальная
конструкция, получившая название дорожки. При этом все состояния
действия делятся на отдельные группы, которые отделяются друг от друга
вертикальными линиями и окружаются общей рамкой. Две соседние линии
образуют дорожку, в верхней части которой записывается название
подразделений. Пересекать линии дорожки могут только переходы.
Порядок следования дорожек не несёт какой-либо семантической
информации.
В общем случае действия выполняются над теми или иными
объектами, которые либо инициируют выполнение действий, либо
определяют некоторый их результат. Часто эти объекты также помещают
на диаграмму, связывая их пунктирными линиями со стрелками и указывая
название объекта и его состояние (заказ [получен]).
46
Пример диаграммы деятельности.
47
Практическая часть работы
1. Ознакомиться с примером диаграммы деятельности, приводимой
в приложении.
2. Внимательно изучить графическую нотацию для построения
диаграмм деятельности .
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы деятельности оболочки ДЭС.
5. Дополнить модель интерфейсами и используемыми базами
данных с необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
деятельности и предоставить преподавателю.
48
Лабораторная работа № 7
Разработка диаграммы последовательности для прототипа
оболочки ДЭС
Цель работы – овладение навыками построения диаграммы
последовательности на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ
(SEQUENCE DIAGRAM)
Диаграмма
последовательности
отображает
взаимодействие
объектов во времени осуществляемое с помощью различных механизмов
передачи и приема сообщений. На ней изображаются исключительно те
объекты, которые непосредственно участвуют во взаимодействии и не
показываются возможные статические ассоциации с другими объектами.
Диаграмма имеет два измерения. Одно слева направо в виде вертикальных
линий, каждая из которых изображает линию жизни отдельного объекта,
участвующего во взаимодействии. Графически каждый объект
изображается прямоугольником и располагается в верхней части своей
линии жизни. Внутри прямоугольника записывается имя объекта и имя
класса, разделенные двоеточием. Вся запись подчеркивается, что является
признаком объекта. Крайний слева объект является инициатором
взаимодействия. Правее изображается другой объект, который
непосредственно взаимодействует с первым, так что все объекты на
диаграмме упорядочены.
Второе измерение диаграммы – вертикальная временная ось,
направленная сверху вниз. Начальному моменту времени соответствует
самая верхняя часть диаграммы. Сообщения изображаются в виде
сплошных горизонтальных линий со стрелками и снабжаются именами
сообщений. Они упорядочиваются по времени своего возникновения. Ось
времени не масштабируется и моделирует лишь временную
упорядоченность взаимодействий типа “раньше позже”.
Линия жизни объекта изображается пунктирной вертикальной линией,
связанной с этим объектом, и служит для обозначения его периода жизни.
Для обозначения момента уничтожения объекта используется символ “Х”.
49
Сам объект на диаграмме располагается в том месте диаграммы, которое
соответствует моменту его возникновения.
Для выделения активного объекта на диаграмме применяется
специальное понятие, получившее название фокус управления. Он
изображается в виде вытянутого узкого прямоугольника на линии жизни ,
заменяя её на время активности объекта. На линии жизни могут быть
несколько прямоугольников, соответствующих периодам активности
объекта.
В отдельных случаях инициатором взаимодействия в системе может
быть актер. В этом случае он изображается в верхнем левом углу
диаграммы со своим фокусом управления, который будет существовать
постоянно, отмечая характерную для пользователя активность в
инициировании взаимодействия с системой.
Иногда некоторый объект может инициировать рекурсивное
взаимодействие с самим собой. На диаграмме эта рекурсия обозначается
небольшим прямоугольником, присоединенным к правой стороне фокуса
управления рассматриваемого объекта.
Взаимодействие между объектами осуществляется с помощью
передачи сообщений в самом широком смысле. Они могут инициировать
выполнение операций объектом соответствующего класса, а параметры
этих операций передаются вместе с сообщением. Все сообщения также
упорядочены по времени своего возникновения в системе. Часто
отправителя сообщения называют клиентом, а получателя сервером.
Сервер либо выполняет операцию, либо передает клиенту необходимую
информацию в форме обратного сообщения.
Существуют следующие виды сообщений, изображаемые на
диаграмме различными линиями и различными формами стрелок:
1. Сообщения для вызова процедур, выполнения операции или
обозначения отдельных, вложенных потоков управления, изображаемые
сплошной линией с залитой стрелкой “
”.
2. Сообщения для обозначения простого потока управления с
передачей фокуса управления серверу, изображаемые сплошной линией с
полу стрелкой “
”.
3. Сообщения при возникновении исключительной ситуации,
вызывающие прерывание и обозначаемые сплошной линией с обычной
стрелкой “→”.
4. Сообщения для возврата из процедур, изображаемые пунктирной
линией со стрелкой “--->”.
50
В отдельных случаях объект может посылать сообщения самому себе,
инициируя так называемые рефлексивные сообщения. Такие сообщения
изображаются прямоугольником со стрелкой, начало и конец которой
совпадают.
Значения параметров отдельных сообщений могут содержать
условные выражения, образуя ветвление или альтернативные пути
основного потока управления. Для изображения ветвления рисуются две
или более стрелки, выходящие из одной точки фокуса управления объекта.
При этом соответствующие условия должны быть явно указаны рядом с
каждой из стрелок в форме сторожевого условия.
Некоторые сообщения вызывают выполнение стандартных
действий. Эти действия указываются на диаграмме явно рядом с
соответствующим сообщением. Для этого используются следующие
обозначения:
1. “call”-вызов операции или процедуры принимающего объекта.
2. “return”-возврат значения выполненной операции или процедуры
вызвавшему объекту.
3. “create”-создание другого объекта для выполнения определенных
действий.
4. “destroy”-уничтожение соответствующего объекта
5. “send”-посылка сигнала объекту, асинхронно возникшего в
посылающем объекте, где описан этот сигнал.
Во всех остальных случаях для сообщения записывается имя операции
и аргументы, которые заключаются в круглые скобки: звонок(),
соединение(b), коммутация(a,b).
Иногда выполнение тех или иных действий может потребовать явной
спецификации временных ограничений, накладываемых на сам интервал
выполнения операций или передачи сообщений. На диаграмме такие
ограничения записываются слева от стрелки сообщений в виде выражения,
которое заключается в фигурные скобки. Если временная характеристика
относится к конкретному объекту, то имя этого объекта записывается
перед выражением и отделяется от него точкой: (b.время ожидания ответа
не более 5 сек)
На диаграммах последовательности могут использоваться
комментарии для отдельных сообщений или объектов.
51
:Коммутатор
с: Телефонный аппарат
d: Телефонный аппарат
бонент
b: Або
Поднять
трубку
Тон-сигнал()
*Поворот
диска
*Набор
цифры
Коммутация(a,b)
"create"
:Разговор
"send"
"send"
Соединение()
Соединение(а)
Опустить
трубку
Звонок()
Поднять
трубку
Соединение(в)
Закончить
разговор
Закончить
разговор
"destroy"
X
{После установления
соединенияабоненты
a и b могут начать
обмен информацией}
Диаграмма последовательности для
моделирования телефонного разговора
52
Опустить
трубку
Практическая часть работы
1. Ознакомиться с примером диаграммы последовательности,
приводимой в приложении.
2. Внимательно изучить графическую нотацию для построения
диаграмм последовательности.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы последовательности оболочки
ДЭС.
5. Дополнить модель интерфейсами и используемыми базами
данных с необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
последовательности и предоставить преподавателю.
53
Лабораторная работа № 8
Разработка диаграммы кооперации для прототипа оболочки
ДЭС
Цель работы – овладение навыками построения диаграммы
кооперации на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА КООПЕРАЦИИ
(COLLABORATION DIAGRAM)
Диаграмма
кооперации
предназначена
для
спецификации
структурных аспектов взаимодействия программной системы. На
диаграмме в виде прямоугольников изображаются участвующие во
взаимодействии объекты, указываются ассоциации между ними и их роли,
изображаются потоки сообщений, пронумерованных в порядке их
инициализации, при этом в виде отдельного измерения время не
указывается. Таким образом, эта диаграмма представляет собой
временной срез совокупности объектов, взаимодействующих между собой
для выполнения определенной цели.
Диаграмма кооперации может быть представлена на двух уровнях:
а) На уровне спецификации, когда показывается роль
классификаторов, т.е. классов интерфейсов типов данных, компонент, и
роли ассоциации в рассматриваемом взаимодействии;
б) На уровне примеров, когда указываются экземпляры, и связи,
образующие отдельные роли в кооперации, при этом используются только
те объекты, которые принимают участие во взаимодействии.
Одна и та же совокупность объектов может участвовать в различных
кооперациях. При этом, в зависимости от рассматриваемой кооперации,
могут изменяться как свойства отдельных объектов, так и связи между
ними. Такой выбор лишь нужных свойств и ассоциаций отличает эти
диаграммы от диаграмм классов, где должны быть обязательно указаны
все свойства и все ассоциации элементов диаграммы.
На уровне спецификации кооперация изображается пунктирным
эллипсом, внутри которого записывается имя этой кооперации,
54
представляющей отдельный вариант использования с дополнительной
детализацией, которая отражает особенности будущей реализации
программной системы. Эллипс соединяется пунктирными линиями с
участниками кооперации, в качестве которых могут выступать объекты
или классы. Линии помечаются ролями участников. Роли соответствуют
именам элементов в контексте всей кооперации.
Покупатель
Продаж а
товара
Продавец
Классы изображаются прямоугольником, внутри которого
записывается строка текста, показывающая особенности использования
объектов данного класса и называемая ролью классификатора. Обычно
секция атрибутов и операции не указываются. Пример строки: /обработчик
запросов: Сервер.
Если кооперация является реализацией операцией некоторого класса,
то на диаграмме это изображают следующим образом:
Заказнапокупку
Продажа
Оформитьзаказ
илитак
Продажа:Заказна
покупку::оформить
заказ
Если кооперация допускают обобщенное представление, то на
диаграммах могут быть указаны отношения обобщения соответствующих
элементов, рассмотренные в диаграммах вариантов использования.
Кооперации на уровне спецификации используются на начальных
этапах проектирования. В последующем каждая из коопераций подлежит
детализации на уровне объектов, на котором раскрывается содержание и
структура взаимосвязей её элементов. В качестве элементов здесь
выступают объекты и связи, дополненные сообщениями.
55
Для графического изображения объектов используется такой же
символ прямоугольника, что и для классов. Варианты записи строки текста
в прямоугольнике могут быть следующими:
: С -анонимный объект образуемый на основе класса С;
/R -анонимный объект, играющий роль R;
/R:C -анонимный объект класса С с ролью R;
О/R -объект с именем О и ролью R;
О:С -объект класса С имеющий имя О;
О/R:С
-объект с именем О класса С и ролью R;
О
-объект с именем О;
О: -“объект - сирота” с именем О;
/R -роль с именем R;
/:С -анонимная роль на базе класса С;
/R:С -роль с именем R на основе класса С.
На диаграмме могут присутствовать множества объектов, которым
адресуются операции и сигналы. Такое множество объектов называется
мультиобъектом и изображается двумя прямоугольниками, один из
которых выступает из-за правой верхней вершины другого, в котором
записывается строка текста объекта.
В языке UML все объекты делятся на две категории: пассивные и
активные. Пассивный объект оперирует только данными и не может
инициировать деятельность по управлению другими объектами. Однако
пассивные объекты могут посылать сигналы в процессе выполнения
запросов, которые они получают.
Активный объект имеет свою собственную нить управления и
может инициировать деятельность к управлению другими объектами, при
этом данная нить может выполняться параллельно с другими нитями
вычисления и управления. Такие объекты выделяются на диаграмме
утолщенными границами или ключевым словом {active}. Например,
{active}
а: Вызывающий абонент является инициатором процесса
установления соединения для обмена информации с другим абонентом.
На диаграмме кооперации могут присутствовать и составные
объекты, являющиеся экземплярами контейнерных классов, которые
связаны отношением агрегации или композиции со своими частями.
Аналогичное отношение связывают при этом между собой и
соответствующие
объекты.
Составной
объект
изображается
прямоугольником с двумя секциями. В верхней секции записывается имя
56
составного объекта, а в нижней – его составные части вместо списка его
атрибутов. Они также изображаются прямоугольниками с именами. В
свою очередь вложенные объекты могут быть составными.
Между объектами диаграммы указываются необходимые связи,
которые являются экземплярами или примерами некоторой ассоциации.
Связь может иметь место между двумя и более объектами. Бинарная связь
изображается отрезком прямой линии. На концах линии указываются
имена ролей данной ассоциации, а в середине линии – ее имя, т.е.
собственных имен связи не имеют.
Связь может иметь некоторые стереотипы, которые записываются
рядом с одним из её концов и указывают на особенность реализации
данной связи:
“association” - ассоциации предполагаемые по умолчанию;
“parameter” - параметр метода;
“local” - локальная переменная метода, область видимости которой
ограничена соседним объектом;
“global” - глобальные переменные, область видимости которой – вся
диаграмма кооперации;
“self” - рефлексивная связь объекта с самим собой, которая
изображается петлёй у прямоугольника - объекта.
На диаграмме кооперации указываются также сообщения, которые
здесь
имеют некоторые семантические особенности. Сообщение
специфицирует коммуникацию между двумя объектами, один из которых
передает
другому
некоторую
информацию
для
выполнения
соответствующего действия. Таким образом, именно сообщение является
причиной или стимулом для начала выполнения операций, отправки
сигналов, создания и уничтожения отдельных объектов. При этом связь
обеспечивает лишь канал для направленной передачи сообщения, которые
изображаются помеченными направленными стрелками рядом с этой
связью. Внешний вид стрелки имеет определенный вид:
—► - вызов процедуры или другого вложенного потока управления;
- простой поток управления, при этом каждая такая стрелка
изображает один этап в последовательности потока управления,
- асинхронный поток управления, инициируемый чаще всего
актерами;
- -> - возврат из вызова процедуры, при этом такие стрелки
предполагаются по умолчанию и не рисуются на диаграммах.
57
Заметим, что каждое сообщение может быть помечено строкой
текста со сложным форматом, в которой перечисляются предшествующие
сообщения, передаваемые обязательно до данного; сторожевое условие для
синхронизации нитей потока управления; список аргументов для вызова
операции по данному сообщению и другие параметры.
58
Рассмотрим пример диаграммы кооперации:
5:Коммутация(a,b)
4:*[i:=1
..n]:набор
цифры(i)
8:в ызов абонента(b)
:Коммутатор
линиясв язи
линиясв язи
с:Телефонный
аппарат
1:Поднять
трубку()
3*: Поворот
диска()
11б:Начать
разговор()
d:Телефонный
аппарат
6:создать()
"local"
7:подтв ердить()
:Разгов ор
{transient}
9:зв онок
10:поднять
трубку
11а:начать
разговор
"local"
"global"
у частник
разгов ора
"global"
у частник
разгов ора
а:Абонент
b:Абонент
59
Практическая часть работы
1. Ознакомиться с примером диаграммы кооперации, приводимой в
приложении.
2. Внимательно изучить графическую нотацию для построения
диаграммы кооперации.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы кооперации оболочки ДЭС.
5. Дополнить модель интерфейсами и используемыми базами
данных с необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
кооперации и предоставить преподавателю.
60
Лабораторная работа № 9
Разработка диаграммы компонентов для прототипа оболочки
ДЭС
Цель работы – овладение навыками построения диаграммы
компонентов на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА КОМПОНЕНТОВ
(COMPONENT DIAGRAM)
Для создания конкретной физической системы необходимо
некоторым образом реализовать все элементы логического представления
в конкретные материальные сущности. Прежде всего необходимо
разработать исходный текст программы на некотором языке
программирования. При этом уже в тексте программы предполагается
такая организация программного кода, которая предполагает его разбиение
на отдельные модули.
Тем не менее исходные тексты программы еще не являются
окончательной реализацией проекта, хотя и служат фрагментом его
физического представления. Очевидно, программная система может
считаться реализованной в том случае, когда она будет способна
выполнять функции своего целевого предназначения. Для этого
необходимо, чтобы программный код системы был реализован в форме
исполняемых модулей, библиотек классов и процедур, стандартных
графических интерфейсов, файлах баз данных.
Именно эти компоненты являются необходимыми элементами
физического представления.
В языке UML для физического представления моделей систем
используются диаграммы реализации, которые включают две отдельные
канонические диаграммы: диаграмму компонентов и диаграмму
развертывания. Диаграмма развертывания описывает платформу и
вычислительные средства для работы системы. Если программная система
работает на одном компьютере, то диаграмму развертывания не строят.
Диаграмма компонентов разрабатывается для следующих целей:
61
1. Визуализации общей структуры исходного кода программной системы
2. Спецификации исполняемого варианта программной системы.
3. Обеспечения многократного использования отдельных фрагментов
программного кода.
4. Представления концептуальной и физической схемы баз данных.
В разработке диаграммы компонентов принимают участие
системные аналитики, архитекторы системы и программисты. Одни
компоненты существуют на этапе компиляции программного кода (
исходные модули), другие на этапе его исполнения.
В бизнес - системах диаграммы включают отделы, службы и
документы, которые реально существуют в системе.
Физическая сущность в UML называется компонентом. Компонент
реализует некоторый набор интерфейсов. На диаграмме он обозначается
следующим образом:
Отдельный компонент может быть представлен на уровне типа или
на уровне компилятора. Их имена при этом различаются. В первом случае
записывается только имя типа с заглавной буквы. Во втором случае
записывается имя компонента, а затем через двоеточие – имя типа. Вся
строка имени в этом случае подчеркивается.
Имя компонента и имя типа может состоять из любого числа букв,
цифр и некоторых знаков препинания. Иногда для имени экземпляра
используют другую нотацию:
имя компонента начинается со строчной буквы, а подчеркивание
имени не используется.
В качестве простых имен компонент используют имена файлов:
*.exe, *.dll, *.htm, *.txt, *.doc, *.hlp, *.db, *.mdb, *.h, *.cpp, *.java, *.class,
*.pl, *.asp и т.д.
В ряде случаев символ компонента разделяется на секции, чтобы
явно указать имена реализованных в нем интерфейсов ( расширенное
обозначение компонента).
62
Поскольку компонент как элемент физической реализации модели
представляет отдельный модуль кода, иногда его комментируют с
указанием дополнительных графических символов, иллюстрирующих
конкретные особенности реализации:
для *.dll – два зубчатых колеса на листе, для *.htm – закрашенный
круг, для *.hlp – строчки текста с точками перехода в виде закрашенных
прямоугольников на листе,
для *.cpp – строчки текста и т. д. Эти дополнительные обозначения
не специфицированы в языке UML. В языке же UML выделяют только три
вида компонентов:
1. Компоненты
развертывания,
которые
обеспечивают
непосредственное выполнение системой своих функций: *.dll, *.htm,
*.hlp.
2. Компоненты – рабочие продукты, как правило – это файлы с
исходными текстами программ: *.h, *.cpp и т. п.
3. Компоненты исполнения – файлы *.exe.
Эти компоненты называют артефактами разработки. Другой способ
спецификации различных видов компонентов явное указание
стереотипа компонента перед его именем:
Библиотека (library) –для динамической или статической
библиотеки.
Таблица (table) –для таблицы базы данных.
Файл (file) – для файлов с исходными текстами программ.
Документ (document) – для документов.
Исполнимый (executable) – для компонентов, которые могут
исполняться в узле.
Компонентами
также
являются
интерфейсы,
которые
изображаются
кружочком,
соединяемыми
с
программными
компонентами отрезками линий без стрелок.
При этом имя интерфейса должно начинаться с буквы “I” и
записывается рядом с окружностью. Линия означает, что программный
компонент реализует этот интерфейс.
Другим способом представления интерфейса является его
изображения в виде прямоугольника класса со стереотипом Interface и
возможными секциями атрибутов и операций. Если компонент реализует
некоторый интерфейс, то такой интерфейс называется экспортируемым.
Используемый интерфейс другого модуля называется импортируемым и
63
изображается пунктирной линией со стрелкой, направленной к
интерфейсу.
На диаграмме компонентов необходимо указать другие
зависимости, изображаемые также линией со стрелкой, направленной от
зависимого элемента ( клиента ) к независимому элементу ( источнику ).
Такими зависимостями могут быть, например, связи модулей программы
на этапе компиляции и генерации объектного кода. В другом случае
зависимость может отражать наличие в независимом компоненте
описаний классов, которые используются в зависимом компоненте для
создания соответствующих объектов. Очень важным случаем отношения
зависимости является отношения между различными видами
компонентов, что означает следующее: внесение изменений в исходные
тексты компонент приводят к изменениям компонента-клиента.
Наконец, на диаграмме компонентов могут быть представлены
отношения зависимости между компонентами и реализованными в них
классами. Для обозначения такого компонента используется
расширенный символ прямоугольника компонента. Он делится на две
части. В верхней секции записывается имя, а в нижней- перечисляются
реализуемые классы. Если компонент использует объекты, то они также
могут быть изображены в виде поименованных прямоугольников в
нижней секции. Подобная вложенность означает, что выполнение
компонента влечет выполнение соответствующих объектов, т.е.
существование компонента в течение времени исполнения программы
обеспечивает существование, а возможно, и доступ всех вложенных в
него объектов.
Дадим несколько рекомендаций по построению диаграммы
компонентов :
1. Максимально
учитывать
информацию
о
логическом
представлении модели системы.
2. Точно знать вычислительные платформы и операционные
системы, на которых будет реализовываться система.
3. Хорошо
представлять
возможности
выбранного
языка
программирования.
4. Определиться с выбором базы данных или знаний.
5. При делении программной системы на физические модули или
файлы следует добиваться такой реализации, которая обеспечила
бы возможность повторного использования кода и создания
объектов только при их необходимости. Для этой цели необходимо
большую часть описаний классов, их операций и методов вынести
64
в DDL , оставив в исполняемых компонентах только самые
необходимые для инициализации программы фрагменты
исполняемого кода.
6. После общей структуризации физического представления системы
необходимо дополнить ее интерфейсами и схемами базы данных,
обращая особое внимание на согласование различных частей
программной системы, спецификацию таблиц и установление
связей между таблицами.
7. Завершать построение диаграммы компонентов необходимо
установлением и нанесением взаимосвязей между компонентами, в
том числе и отношений реализации, используя при этом различные
виды графического изображения компонентов. Полученная
диаграмма должна иллюстрировать все важнейшие аспекты
физической реализации системы, начиная с особенностей
компиляции исходных текстов программ и заканчивая
исполнением отдельных частей программы на этапе ее
выполнения.
8. При разработке диаграммы компонентов необходимо использовать
уже имеющиеся в языке UML компоненты и стереотипы, прибегая
лишь в исключительных случаях к механизмам расширения:
дополнительные стереотипы и помеченные значения.
Пример диаграммы компонентов:
Практическая часть работы
1. Ознакомиться с примером диаграммы компонентов, приводимой
в приложении.
65
2. Внимательно изучить графическую нотацию для построения
диаграмм компонентов.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы компонентов оболочки ДЭС.
5. Дополнить модель интерфейсами и используемыми базами
данных с необходимыми информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
9. Произвести проверку правильности построения диаграммы
компонентов.
66
Лабораторная работа № 10
Разработка диаграммы развертывания для прототипа
оболочки ДЭС
Цель работы – овладение навыками построения диаграммы
развертывания на примере оболочки ДЭС.
Общие сведения
ДИАГРАММА РАЗВЕРТЫВАНИЯ
(DEPLOYMENT DIAGRAM)
Диаграмма
развертывания
(размещения)
применяется
для
представления общей конфигурации и топологии распределенной
программной системы и содержит распределение компонентов по
отдельным узлам системы, а также необходимые физические соединения –
маршруты передачи информации между аппаратными устройствами,
задействованными в реализации системы. При этом визуализируется
только компонента – экземпляры программ, являющийся исполнимыми
файлами или динамическими библиотеками, которые используются на
этапе исполнения. Она содержит графические изображения процессоров,
устройств, процессов и связей между ними и является единой для системы
в целом, завершая этапы спецификации модели.
Диаграммы
развертывания
необходимы,
когда
сложные
программные системы реализуются в сетевых вариантах на различных
вычислительных платформах и технологиях доступа к распределенным
базам данных, основанных на схемах клиент-сервер. Для локальных
программных систем такие диаграммы не используются.
Основным элементом на диаграмме является узел, представляющий
некоторый физический существующий вычислительный ресурс системы:
память, процессор, датчик, принтер, модем, сканер, манипулятор и т. п.
Иногда в понятие узла включают человека и даже организационные
подразделения. Графически узел изображается трехмерным кубом с
надписью. Если узел представляется в качестве типа, то имя не
подчеркивается, а если в качестве экземпляра, то имя подчеркивается, при
этом после имени узла указывают и имя типа. В обоих случаях имя
начинается с большой буквы. Узел – экземпляр может не иметь имени узла
67
(анонимный узел). В любом случае перед именем типа для узла –
экземпляра ставиться двоеточие.
За именем узла в фигурных скобках разрешается размещать
дополнительную информацию. Если необходимо явно указать компоненту
узла, то графический символ разбивают на две секции, при этом в верхней
секции записывают имя узла, а в нижней указывают размещенные в узле
компоненты, перечисляя их имена. Иногда в узле даже изображают
установленные на нем компоненты, как на диаграмме компонентов. Более
того, на диаграммах развертывания допускаются специальные обозначения
для различных физических устройств, графическое изображение которых
проясняет назначение или выполняемые устройством функции:
компьютер, клавиатура и т. д.
Соединения на диаграмме изображаются отрезками линий без
стрелок. Это указывает на необходимость организации физического канала
для обмена информацией между соответствующими узлами. Характер
соединения может быть дополнительно специфицирован примечанием.
Можно также указать отношение зависимости между узлом и
развернутыми на нем компонентами, а не изображать их внутри узла.
68
Практическая часть работы
1. Ознакомиться с примером диаграммы развертывания,
приводимой в приложении.
2. Внимательно изучить графическую нотацию для построения
диаграмм развертывания.
3. Используя справочную систему ДЭС и ее работающий прототип,
определить набор физических компонент и интерфейсов, а также
установить имеющиеся между ними зависимости и связи.
4. Разработать структуру диаграммы развертывания оболочки
ДЭС.
5. Дополнить модель интерфейсами и используемыми базами
данных с необходимыми и информационными связями.
6. Нанести на диаграмму взаимосвязи и отношения реализации.
7. При необходимости использовать дополнительные стереотипы,
механизмы расширения и помеченные значения.
8. Произвести проверку правильности построения диаграммы
развертывания и предоставить преподавателю.
Заключение
Использование UML и визуальной объектно-ориентированной среды
моделирования само по себе не является панацеей от всех бед, т. е. не
гарантирует успеха проекта только по факту использования, но может
сразу же решить ряд проблем, возникающих при разработке программных
систем. Язык UML обеспечивает прекрасную возможность для интеграции
между различными инструментальными средствами, процессами и
проблемными областями. Но что самое важное, он позволяет
разработчикам сфокусировать свое внимание на реализации бизнес
требований к системе и предоставляет им парадигму для осуществления
данной цели.
69