Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Объектно-ориентированное моделирование на основе UML. Учебное пособие
.pdf
С.В. Самуйлов
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ
МОДЕЛИРОВАНИЕ
НА ОСНОВЕ UML
Учебное пособие
Саратов
2016
УДК 004
ББК 32.97
Автор
С.В. Самуйлов, к.т.н., доцент кафедры «Информатика, математика и обще-
гуманитарные науки» Пензенского филиала Финансового университета при Пра-
вительстве РФ.
Самуйлов С.В.
Объектно-ориентированное моделирование на основе UML: учебное посо-
бие / С.В. Самуйлов. — Саратов: Издательство «Вузовское образование»,
2016. — (Высшее образование). — 37 с. — Док. опубл. не был. — Доступ с сайта
ЭБС IPRbooks.
Учебное пособие представляет собой краткое изложение курса «Объектно-
ориентированное моделирование на основе UML» в форме изложения теорети-
ческого материала об основных диаграммах унифицированного языка моделиро-
вания UML. Дополнительно в конце учебного пособия рассматриваются вопросы
практического использования изученного теоретического материала в рамках
выполнения контрольной работы.
Учебное пособие ориентировано, в первую очередь, на оказание помощи
студентам при написании ими контрольной работы и самостоятельной подготов-
ке к сдаче экзамена по дисциплине «Объектно-ориентированное моделирование
на основе UML».
Учебное пособие предназначено, прежде всего, для студентов направления
подготовки «Бизнес-информатика», а также широкого круга читателей, интересующихся вопросами моделирования и проектирования.
© Самуйлов С.В., 2016
3
Содержание
Введение ......................................................................................................................... 4
1. Объектно-ориентированный подход к проектированию ИС ................................ 5
1.1. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ИС ................................................................... 5
1.2. ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ......................................................... 8
1.3. ДИАГРАММА КЛАССОВ ........................................................................................ 13
1.4. ДИАГРАММА СОСТОЯНИЯ .................................................................................... 19
1.5. ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ ................................................................. 22
1.6. ДИАГРАММА ДЕЯТЕЛЬНОСТИ .............................................................................. 26
2. Цель и организация выполнения контрольной работы ....................................... 30
3. Требования к оформлению контрольной работы ................................................. 32
4. Структура и содержание контрольной работы ..................................................... 33
5. Темы теоретической части контрольной работы ................................................. 35
6. Темы практической части контрольной работы .................................................. 36
Список литературы ...................................................................................................... 37
4
Введение
Предлагаемое учебное пособие посвящено рассмотрению основных приемов
визуального моделирования систем с помощью UML и предназначено студентам
направления подготовки «Бизнес-информатика» для аудиторных и самостоятельных занятий по дисциплине «Объектно-ориентированное моделирование на
основе UML». В пособии описываются основные элементы нотации диаграмм
UML, на конкретном примере рассматривается процесс проектирования информационных систем с применением программной платформы StarUML. Этапы со-
здания визуальной модели сопровождаются иллюстрированными инструкциями.
Последние разделы учебного пособия содержат варианты заданий к кон-
трольной работе по дисциплине и требования к ее оформлению.
5
1. Объектно-ориентированный подход к проектированию ИС
1.1. Методология проектирования ИС
В основе проектирования ИС лежит моделирование предметной области.
Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области
понимается некоторая система, имитирующая структуру или функционирование
исследуемой предметной области и отвечающая основному требованию – быть
адекватной этой области [1].
Как правило, строится система моделей, которая отражает структурный и
оценочный аспекты функционирования предметной области.
С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать бу-
дущих пользователей системы к ее разработке.
Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность
графических объектов, используемых в модели. Нотация является синтаксисом
языка моделирования. Язык моделирования, с одной стороны, должен делать
решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспе-
чения.
В основе различных методологий моделирования предметной области ИС
лежат принципы последовательной детализации абстрактных категорий. Обычно
модели строятся на трех уровнях: на внешнем уровне (определении требовании),
на концептуальном уровне (спецификации требований) и внутреннем уровне
(реализации требовании).
Так, на внешнем уровне модель отвечает на вопрос, что должна делать си-
стема, то есть определяется состав основных компонентов системы: объектов,
функций, событий, организационных единиц, технических средств.
На концептуальном уровне модель отвечает на вопрос, как должна функ-
ционировать система? Иначе говоря, определяется характер взаимодействия
компонентов системы одного и разных типов.
На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе?
С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа системных требований, логического (техниче-
ского) и физического (рабочего) проектирования.
6
Существуют различные методологии структурного моделирования предмет-
ной области, среди которых следует выделить функционально-ориентированные
и объектно-ориентированные методологии [1].
Объектные методики рассматривают моделируемую организацию как
набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение
объектов, составляющих организацию, и распределение между ними ответствен-
ностей за выполняемые действия.
Функциональные методики рассматривают организацию как набор функ-
ций, преобразующий поступающий поток информации в выходной поток. Основное отличие от объектной методики заключается в четком отделении функ-
ций (методов обработки данных) от самих данных.
С точки зрения бизнес-моделирования каждый из представленных подходов
обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим
структурам организации.
Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще
слабо оформлена. Подход от выполняемых функций интуитивно лучше понима-
ется исполнителями при получении от них информации об их текущей работе.
В контрольной работе для проектирования информационных систем бу-
дет использоваться объектно-ориентированный подход.
Объектно-ориентированный подход обладает следующими преимуществами
[1]:
объектная декомпозиция дает возможность создавать модели меньшего
размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для по-
вторного использования, что ведет к созданию среды разработки и переходу к
сборочному созданию моделей.
объектная декомпозиция позволяет избежать создания сложных моделей,
так как она предполагает эволюционный путь развития модели на базе относи-
тельно небольших подсистем.
объектная модель естественна, поскольку ориентированна на человече-
ское восприятие мира.
Большинство существующих методов объектно-ориентированного подхода
включают язык моделирования и описание процесса моделирования. Процесс –
это описание шагов, которые необходимо выполнить при разработке проекта. В
качестве языка моделирования объектного подхода используется унифициро-
ванный язык моделирования UML.
Язык моделирования UML фактически является стандартом по объектно-
ориентированным технологиям. Он реализован многими фирмами – производителями программного обеспечения в рамках CASE-технологий, например, Ra-
tional Rose, ARIS Toolset и др. [2].
7
Язык UML обеспечивает поддержку всех этапов жизненного цикла ИС и
предоставляет для этих целей ряд графических средств – диаграмм.
Диаграмма – это графическое представление множества элементов. Чаще
всего она изображается в виде связного графа с вершинами (сущностями) и реб-
рами (отношениями) и представляет собой некоторую проекцию системы.
На рисунке 1 приведена технологическая сеть проектирования экономиче-
ской информационной системы [2].
Рис. 1. Технологическая сеть проектирования ЭИС
На рисунке 1 ОЭИС – описание экономической информационной системы,
ДВИ – диаграмма вариантов использования, ДК – диаграмма классов, ДС – диаграмма состояний, ДПк – диаграмма пакетов, ДД – диаграмма деятельности, ДП
– диаграмма последовательности, ДР – диаграмма размещения, ДКп – диаграмма
компонентов.
На входе этапа анализа системных требований используется описание
экономической информационной системы, полученное в ходе работ по анализу и
проектированию бизнес-процессов.
Анализ системных требований начинается с идентификации основных ва-
риантов использования (ДВИ) и объектов-сущностей (ДК), которые будут
применяться в информационной системе. Работы по идентификации вариантов
использования и классов объектов-сущностей, как правило, выполняются параллельно.
Разработка диаграммы состояний объектов (ДС) осуществляется только
для классов объектов со сложным поведением. При этом рассматриваются все
варианты использования, в которых объекты данного класса используются и ме-
няют свои состояния.
Разработка диаграммы пакетов (ДПк) осуществляется путем группировки
классов объектов по подсистемам.
8
На этапе логического проектирования ЭИС осуществляется детализация
диаграммы вариантов использования, диаграммы классов, диаграммы состояний,
диаграммы пакетов и разработка диаграмм последовательности и диаграмм дея-
тельности.
Разработка диаграммы последовательности (ДП) выполняется для каждого варианта использования с учетом построенных диаграмм классов объектов и
состояний.
Разработка диаграммы деятельности (ДД) уточняет характер взаимодей-
ствия объектов не в одном, а в нескольких вариантах использования. Если диаграмма взаимодействия объектов формирует набор методов обработки объектов,
то диаграммы деятельностей дают спецификацию алгоритмов для последующего
программирования процедур этих методов.
На этапе физического проектирования происходит детализация диаграмм
классов объектов и пакетов с позиции из реализации в конкретной программнотехнической среде.
Разработка диаграммы компонентов (ДКп) и диаграммы размещения
компонентов (ДР) реализует клиент-серверную технологию и определяет схему
размещения компонент по узлам вычислительной сети.
На этапе реализации ЭИС осуществляется кодогенерация классов объек-
тов, программирование процедур методов классов объектов, наполнение баз
данных и размещение компонентов по узлам вычислительной сети [2].
В контрольной работе будет выполняться проектирование информационной
системы на этапе анализа системных требований и этапе логического проектирования.
Ниже будет рассмотрен процесс построения диаграммы вариантов использования, диаграммы классов, диаграммы состояний, диаграммы последовательности и диаграммы деятельностей для предметной области «Продажа компьюте-
ров через Интернет-магазин».
1.2. Диаграмма вариантов использования
Визуальное моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится
модель в форме так называемой диаграммы вариантов использования, кото-
рая описывает функциональное назначение системы или, другими словами, то,
что система будет делать в процессе своего функционирования [3].
Диаграмма вариантов использования является исходным концептуальным
представлением (моделью) системы в процессе её проектирования и разработки.
Она описывает функциональное назначение системы и завершает анализ предметной области, когда определились требования к функциональному поведению
проектируемой системы.
9
Суть данной диаграммы состоит в следующем: проектируемая система
представляется в виде множества сущностей или актеров, взаимодействующих с
системой с помощью так называемых вариантов использования.
Вариант использования – это описание на «высоком уровне» фрагмента
функциональности, которую обеспечивает система. Другими словами, вариант
использования иллюстрирует то, как можно использовать систему.
Таким образом, вариант использования служит для ожидания сервисов, которые система предоставляет актёру, т.е. наборов действий, совершаемых систе-
мой при диалоге с актёром. Способ реализации действий не уточняется.
Отдельный вариант использования обозначается на диаграмме эллипсом,
внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами. Сам текст имени варианта использования дол-
жен начинаться с заглавной буквы.
Примерами могут служить варианты использования «Покупка компьютера»,
«Построить конфигурацию» (рис. 2).
Рис. 2. Примеры вариантов использования
В начале работы над проектом возникает вопрос, как в заданной предметной
области выявить варианты использования? Для этих целей можно использовать
как документацию заказчика, так и мнение будущих пользователей проектируемой системы. Каждому пользователю системы могут быть заданы следующие
вопросы:
какие действия он предполагает выполнять с системой?
будет ли он с ее помощью вводить, обновлять, удалять информацию?
будет ли он информировать систему о каких-либо внешних событиях?
должна ли система информировать пользователя о каких-либо изменени-
ях или событиях?
Актер представляет собой любую внешнюю по отношению к моделируемой
системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения част-
ных задач.
Актёром может быть человек, техническое устройство, программа или какая-либо другая система. Все они являются источниками взаимодействия.
Стандартным графическим обозначением актера на диаграммах является
фигурка «человечка», под которой записывается конкретное имя актера.
Для предметной области «Продажа компьютеров через Интернет-магазин»
примерами могут служит актеры «Клиент» и «Система Интернет-продаж» (рис.
3).
10
Рис. 3. Примеры актеров
Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров
одних актеров и вариантов использования с экземплярами других актеров и ва-
риантов.
Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной си-
стемы.
В свою очередь один вариант использования может взаимодействовать с не-
сколькими актерами, предоставляя для всех них свой сервис.
В то же время два варианта использования, определенные в рамках одной
моделируемой системы, также могут взаимодействовать друг с другом, однако
характер этого взаимодействия будет отличаться от взаимодействия с актерами.
Однако в обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию
функционального поведения моделируемой системы.
В языке UML имеется несколько стандартных видов отношений между ак-
терами и вариантами использования:
ассоциации;
включения;
расширения;
обобщения.
На диаграммах вариантов использования ассоциация служит для обозначе-
ния специфической роли актера при его взаимодействии с отдельным вариантом
использования.
Отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь некоторые дополнительные обо-
значения, например, имя и кратность.
На рисунке 3 отношение ассоциации между актером «Клиент» и вариантом
использования «Покупка компьютера» указывает на то, что в проектируемой системе клиент может воспользоваться данным сервисом, а отношение ассоциации
между актером «Система Интернет-продаж» и вариантом использования «По-
купка компьютера» указывает на то, что покупка компьютера осуществляется
под управлением системы Интернет-продаж.
Включение в языке UML – это разновидность отношения зависимости
между базовым вариантом использования и его специальным случаем.
Отношение включения устанавливается только между двумя вариантами
использования и указывает на то, что заданное поведение для одного варианта
использования включается в качестве составного фрагмента в последователь-
ность поведения другого варианта использования.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]