И. В.

Червенчук

МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ С

ИСПОЛЬЗОВАНИЕМ ЯЗЫКА UML

Методические указания
к выполнению курсовой работы

Омск 2008
 2

Моделирование информационных систем с использованием языка UML:

Методические указания к выполнению курсовой работы / И. В. Червенчук.
Омский государственный институт сервиса, 2008.

В работе рассматриваются вопросы разработки информационных систем с

использованием унифицированного языка моделирования UML, что является
основой для выполнения курсовой работы по дисциплине «Информационные
системы и процессы. Моделирование и управление». Прорабатываются основные
этапы рационального унифицированного процесса разработки информационных
систем, приводятся примеры и иллюстрации. Даны варианты заданий к
выполнению курсовых работ.
Методические указания предназначены для студентов специальности
«Прикладная информатика» и могут быть использованы при выполнении курсовой
работы, подготовке к экзамену, а также в процессе самостоятельной работы.

Рецензент

Ответственный за выпуск зав. кафедрой ПрИМ О.Н. Лучко

 3

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ …………………………………………………………………4

1. ОБЩИЕ ТРЕБОВАНИЯ К ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ…8

2. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML .................9

3. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ ………………………………12

4. РАЗРАБОТКА МОДЕЛИ ПРОГРАММНОЙ СИСТЕМЫ

СРЕДСТВАМИ UML ……………………………………………………….14
4.1. Разработка вида с точки зрения прецедентов………………16
4.2. Разработка вида с точки зрения проектирования ………………21
4.3. Разработка профиля реляционной базы данных ………………..34

5. ВОПРОСЫ РЕАЛИЗАЦИИ ИНФОРМАЦИОННОЙ

СИСТЕМЫ……………………………………………………………. 41

6. ТЕМЫ КУРСОВЫХ РАБОТ………………………………………..46

Библиографический список…………………………………………...47
 4

ВВЕДЕНИЕ

В настоящее время существует множество средств моделирования

информационных систем и подходов, лежащих в их основе. Каждый
подход предполагает некоторую нотацию описания предметной области
в тех или иных терминах.
В России для моделирования и анализа информационных систем
достаточно широко используются следующие средства
моделирования: Rational Rose, Oracle Designer, AllFusion Process
Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS,
Power Designer.
BPWin и ERWin компании Соmputer Associates. Computer
Associates International, Inc. (CA) входит в пятерку ведущих
производителей программного обеспечения, предлагая средства
моделирования, резервного копирования, управления инфраструктурой
предприятия (сетями, серверами и т.д.), информационной безопасности,
business intelligence и т.д. Пакет BPWin основан на методологии IDEF и
предназначен для функционального моделирования и анализа
деятельности предприятия. Методология IDEF, являющаяся
официальным федеральным стандартом США, представляет собой
совокупность методов, правил и процедур, предназначенных для
построения функциональной модели объекта какой-либо предметной
области. Функциональная модель IDEF отображает функциональную
структуру объекта.
BPwin поддерживает сразу три стандартные нотации - IDEF0
(функциональное моделирование), DFD (моделирование потоков
данных) и IDEF3 (моделирование потоков работ). Эти три основных
ракурса позволяют описывать предметную область наиболее
комплексно.
Пакет ERWin это средство концептуального моделирования БД.
Используется при моделировании и создании баз данных
произвольной сложности на основе диаграмм "сущность - связь". В
настоящее время ERWin является наиболее популярным пакетом
моделирования данных благодаря поддержке широкого спектра СУБД
самых различных классов.
Oracle Designer компании Oracle. Набор инструментальных средств
Oracle Designer предлагает интегрированное решение для разработки
прикладных систем корпоративного уровня для Web и
клиент/серверных приложений. Oracle Designer участвует в каждой фазе
жизненного цикла разработки программного обеспечения - от
моделирования бизнес-процессов до внедрения. Применение единого
 5

репозитория, делает возможным использование любых его компонент

для быстрой разработки масштабируемых, кросс-платформных
распределенных приложений. Средства концептуального
моделирования Oracle Designer включают в себя:
ER-диаграммы (диаграммы информационной структуры
предметной области, представляемой в виде объектов и их
взаимосвязей);
диаграммы функциональной иерархии, описывающие функции,
которые выполняет система;
диаграммы потоков данных, циркулирующих на предприятии.
Такие модели представляют информационные потребности в
удобном и наглядном для восприятия виде, что делает их хорошим
средством коммуникации между проектировщиками и
пользователями в процессе уточнения постановки задач. Oгасlе
Designer автоматически создает отчеты, которые содержат всю
информацию о проекте и могут быть использованы как набор
документов, отражающих текущее состояние проекта.
Rational Rose компании IBM. IBM Rational Rose – входит в состав
пакета IBM Rational Suite и предназначен прежде всего для
моделирования программных систем с использованием широкого
круга инструментальных средств и платформ. Rational Rose является
одним из ведущих систем визуального моделирования объектно-
ориентированных систем в программной индустрии, благодаря
полноценной поддержке языка UML (Унифицированный язык
моделирования) и многоязыковой поддержке командной разработки.
Система полностью поддерживает компонентно-ориентированный
процесс создания информационных систем. Любые участники проекта
– аналитики, специалисты по моделированию, разработчики и другие
могут использовать модели, построенные в Rational Rose, для
большей эффективности создания конечного продукта. Любые
модели, создаваемые с помощью языка UML, являются
взаимосвязанными: бизнес-модель, функциональная модель, модель
анализа, модель проектирования, модель базы данных, модель
компонентов и модель физического развертывания системы.
Существуют расширения Rational Rose, которые позволяют
выполнять скелетную (round-trip) разработку ИС, создаваемых на базе
языков C/C++, Java, Smalltalk, Ada, Object Pascal (Borland Delphi) и др.
Таким образом, можно сгенерировать каркас программного кода на
любом из указанных языков или выполнить процедуру обратного
проектирования, что позволяет сформировать модель на базе
существующего кода. Интеграция Rational Rose с Rational
TestManager позволяет создавать сценарии тестирования на базе
 6

визуальной модели. Интеграция Rational Rose с Rational ClearCase

позволяет поставить на версионный контроль модель целиком или по
частям. Интеграция Rational Rose с Rational SoDA позволяет
автоматизировать процесс создания документов и отчетов по
визуальной модели.
PowerDesigner компании Sybase. Компания Sybase со дня своего
основания традиционно является ведущим поставщиком
информационных технологий на мировой рынок финансовых
институтов. PowerDesigner является комплексным решением для
моделирования и разработки приложений и бизнес-процессов для
организаций, которые нуждаются в быстром, последовательном и
эффективном с точки зрения затрат создании или реинжиниринге
бизнес-приложений. Последняя версия продукта, PowerDesigner,
обладает новыми возможностями по моделированию бизнес-
процессов, объектному моделированию, базирующемуся на UML, и
поддерживает как традиционные, так и вновь появляющиеся
технологии моделирования в рамках одной развитой графической
среды. Это позволяет значительно сократить затраты и время
реализации проекта, который должен функционировать на различных
платформах и инструментальных средах. Одним из основных
преимуществ PowerDesigner является также использование
репозитория масштаба предприятия для хранения и управления всей
информацией, касающейся моделирования и дизайна приложений на
всех уровнях ведения бизнеса в компании. Это позволяет правильно
организовать рабочий процесс и кардинальным образом повысить
эффективность работы разработчика.
ARIS компании IDS Scheer AG. В настоящее время наблюдается
тенденция интеграции разнообразных методов моделирования и
анализа систем, проявляющаяся в форме создания интегрированных
средств моделирования. Одним из таких средств является продукт,
носящий название ARIS, разработанный германской фирмой IDS
Scheer. Основное направление - программное обеспечение и
консалтинг. Система ARIS представляет собой комплекс средств
анализа и моделирования деятельности предприятия. Ее
методическую основу составляет совокупность различных методов
моделирования, отражающих разные взгляды на исследуемую
систему. Одна и та же модель может разрабатываться с
использованием нескольких методов, что позволяет использовать
ARIS специалистам с различными теоретическими знаниями и
настраивать его на работу с системами, имеющими свою специфику.
Методика моделирования ARIS основывается на разработанной
профессором Августом Шером теории построения интегрированных
 7

ИС, определяющей принципы визуального отображения всех аспектов

функционирования анализируемых компаний. ARIS поддерживает
четыре типа моделей, отражающих различные аспекты исследуемой
системы:
организационные модели, представляющие структуру системы -
иерархию организационных подразделений, должностей и
конкретных лиц, связи между ними, а также территориальную
привязку структурных подразделений;
функциональные модели, содержащие иерархию целей, стоящих
перед аппаратом управления, с совокупностью деревьев функций,
необходимых для достижения поставленных целей;
информационные модели, отражающие структуру информации,
необходимой для реализации всей совокупности функций системы;
модели управления, представляющие комплексный взгляд на
реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как
собственные методы моделирования ARIS, так и различные известные
методы и языки моделирования, в частности, ER и UML. В процессе
моделирования каждый аспект деятельности предприятия сначала
рассматривается отдельно, а после детальной проработки всех
аспектов строится интегрированная модель, отражающая все связи
между различными аспектами. ARIS не накладывает ограничений на
последовательность построения указанных выше типов моделей.

Каждый из рассматриваемых продуктов достаточно универсален

но имеет преимущественное назначение:
для моделирования баз данных больше подходят инструменты
Erwin, Power Designer и Rational Rose;
для моделирования компонентов разрабатываемых приложений
больше подходят Oracle Designer, Power Designer и Rational Rose;
для моделирования бизнес-процессов больше подходят BPwin,
ARIS и Rational Rose.
Таким образом, средство Rational Rose, и соответственно, язык
UML являясь универсальном средством моделирования позволяет
решить все типовые задачи моделирования информационных систем.
Данное издание будет посвящено возможностям языка UML для
разработки информационных систем.
 8

1. ОБЩИЕ ТРЕБОВАНИЯ К ВЫПОЛНЕНИЮ КУРСОВОЙ

РАБОТЫ

Курсовая работа по дисциплине «Информационные системы и

процессы. Моделирование и управление» является заключительным
этапом изучения данного курса и имеет целью закрепить на практике
основные теоретические знания по моделированию информационных
систем. Работа заключается в разработке модели некоторой
информационной системы средствами унифицированного языка
моделирования UML с последующей ее реализацией. В качестве
типового варианта задания предлагается разработка информационно-
справочной системы на основе базы данных, но по желанию студента и
по согласованию с преподавателем в качестве задания студенту может
быть предложена разработка WEB-приложения, тестовой системы или
аппаратного устройства. При этом основным необходимым
требованием является применение объектно-ориентированного подхода
и построение UML-модели.
Типовое название курсовой работы выглядит как «Разработка
информационно-справочной системы _название_ »
Рекомендуется следующая структура пояснительной записки:
Введение
1. Содержательный обзор предметной области. Основные
требования к системе
2. Развернутая модель информационной системы
2.1. Вид с точки зрения прецедентов
2.2. Вид с точки зрения проектирования
2.3. Вид с точки зрения реализации
2.4. Вид с точки зрения процессов (при необходимости)
2.5. Вид с точки зрения развертывания (при необходимости)
3. Реализация информационной системы
Заключение
Приложение Листинг программы или головного модуля

Во введении можно указать на использование информационных

технологий в различных сферах деятельности, включая сферу сервиса,
преимуществах электронного учета, проблемах построения
специализированных информационных систем и т.д.
Данные методические указания содержат подробные рекомендации
к основным разделам пояснительной записки и примеры
проектирования. Следует обратить внимание, что основным предметом
данной курсовой работы является разработка UML-модели
информационной системы, поэтому настоятельно рекомендуется UML-
 9

диаграммы приводить в основной части пояснительной записки,

снабдив их подробными комментариями, а тексты программ выносить в
приложение.
Вид с точки зрения процессов следует приводить при разработке
многозадачных систем. Вид с точки зрения развертывания
предполагает наличие распределенной информационной системы.
Данные виды, и соответствующие им разделы пояснительной записки,
являются не обязательными для выполнения данной курсовой работы,
их использование предполагается при выполнении только
определенных вариантов курсовой работы.
При освещении в записке вопросов реализации системы желательно
обосновать выбор среды программирования, привести руководство
пользователя. Обязательным элементом является включение в текст
экранных форм (скрин-шортов) реализованной программы, поощряется
использование средств обратного проектирования.
В заключении кратко подводятся основные итоги работы:
разработана UML-модель системы, система реализована посредством
такой-то среды программирования, что разработанная система
позволяет, преимущества используемых подходов (на основе
моделирования) к проектированию систем.
Курсовая работа должна содержать 20-30 страниц печатного текста
с иллюстрациями. В обязательном порядке должны быть приведены
диаграммы прецедентов, классов, взаимодействия.

2. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML

Рациональная разработка информационной системы предполагает

глубокую предварительную аналитическую проработку. Прежде всего,
необходимо очертить круг задач, выполняемых разрабатываемой
системой, затем, разработать модель системы, и наконец, определить
способы реализации. Глубокая проработка архитектуры
разрабатываемой информационной системе на начальных этапах
проектирования, как правило, окупается в последствии, особенно при
разработке крупномасштабных проектов с длительным
сопровождением.
Средства языка моделирования UML (Unified Model Language, –
унифицированный язык программирования ) позволяют выразительно и
довольно легко произвести предварительную концептуальную
разработку информационной системы, и при этом, методически
сопровождать весь ход разработки включая и весь дальнейший
жизненный цикл разрабатываемой информационной системы как
программного продукта.
 10

UML – это язык для визуализации, специфицирования,

конструирования и документирования артефактов программных систем,
основанный на объектно-ориентированном подходе.
UML, как и любой другой язык, состоит из словаря и правил,
позволяющих комбинировать входящие в него слова и получать
осмысленные конструкции. В языке моделирования словарь и правила
ориентированы на концептуальное и физическое представление
информационных систем. Моделирование необходимо для понимания
системы. При этом единственной модели никогда не бывает достаточно.
Напротив, для понимания любой нетривиальной системы приходится
разрабатывать большое количество взаимосвязанных моделей. В
применении к программным системам это означает, что необходим
язык, с помощью которого можно с различных точек зрения описать
представления архитектуры системы на протяжении цикла ее
разработки.
UML – это язык визуализации, при этом UML - это не просто набор
графических символов. За каждым из них стоит хорошо определенная
семантика (см. [1]) Таким образом, модель, написанная одним
разработчиком, может быть однозначно интерпретирована другим или
даже инструментальной программой.
UML – это язык специфицирования. В данном контексте
специфицирование означает построение точных, недвусмысленных и
полных моделей. UML позволяет специфицировать все существенные
решения, касающиеся анализа, проектирования и реализации, которые
должны приниматься в процессе разработки и развертывания системы
программного обеспечения.
UML – это язык конструирования. Хотя UML не является языком
визуального программирования, модели, созданные с его помощью,
могут быть непосредственно переведены на различные конкретные
языки программирования. Иными словами, UML-модель можно
отобразить на такие языки, как Java, C++, Visual Basic, и даже на
таблицы реляционной базы данных или устойчивые объекты объектно-
ориентированной базы данных. Те понятия, которые предпочтительно
передавать графически, так и представляются в UML; те же, которые
лучше описывать в текстовом виде, выражаются с помощью языка
программирования.
Подобное отображение модели на язык программирования
позволяет осуществлять прямое проектирование: генерацию кода из
модели UML в какой-то конкретный язык. Можно решить и обратную
задачу: восстановить модель по имеющейся реализации. Естественно,
модель и реализация предполагает использование ряда специфических
сущностей. Поэтому для обратного проектирования необходимы как
 11

инструментальные средства, так и вмешательство человека. Сочетание

прямой генерации кода и обратного проектирования позволяет работать
как в графическом, так и в текстовом представлении, если
инструментальные программы обеспечивают согласованность между
обоими представлениями.
Помимо прямого отображения в языки программирования, UML в
силу своей выразительности и однозначности позволяет
непосредственно исполнять модели, имитировать поведение систем и
контролировать действующие системы.
UML – это язык документирования
Компания, выпускающая программные средства, помимо
исполняемого кода производит и другие документы, в том числе:
– требования к системе;
– архитектуру;
– проект;
– исходный код;
– проектные планы;
– тесты;
– прототипы;
– версии, и др.
В зависимости от принятой методики разработки выполнение
одних работ производится более формально, других менее. Упомянутые
документы - это не просто поставляемые составные части проекта; они
необходимы для управления, для оценки результата, а также в качестве
средства общения между членами коллектива во время разработки
системы и после ее развертывания.
UML предлагает разработчику и руководству свой вариант решения
проблемы документирования системной архитектуры и всех ее деталей,
предлагает язык для формулирования требований к системе и
определения тестов и, наконец, предоставляет средства для
моделирования работ на этапе планирования проекта и управления
версиями.

Рассмотрим разработку модели информационной системы

средствами языка UML на примере разработки автоматизированного
рабочего места секретаря кафедры (далее АРМ секретаря кафедры).

3. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

 12

Понятие предметной области базы данных является одним из

базовых понятий информатики и не имеет точного определения. Его
использование в контексте ИС предполагает существование устойчивой
во времени соотнесенности между именами, понятиями и
определенными реалиями внешнего мира, не зависящей от самой ИС и
ее круга пользователей. Таким образом, введение в рассмотрение
понятия предметной области базы данных ограничивает и делает
обозримым пространство информационного поиска в ИС и позволяет
выполнять запросы за конечное время.
Мы под описанием предметной области будем понимать описание
окружения разрабатываемой системы, типы пользователей системы, при
этом также укажем основные задачи, решение которых возлагаются на
систему.
В предварительном описании предметной области вводятся
основные термины (словарь системы), определяются типы
пользователей и их права, формулируются задачи, которые должна
решать разрабатываемая система. При этом при описании
предполагается использовать средства обычного языка и стандартной
деловой графики (рисунки, диаграммы, таблицы).
При разработке словаря системы необходимо определить имена
сущностей («студент», «преподаватель», «дисциплина»). При этом
термин сущность понимается нами как компонент модели предметной
области, то есть как уже выделенный на концептуальном уровне объект.
Выделяемые в предметной области объекты превращаются аналитиком
в сущности.
Сущность является результатом абстрагирования реального
объекта. С объектами связано две проблемы: идентификация и
адекватное описание. Для идентификации используют имя, которое
должно быть уникальным. При этом предполагается, что происходит
отказ от его смысла, который присущ естественному языку.
Используется только указательная функция имени. Имя – это прямой
способ идентификации объекта. К косвенным способам идентификации
объекта относят определение объекта через его свойства
(характеристики или признаки).
Объекты взаимодействуют между собой через свои свойства, что
порождает ситуации. Ситуации – это взаимосвязи, выражающие
взаимоотношения между объектами. Ситуации в предметной области
описываются посредством высказываний о предметной области. На
данном этапе можно использовать методы исчисления высказываний и
исчисления предикатов, то есть формальной, математической логики.
Например, высказывание "Программист и менеджер есть служащие
компании" описывает отношение включения. Таким образом, вся
 13

информация об объектах и сущностях предметной области описывается

с помощью утверждений на естественном языке.
Можно указать структурные связи, выделить статические и
динамические ситуации (таким образом ввести в модель параметр
времени), однако для детальной проработки модели удобнее
использовать развитые средства описания предметной области,
например средства языка UML.

Итак, ставится задача разработать систему «АРМ секретаря

кафедры» которая позволяла бы вести автоматизированный учёт
данных о сотрудниках и студентах кафедры ВУЗА, обеспечивала
гибкие возможности при решении запланированных и
незапланированных специфических задач обработки учетных данных.
В рамках решения задачи разработки АРМ секретаря кафедры
выделим следующие сущности:
преподаватели – преподаватели кафедры;
студенты – учащиеся вуза данной специальности;
студенты учатся в группах, группа является организующей
(объединительной) сущностью для студентов;
аспиранты, имеют ту особенность, что с одной стороны сами могут
вести занятия, с другой, сами являются учащимися и имеют научного
руководителя;
дисциплина – преподаваемая дисциплина (предмет, курс).
Веденные сущности имеют ряд атрибутов, которые мы определим в
дальнейшем.
Ведем два типа пользователей: рядовой пользователь (в
дальнейшем пользователь, и администратор. Предполагается, что
пользователь может обращаться к системе с запросом, выводить
отчеты, администратор дополнительно может модифицировать
данные. Например, в роли пользователя может выступать помощник
секретаря кафедры, в роли администратора сам секретарь, или
ответственный преподаватель.
С учетом введенных терминов разрабатываемая систем должна
обеспечивать:
– организацию полного и достоверного учета всех сотрудников и
студентов кафедры;
– информационную поддержку принимаемых управленческих решений,
формирование полной и достоверной информации об образовательных
процессах и результатах деятельности кафедры;
– сокращение трудозатрат на подготовку первичных документов и
отчетов;
 14

– устранение дублирования при вводе информации и, возникающих при

этом механических ошибок;
– удобный интерфейс пользователя;
– разграничение полномочий рядовых пользователей и
администратора.
В данном примере мы решаем частную задачу – разрабатываем
АРМ секретаря кафедры, поэтому структурной единицей самого
высокого уровня для нас принимается кафедра, которую мы будем
иметь ввиду по умолчанию, то есть предполагается, что все элементы
модели относится только к данной кафедре, что явно не
специфицируется. Структуры более высокого уровня, такие как
факультет, вуз, нами рассматриваться не будут.

4. РАЗРАБОТКА МОДЕЛИ ПРОГРАММНОЙ СИСТЕМЫ

СРЕДСТВАМИ UML

Язык UML является языком специфицирования и визуализации,

основными единицами его являются диаграммы.
Диаграмма в UML - это графическое представление набора
элементов, изображаемое чаще всего в виде связанного графа с
вершинами (сущностями) и ребрами (отношениями). Диаграммы
характеризуют систему с разных точек зрения. Диаграмма - в некотором
смысле одна из проекций системы. Как правило, диаграммы дают свер-
нутое представление элементов, из которых составлена система. Один и
тот же элемент может присутствовать во всех диаграммах, или только в
нескольких (самый распространенный вариант), или не присутствовать
ни в одной (очень редко). Теоретически диаграммы могут содержать
любые комбинации сущностей и отношений. На практике, однако,
применяется сравнительно небольшое количество типовых комбинаций,
соответствующих пяти наиболее употребительным видам, которые
составляют архитектуру программной системы (см. следующий раздел).
Таким образом, в UML выделяют девять типов диаграмм:
- диаграммы классов
- диаграммы объектов;
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий (деятельности);
- диаграммы компонентов;
- диаграммы развертывания.
Концептуальная модель UML
 15

На диаграмме классов показывают классы, интерфейсы, объекты и

кооперации, а также их отношения. При моделировании объектно-
ориентированных систем этот тип диаграмм используют чаще всего.
Диаграммы классов соответствуют статическому виду системы с точки
зрения проектирования. Диаграммы классов, которые включают
активные классы, соответствуют статическому виду системы с точки
зрения процессов.
На диаграмме объектов представлены объекты и отношения между
ними. Они являются статическими «фотографиями» экземпляров
сущностей, показанных на диаграммах классов. Диаграммы объектов,
как и диаграммы классов, относятся к статическому виду системы с
точки зрения проектирования или процессов, но с расчетом на
настоящую или макетную реализацию.
На диаграмме прецедентов представлены прецеденты и актеры
(частный случай классов), а также отношения между ними. Диаграммы
прецедентов относятся к статическому виду системы с точки зрения
прецедентов использования. Они особенно важны при организации и
моделировании поведения системы.
Диаграммы последовательностей и кооперации являются частными
случаями диаграмм взаимодействия. На диаграммах взаимодействия
представлены связи между объектами; показаны, в частности,
сообщения, которыми объекты могут обмениваться. Диаграммы
взаимодействия относятся к динамическому виду системы. При этом
диаграммы последовательности отражают временную упорядоченность
сообщений, а диаграммы кооперации - структурную организацию
обменивающихся сообщениями объектов. Эти диаграммы являются
изоморфными, то есть могут быть преобразованы друг в друга.
На диаграммах состояний (Statechart diagrams) представлен
автомат, включающий в себя состояния, переходы, события и виды
действий. Диаграммы состояний относятся к динамическому виду
системы; особенно они важны при моделировании поведения
интерфейса, класса или кооперации. Они акцентируют внимание на
поведении объекта, зависящем от последовательности событий, что
очень полезно для моделирования реактивных систем.
Диаграмма деятельности - это частный случай диаграммы
состояний; на ней представлены переходы потока управления от одной
деятельности к другой внутри системы. Диаграммы деятельности
относятся к динамическому виду системы; они наиболее важны при
моделировании ее функционирования и отражают поток управления
между объектами.
На диаграмме компонентов представлена организация
совокупности компонентов и существующие между ними зависимости.
 16

Диаграммы компонентов относятся к статическому виду системы с

точки зрения реализации. Они могут быть соотнесены с диаграммами
классов, так как компонент обычно отображается на один или
несколько классов, интерфейсов или коопераций.
На диаграмме развертывания представлена конфигурация
обрабатывающих узлов системы и размещенных в них компонентов.
Диаграммы развертывания относятся к статическому виду архитектуры
системы с точки зрения развертывания. Они связаны с диаграммами
компонентов, поскольку в узле обычно размещаются один или
несколько компонентов.
Здесь приведен неполный список диаграмм, применяемых в UML.
Инструментальные средства позволяют генерировать и другие
диаграммы, например, такие как диаграммы профиля баз данных,
диаграммы WEB-приложений и т.д.

4.1. Разработка вида с точки зрения прецедентов

Моделирование начинается с определения основных задач

разрабатываемой системы и действий, которые она должна выполнять.
Для этих целей используются диаграммы прецедентов. Как уже
говорилось, на диаграммах прецедентов указываются прецеденты и
актеры, а также отношения между ними.
Прецедент (Use case) - это описание последовательности выполня-
емых системой действий, которая производит наблюдаемый результат,
значимый для какого-то определенного актера (Actor). Прецедент
применяется для структурирования поведенческих сущностей модели.
Прецедент только декларирует описание какого-либо действия системы,
отвечая на вопрос «что делать?», но не указывает какими средствами.
Конкретная реализация специфицируемого прецедентом поведения
обеспечивается классом, кооперацией классов или компонентом.
Актер представляет собой связное множество ролей, которые
пользователи прецедентов исполняют во время взаимодействия с ними.
Обычно актер представляет роль, которую в данной системе играет
человек, аппаратное устройство или даже другая система. В
разрабатываемой системе «АРМ секретаря кафедры» актерами
являются администратор (админ) и пользователь.
Графически прецедент изображается в виде ограниченного
непрерывной линией эллипса, обычно содержащего только его имя,
актер имеет пиктограмму «человечек».
Для того, чтобы построить диаграмму прецедентов необходимо
выявить элементарные действия, производимые системой и сопоставить
их с прецедентами. При этом, имена прецедентов желательно давать
 17

так, чтобы они указывали на поведение, часто такие имена содержат

глаголы, например, «сформировать отчет», «найти данные по
критерию» и т.д. Можно давать имена прецедентам существительными,
предполагающие некоторые действия, например, «авторизация»,
«поиск», «контроль».
Возвращаясь к моделированию АРМ секретаря кафедры, выделим
прецеденты:
Редактирование данных,
Поиск студента,
Поиск преподавателя,
Выдача списка преподаваемых дисциплин,
Авторизация.

Элементы диаграммы прецедентов (прецеденты и актеры) должны

быть связаны отношениями.
Наиболее распространенным отношением между прецедентами,
прецедентами и актерами является ассоциация. В некоторых случаях
могут быть использованы отношения обобщения. Данные отношения
имеют тот же смысл, что и на диаграмме классов.
Кроме того, между прецедентами в языке UML определены две
специфические зависимости – отношение включения и отношение
расширения.
Отношение включения между прецедентами означает, что в
некоторой точке базового прецедента инкорпорировано (включено)
поведение другого прецедента. Включаемый прецедент никогда не
существует автономно, а инстанцируется только как часть
объемлющего прецедента. Можно считать, что базовый прецедент
заимствует поведение включаемых. Благодаря наличию отношений
включения удается избежать многократного описания одного и того же
потока событий, поскольку общее поведение можно описать в виде
самостоятельного прецедента, включаемого в базовые. Отношение
включения является примером делегирования, при котором ряд
обязанностей системы описывается в одном месте (во включаемом
прецеденте), а остальные прецеденты, когда необходимо, включают эти
обязанности в свой набор.
Отношения включения изображаются в виде зависимостей со
стереотипом «include». Чтобы специфицировать место в потоке
событий, где базовый прецедент включает поведение другого, вы
просто пишете слово include, за которым следует имя включаемого
прецедента.
Отношение расширения применяют для моделирования таких
частей прецедента, которые пользователь воспринимает как
 18

необязательное поведение системы. Тем самым можно разделить

обязательное и необязательное поведение. Отношения расширения
используются также для моделирования отдельных субпотоков,
выполняемых лишь при определенных обстоятельствах. Наконец, их
применяют для моделирования нескольких потоков, которые могут
включаться в некоторой точке сценария в результате явного
взаимодействия с актером.
Отношение расширения изображают в виде зависимости со
стереотипом «extend». Точки расширения базового сценария
перечисляются в дополнительном разделе. Они являются просто
метками, которые могут появляться в потоке базового прецедента.
Примером использования данного отношения может быть доступ к
базе данных имеющую оперативную часть и архив. При этом если
запрос обеспечивается данными оперативной части, выполняется
основной (базовый) доступ к данным, если же данных оперативной
части недостаточно, производится доступ к данным архива, то есть
доступ идет по расширенному сценарию.
В нашем случае, прецедент редактирование данных включает в
себя прецеденты: ввод данных, удаление данных, изменение данных.
Диаграмма прецедентов АРМ секретаря кафедры показана на рис. 1.
Прецедент поиск студента предполагает поиск по фамилии и поиск
по итогам успеваемости.

При разработке вида с точки зрения прецедентов часто необходимо

дать расширенное описание прецедента (в сокращенном варианте
указывается только его имя). Как правило, в начале работы потоки
событий прецедента описывают в текстовой форме. По мере уточнения
требований к системе будет удобнее перейти к графическому
изображению потоков на диаграммах деятельности и взаимодействия.
Потоки событий могут быть описаны посредством
неструктурированного текста, структурированного текста (содержащего
служебные слова: ЕСЛИ, ДО ТЕХ ПОР ПОКА и т.п.),
специализированного формального языка (псевдокода).
При описании прецедента потоком событий важно обозначить
также основной и альтернативный потоки поведения системы.
В качестве примера рассмотрим описание потока событий
прецедента авторизация.
 19

Добавить Изменить

<<include>>
<<include>>

<<include>>
Удалить
Редактирование данных

Админ Выдача списка

преподаваемых дисциплин
Поиск сотрудника

Авторизация
<<include>>
Поиск по фамилии

Поиск студента <<include>>

Пользователь
Поиск по оценкам

Рис. 1. Диаграмма прецедентов АРМ секретаря кафедры

Основной поток событий. Прецедент начинается, когда система

запрашивает у пользователя его входное имя (Login) и пароль
(Password). Пользователь может ввести его с клавиатуры. Завершается
ввод нажатием клавиши Enter. После этого система проверяет
введенные Login и пароль, и если они соответствуют администратору,
подтверждает полномочия администратора. На этом прецедент
заканчивается.
Исключительный поток событий. Клиент может прекратить
транзакцию в любой момент, нажав клавишу Cancel. Это действие
начинает прецедент заново. Ввод в систему не производится.
Исключительный поток событий. Клиент может в любой момент
до нажатия клавиши Enter стереть свои Login и пароль.
Исключительный поток событий. Если клиент ввел Login и пароль
не соответствующий администратору, ему предлагается произвести
повторный ввод или войти в систему на правах рядового пользователя.
 20

ввод Login,
Password

Нажатие
клавиши

Нажата
Cancel
Да

Нет
Нажата Enter

Нет
Да
Аутентификация
Login, Password

Аутентификация
администратора выполнена

Нет
Да
Установить права
администратора

Войти в систему на правах

рядового пользователя

Да Нет

Вход в систему

Рис. 2. Авторизация пользователя. Диаграмма деятельности

Очевидно, что описание прецедента потоком событий предполагает

некоторый алгоритм, который можно представить на диаграмме
деятельности (рис. 2).
Диаграмма алгоритма должна содержать начальную и конечную
вершины, причем только одну начальную, и одну конечную. Диаграмма
 21

содержит исполняемые вершины – деятельности (обозначаются

скругленными прямоугольниками), условные вершины (decision –
выбор, распознавание, обозначаются ромбиками) и связи.
Подобными диаграммами можно пояснить и выполнение других
прецедентов, таким образом дополнить вид системы с точки зрения
прецедентов использования.

4.2. Разработка вида с точки зрения проектирования

Вид с точки зрения проектирования является основным этапом

концептуальной проработки модели. На данном этапе вводятся
основные абстракции, определяются классы и интерфейсы посредством
которых реализуется решение поставленных задач. Если прецеденты
только декларируют поведение системы, то на этапе разработки вида с
точки зрения проектирования определяется какими средствами данные
прецеденты будут реализованы. Статические аспекты данного вида
разрабатываются посредством диаграммы классов, динамические –
посредством диаграмм взаимодействий и состояний (автомат).

Диаграммы классов содержат классы, интерфейсы, кооперации, а

так же связи между ними. Начинать разработку диаграммы классов
следует с определения классов, соответствующих основным сущностям
системы, которые, как правило, определяются на начальных этапах
разработки при описании предметной области. Здесь следует решить
какие сущности удобнее смоделировать как классы, а какие как их
атрибуты. Например, если бы требовалась в рамках факультета указать
для каждой кафедры заведующего, лучше сущность заведующий
кафедры сделать атрибутом класса кафедра с указанием на класс
преподаватели (ассоциация «один к одному»), а не вводить отдельный
класс заведующий кафедры.
При моделировании необходимо помнить, что каждому классу
должна соответствовать некоторая реальная сущность или
концептуальная абстракция из области, с которой имеет дело
пользователь или разработчик. Хорошо структурированный класс
обладает следующими свойствами:
– является четко очерченной абстракцией некоторого понятия из
словаря проблемной области или области решения;
– содержит небольшой, точно определенный набор обязанностей и
выполняет каждую из них;
– поддерживает четкое разделение спецификаций абстракции и ее
реализации;
– понятен и прост, но в то же время допускает расширение и
 22

адаптацию к новым задачам.

В рамках разработки модели АРМ секретаря кафедры определим
классы: преподаватели, студенты, аспиранты, дисциплины, группы.
Очевидно, что первые из них имеют много общих атрибутов, поэтому
введем абстрактный класс персона, который будет инкапсулировать все
свойства, относящиеся к человеку в контексте разрабатываемой
системы (фамилия, имя, адрес и т.д.). В данном случае персона будет
суперклассом и связываться отношением обобщения с классами
преподаватели, студенты, аспиранты.
Атрибут адрес имеет собственную структуру, чтобы отразить ее
можно ввести дополнительный класс, назовем его T_ADR (как принято
во многих системах программирования названия классов начинать с
буквы T). Следует иметь ввиду что, атрибут адрес класса персона
является экземпляром класса T_ADR, то есть между этими классами
устанавливается отношение зависимости (отображается пунктирной
стрелкой с открытым наконечником, стрелка направлена от зависимого
элемента к независимому). В нашем случае изменение структуры класса
T_ADR влечет за собой изменение класса персона через структуру
соответствующего атрибута (адрес).
При моделировании класса T_ADR атрибут индекс зададим
посредством примитивного типа T_POSTIDX, определяемого как
шестизначное десятичное число. Примитивные типы моделируются
стереотипом «type», диапазон значений указывается через ограничения,
заключенные в фигурные скобки.
В классе преподаватель выделим специфические атрибуты,
относящиеся только к преподавателю: должность, уч. степень (ученая
степень), уч. звание (ученое звание), разряд (разряд единой тарифной
сетки). Атрибуты уч. степень и уч. звание лучше определить
специализированными типами через перечисление. Перечисления
моделируются классом со стереотипом «enum» (enumeration –
перечисление), допустимые значения записываются как атрибуты,
метки, определяющие видимость атрибутов при этом подавляются. В
рассматриваемом примере введем специализированные классы
T_Должн, Т_УчСт, Т_УчЗв, определяющие соответственно
возможные должности, ученые степени, ученые звания через
перечисления. В данном случае, как и везде в подобных случаях при
создании классов, специфицирующих атрибуты основного класса,
устанавливаются отношения зависимости.
Для класса студент вводится специфический атрибут номер
зачетки. Для класса аспирант определяются специфические атрибуты
форма обучения и дата поступления. Форма обучения определятся
специальным классом через перечисление Т_ФормОбуч (очная,
 23

заочная).
Класс группа имеет атрибуты: название, форма обучения, число
студ. (число студентов). Учитывая, что преподаватели рассматриваемой
кафедры могут вести занятия у групп с других факультетов, вводится
дополнительный класс специальность, с атрибутами номер
(специальности), название (специальности), факультет, типы которых
в данной модели не заданы, хотя могут определяться через
перечисления.
Класс дисциплина имеет атрибуты: номер, название, цикл.
Атрибут цикл посредством введенного через перечисление
специализированного типа Т_Циклы определяет к какому циклу
относится дисциплина: к циклу гуманитарных и социально-
экономических дисциплин, математических и естественнонаучных
дисциплин, общепрофессиональных дисциплин или специальных
дисциплин.
Атрибуты количество часов, количество семестров нельзя
указать в классе дисциплина, поскольку они зависят от специальности,
тем более нельзя указать их в классе специальность. Данные атрибуты
относятся к паре специальность-дисциплина и определяются в классе -
ассоциации Дисциплины-специальности.
При визуализации структуры классов следует обращать внимание
на видимость атрибутов. Все рассмотренные атрибуты должны быть
доступны и иметь видимость Public (обозначается знаком «+» или
пиктограммой без замка). В рассмотренных классах мы делали упор на
структуру, а не на поведение (операции не описывались и не
предполагается их описывать), поэтому для облегчения восприятия
диаграммы желательно изображение операций подавить.
На введенном множестве классов необходимо доопределить связи.
Связи обобщения и зависимости были уже определены, осталось
определить ассоциации.
Студенты формируются в группы, в данном случае ассоциация
будет иметь вид агрегации. Агрегация предполагает отношение типа
часть-целое, обозначается сплошной линией с ромбиком на конце со
стороны целого (в нашем случае группы). Множественность
отношения студенты-группы «многие к одному». Каждая группа
относится к определенной специальности, в свою очередь
определенной специальности может соответствовать несколько групп,
поэтому ассоциация группа-специальность также имеет тип
множественности «многие к одному».
В данном случае, как и в большинстве других, направление
ассоциаций двухстороннее, поэтому навигацию лучше подавлять (снять
галочку в поле Navigable опции Detail Role).
 24

Персона T_ADR
Фамиллия : String Индекс : T_POSTIDX
Имя : String Город : String <<type>>
Отчество : String Улица : String T_POSTIDX { 6-значное
Адрес : T_ADR Дом : String десятичное число }
<<enum>> Телефон : Integer Квартира : Integer
Т_Должн
ассистент
ст. преподаватель
доцент Студенты
Аспиранты
профессор Номер зачетки : String
Форма обучения : Т_ФормОбуч
Преподаватели 1 Дата поступления : Date
<<enum>> Должность : Т_Должн 1..n
0..n 0..n
T_УчСт Уч.степень : T_УчСт
0..n
к.т.н. Уч. звание : T_УчЗв +руководитель
к.ф.-м.н. Разряд : Integer
к.п.н. ставка : Double 1
д.т.н. 1..n 1..n Староста
д.ф.-м.н.
д.п.н Ведут занятия
1..n 1
1 0..n
<<enum>> Группа <<enum>>
T_УчЗв Название : String Т_ФормОбуч
доцент Форма обучения : Т_ФормОбуч
Очная
профессор Число студ : Integer
Заочная
1..n
1..n 1
<<enum>> Специальность
Т_ЦИКЛЫ Дисциплины
0..n Номер : Integer
Номер : Integer
гуманитарных и соц-эконом Название : String
Название : String 1..n
мат. и естеств.науч. 1..n Факультет
Курс : Integer
общепрофессиональн.
Цикл : Т_ЦИКЛЫ
специальные Дисциплины-Специальности
Кол-во часов
Кол-во семестров

Рис. 3. Диаграмма классов АРМ секретаря кафедры ( вариант 1)

 25

Определим ассоциацию между преподавателями и

преподаваемыми дисциплинами по типу «многие ко многим»:
преподаватель может вести несколько дисциплин, некоторые
дисциплины могут преподаваться несколькими преподавателями.
Между дисциплинами и специальностями также устанавливается
ассоциация «многие ко многим»: учебный план специальностей
содержит множество дисциплин, большинство дисциплин встречаются
в рабочих планах нескольких специальностей. К данной ассоциации
прикрепляется класс-ассоциация Дисциплины-специальности с
атрибутами, указывающими курс, количество семестров и количество
часов данной дисциплины у данной специальности.
Аналогично введем ассоциацию между группами и
преподавателями: преподаватели ведут занятия в группах, тип
множественности ассоциации «многие ко многим». Прямую
ассоциацию между группами и дисциплинами определять не нужно,
поскольку данная связь прослеживается через связующий класс
специальность.
Для того, чтобы отобразить наличие руководителя у аспиранта
необходимо ввести ассоциацию между аспирантом и преподавателем по
типу «многие к одному», у одного руководителя может быть несколько
аспирантов. На данной ассоциации со стороны преподавателя можно
явно указать роль: руководитель.
В каждой группе имеется староста группы, этот факт можно
отобразить дополнительной ассоциацией (дадим ей имя староста) от
группы к студентам с типом множественности «один к одному». В
данном случае можно явно указать навигацию.
Аспиранты также могут вести занятии по определенной
дисциплине у определенных групп: ассоциации «многие ко многим»
аспиранты-группы, аспиранты-дисциплины. Некоторые аспиранты
могут не вести занятия, поэтому тип множественности на концах
ассоциации будет 0..n.
Итоговая диаграмма классов приводится на рис. 3.
Учитывая, что и аспиранты и преподаватели ведут занятия можно
ввести дополнительный абстрактный класс, например, преподающие,
являющийся потомком класса персона и суперклассом для классов
преподаватель и аспирант, что позволит несколько сократить число
связей. (рис. 4.). В данном случае от классов дисциплина и группа
ассоциации будут идти к классу преподающие, предполагая связь с
классами преподаватель и аспирант через наследование (отношение
обобщения). В класс преподающие можно вынести атрибуты ставка
(0,5 ставки, полная ставка) и разряд.
 26

Персона T_ADR
Фамиллия : String Индекс : T_POSTIDX
Имя : String Город : String
Отчество : String Улица : String
<<type>>
Адрес : T_ADR Дом : String
Квартира : Integer T_POSTIDX { 6-значное
Телефон : Integer
десятичное число }
<<enum>>
Т_Должн
ассистент
ст. преподаватель
доцент Преподающие Аспиранты
профессор Форма обучения : Т_ФормОбуч
Ставка : float
Разряд : Integer Дата поступления : Date
1..n
<<enum>> 0..n
1..n
T_УчСт +руководитель Студенты
к.т.н. Преподаватели
к.ф.-м.н. 1 Номер зачетки : String
Должность : Т_Должн
к.п.н.
Уч.степень : T_УчСт 1
д.т.н.
д.ф.-м.н.
Уч. звание : T_УчЗв Ведут занятия
1..n
д.п.н
Староста
1..n <<enum>>
1 1 Т_ФормОбуч
Группа
Очная
<<enum>> Название : String
Заочная
T_УчЗв Форма обучения : Т_ФормОбуч
доцент 1..n Число студ : Integer 1
профессор Специальность
1..n
Дисциплины Номер : Integer
<<enum>> Название : String
Т_ЦИКЛЫ Номер : Integer 1..n
Факультет
Название : String 1..n
гуманитарных и соц-эконом
мат. и естеств.науч.
Цикл : Т_ЦИКЛЫ Дисциплины-Специальности
общепрофессиональн. Кол-во часов : Integer
специальные Кол-во семестров : Integer
Курс : Integer

Рис. 4. Диаграмма классов АРМ секретаря кафедры (вариант 2)

 27

Персона T_ADR
Фамиллия : String Индекс : T_POSTIDX
Имя : String Город : String
Отчество : String Улица : String
Адрес : T_ADR Дом : String
Телефон : Integer Квартира : Integer

Преподающие Аспиранты
Ставка : float Форма обучения : Т_ФормОбуч
Разряд : Integer Дата поступления : Date
1..n
0..n
1..n
+руководитель Студенты
Преподаватели
1 Номер зачетки : String
Должность : Т_Должн
Уч.степень : T_УчСт
1
Уч. звание : T_УчЗв Ведут занятия 1..n

Староста
1..n
1 1
Группа
Название : String
Форма обучения : Т_ФормОбуч
1..n Число студ : Integer
1
1..n Специальность
Дисциплины Номер : Integer
Номер : Integer Название : String
1..n Факультет
Название : String
1..n
Курс : Integer
Цикл : Т_ЦИКЛЫ Дисциплины-Специальности
Кол-во часов
Кол-во семестров

Рис. 5. Упрощенная диаграмма классов

Получившаяся диаграмма достаточно сложна и нагружена

элементами, однако моделирование классов еще далеко не
закончено: необходимо еще определить некоторые служебные
классы и интерфейсы. С целью разгрузить диаграмму классов
построим новый ее вид (на отдельной диаграмме) оставив
изображение основных классов и подавив отображения
вспомогательных, определяющих типы атрибутов (рис. 5).
На рис. 5 наряду с основными классами, соответствующими
концептуальным элементам системы показан также класс T_ADR,
раскрывающий структуру адреса, данный класс также имеет важное
значение, поскольку содержит необходимые элементы данных для
преподавателей и аспирантов – потомков класса персона.
Перейдем к определению интерфейсов. Классы
взаимодействуют с внешним миром через интерфейсы.
 28

Интерфейс (Interface) - это совокупность операций, которые

определяют сервис (набор услуг), предоставляемый классом или
компонентом. Таким образом, интерфейс описывает видимое извне
поведение элемента. Интерфейс может представлять поведение
класса или компонента полностью или частично; он определяет
только спецификации операций (сигнатуры), но никогда - их
реализации. Графически интерфейс изображается в виде круга, под
которым пишется его имя. Интерфейс редко существует сам по себе
- обычно он присоединяется к реализующему его классу или
компоненту. Интерфейс всегда предполагает наличие некоторого
«контракта» между стороной, которая декларирует выполнение
ряда операций и стороной, которая эти операции реализует.
Поместим на диаграмму класс электронная таблица, в
котором инкапсулированы все свойства и операции электронной
таблицы, позволяющей редактировать данные. Структуру данного
класса раскрывать ввиду большой сложности не будем. Так в
современных средствах разработки приложений разработчик
пользуется готовыми классами и шаблонами, наследуя их
возможности, например библиотека VCL (Delphi) содержит класс
TTable, инкапсулирующий возможности электронной таблицы.
Потомки класса электронная таблица являются конкретными
электронными таблицами, содержащие конкретные данные по
преподавателям, аспирантам, студентам, группам, дисциплинам и
специальностям. Делая соответствующие классы потомками класса
электронная таблица, мы декларируем для этих классов все
свойства и операции, присущие электронным таблицам
(регистрацию в системе, вставку, удаление, редактирование
данных, сортировку и т. д.).
Для класса электронная таблица, а соответственно и для всех
его потомков определим интерфейс редактирование, подразумевая
все возможные операции редактирования данных (вставку,
удаление, изменение данных). При этом предполагается, что в
классе электронная таблица данные возможности реализованы.
Использование специального класса электронная таблица и
наследование позволило избежать определения специальных
свойств и интерфейсов редактирования данных для каждой
электронной таблицы.
Определим интерфейсы поиск преподавателя, поиск
дисциплины, присоединив их к соответствующим классам
отношениями реализации. Состав операций данных интерфейсов
 29

раскрывать не будем (он достаточно тривиален), поэтому

интерфейсы отобразим в сокращенной форме (в виде кружочка).
Напомним, что отношение реализации, присоединенное к
интерфейсу в сокращенной форме, отображается простой сплошной
линией (как ассоциация).
Интерфейс поиск студента отобразим с указанием списка
операций через стереотипный класс, при этом отношение
реализации отображается пунктирной стрелкой с закрытым
наконечником.
Естественно предполагается, что введенные интерфейсы
реализуется средствами классов, к которым они присоединены
отношением реализации, то есть соответствующие классы содержат
операции и методы, реализующие заявленные интерфейсы. Для
облегчения восприятия данные механизмы не визуализируются.
Для управления правами доступа и авторизацией пользователя
введем класс менеджер доступа. Менеджер доступа имеет атрибут
закрытого типа доступа таблица паролей, который является
экземпляром класса КодирТабл (Кодированная таблица),
содержащей пароли (password) и входные имена (login)
пользователей-администраторов. Предполагается, что возможности
служебного класса КодирТабл не позволяют постороннему
пользователю считывать пароли пользователей. На данном этапе
проектирования мы просто декларируем такие возможности, не
останавливаясь на механизме их реализации, но предполагая что
таковые инкапсулированы в класс КодирТабл.
Класс менеджер доступа содержит открытые операции ввод
пароля и предоставление прав администратора, средствами
которых реализуется авторизация и управление правами доступа.
Укажем зависимость между интерфейсом редактирования
данных (редактирование) и менеджером доступа, предполагая, что
полные возможности по редактированию данных имеют только
пользователи с правами администратора.
Итоговая диаграмма приводится на рис. 6.
 30

Электронная таблица
Редактир
ование

Менеджер доступа Персона T_ADR

Таблица паролей : КодирТабл Фамиллия : String Индекс : T_POSTIDX
Имя : String Город : String
Ввод пароля() Отчество : String Улица : String
Предоставление прав администратора() Адрес : T_ADR Дом : String
Телефон : Integer Квартира : Integer

КодирТабл
Аспиранты
Login
Форма обучения : Т_ФормОбуч
Password
Преподающие Дата поступления : Date
Ставка : float 0..n
Разряд : Integer
1..n
1..n +руководитель
Студенты
Преподаватели 1 Номер зачетки : String
Должность : Т_Должн
Поиск Уч.степень : T_УчСт
1 <<Interface>>
преподавателя Уч. звание : T_УчЗв Ведут занятия 1..n
Поиск студента

1..n Староста
1 Поиск по фамилии()
1
Группа Поиск о оценкам()
Название : String
Форма обучения : Т_ФормОбуч
1..n Число студ : Integer 1
Специальность
Дисциплины 1..n
Номер : Integer
Номер : Integer
1..n Название : String
Название : String 1..n
Поиск дисциплины Факультет
Цикл : Т_ЦИКЛЫ
Дисциплины-Специальности
Кол-во часов : Integer
Кол-во семестров : Integer
Курс : Integer

Рис. 6. Итоговая диаграмма классов АРМ секретаря кафедры

 31

Итак, разработка объектно-ориентированной модели АРМ

секретаря кафедры средствами диаграммы классов UML на данном
этапе можно считать законченной. Естественно, возможны
возвращения к ней и пересмотр некоторых элементов в ходе
проектирования системы, при корректировке задач, при уточнении
отдельных деталей. Процесс проектирования информационных
систем является итеративным. Необходимо отметить, что
разработанная диаграмма классов содержит элементы явно или
скрыто реализующие все прецеденты использования диаграммы
прецедентов. Каждому прецеденту диаграммы прецедентов должен
соответствовать либо интерфейс, либо операция интерфейса
(реализация предполагается в соответствующих интерфейсу
классах), либо открытая операция класса, либо набор открытых
операций (в данном случае прецедент реализуется непосредственно
соответствующим классом или набором классов).

Рассмотрим процесс создания новой записи о студенте

средствами диаграммы последовательности.
Создание новой записи предполагает права администратора,
поэтому действующим лицом данного взаимодействия будет
администратор (админ). Данный элемент уже был введен на
диаграмме прецедентов, поэтому перетащим его на диаграмму
последовательности из браузера вида с точки зрения прецедентов.
Следует обратить внимание, что на диаграммах взаимодействия
фигурируют объекты, то есть конкретные экземпляры классов (имя
объекта всегда подчеркивается).
Ведем объекты: форма ввода, менеджер записей, запись о
студенте Петрове (как конкретный пример записи о студенте),
менеджер транзакций. Данный набор объектов является типовым
при модификации записи в таблице базы данных.
Форма ввода – элемент пользовательского интерфейса,
представляет собой типовую форму ввода данных о студенте
(фамилия, имя, отчество, адрес и т. д.). В нашем случае
представляет собой несколько доопределенную конкретную
реализацию стандартного интерфейса редактирование класса
электронная таблица. Поскольку специально интерфейс
редактирование данных о студенте нами не вводился на диаграмме
классов, поэтому явно указывать класс для объекта форма ввода
не будем.
 32

Менеджер записей – объект, обладающий стандартным

набором возможностей по управлению данными при работе с
электронной таблицей. Данный набор возможностей наследуется
классом студенты от класса электронная таблица. Для объекта
Менеджер записей явно указывается класс, экземпляром которого
он является – студенты.
Петров – конкретная запись о студенте Петрове, новый
элемент таблицы о студентах. Здесь явно укажем введенный класс
запись о студенте. Подобные объекты обычно существуют
временно для посылки соответствующей информации в базу
данных при транзакциях. После окончания транзакции данный
объект может быть уничтожен. Соответствующий записи объект
может быть создан вновь при необходимости редактирования
информации.
Менеджер транзакций – объект, обеспечивающий выполнение
законченной операции над базой данных, в данном случае создание
новой записи о студенте Петрове. На данный объект возлагается
выполнение также ряда системных функций, сопровождающих
трансакцию. Примером менеджеров трансакций являются,
например, BDE (используются для доступа из приложений Delphi к
базам данных Paradox, Dbase и др.), ADO (используется для доступа
к базам MS Access из различных приложений).
Диаграмма последовательности ввода новой записи о студенте
в АРМ секретаря кафедры представлена на рис. 7.
На диаграмме последовательности определим передачу
сообщений между объектами: создать новую запись
(транслируется от объекта к объекту до конца цепочки как
сообщение сохранить запись); открыть форму (к форме ввода);
ввести Ф.И.О., адрес.. (ввод данных по студенту), далее эти
данные транслируются сообщениями сохранить Ф.И.О., адрес.. .
От менеджера транзакций передается сообщение собрать
информацию о студенте, обеспечивающее обратную связь с базой
данных, и наконец рефлексивное сообщение менеджера
транзакций поименованное как сохранить запись в БД,
обеспечивает окончание транзакции.
 33

Форма Менеджер записей : Петров : Запись Менджер

: Админ
Ввода Студенты студента транзакций
1: Создать нов запись

2: Открыть форму

3: Вести Ф.И.О, адрес ...

4: Сохранить запись

5: Сохранить запись

6: Создать нов пустую запись

7: Сохранить Ф.И.О., адрес .. студента

8: Сохранить запись

9: Собрать информацию о студенте

10: Сохранить запись в БД

Рис. 7. Ввод данных о студенте. Диаграмма последовательности

При желании можно данное взаимодействие представить

диаграммой кооперации, иллюстрирующей прежде всего
структурный аспект взаимодействия (рис. 8). Данную диаграмму
можно построить из предыдущей в автоматическом режиме (в
Rational Rose нажатием клавиши F5).
При необходимости проект можно дополнить и другими
диаграммами взаимодействия, раскрывающими работу
прецедентов.
 34

Форма
Ввода
1: Создать нов запись
2: Открыть форму 5: Сохранить запись
3: Вести Ф.И.О, адрес ...
4: Сохранить запись

Менеджер записей :
Студенты

: Админ

6: Создать нов пустую запись

7: Сохранить Ф.И.О., адрес .. студента
Петров : Запись 8: Сохранить запись
студента 10: Сохранить запись в БД

9: Собрать информацию о студенте

Менджер
транзакций

Рис. 8. Ввод данных о студенте. Диаграмма кооперации

4.3. Разработка профиля реляционной базы данных

В том случае, если для реализации системы используется

объектно-ориентированная СУБД (ООСУБД), построенная в
предыдущем разделе диаграмма объектов является окончательной
моделью и прямым руководством к реализации информационной
системы. В том же случае, когда в качестве информационного ядра
информационной системы предполагается использовать
реляционную базу данных (РБД), необходимо разработать еще одну
диаграмму – диаграмму профиля реляционной базы данных.
UML-профиль для проекта базы данных является расширением
UML, сохраняющим метамодель UML без изменений. Профиль для
проекта баз данных добавляет стереотипы и тегированные
значения, присоединенные к этим стереотипам, но не изменяет
основную метамодель UML. Для визуализации проектируемых эле-
ментов базы данных и правил проектирования реляционных баз
данных в профиль (далее просто баз данных) добавлены
соответствующие пиктограммы.
 35

База данных описывается с помощью таблиц, столбцов и

связей. В профиле есть элементы, расширяющие базу данных,
например, триггеры, хранимые процедуры, ограничения, типы,
определенные пользователем (домены), представления и другие.
Профиль показывает, каким образом и где все эти элементы
использовать в модели.
На профиле баз данных UML определяются следующие
сущности:
Таблица (Table) — набор записей в базе данных по
определенному объекту, состоит из столбцов.
Столбец (Column) — компонент таблицы, содержащий один
из атрибутов таблицы (поле таблицы).
Первичный ключ (Primary key) — возможный ключ,
выбранный для идентификации строк таблицы.
Внешний ключ (Foreign key) — один или несколько столбцов
одной таблицы, являющиеся первичными ключами другой
таблицы.
Представление (View) — виртуальная таблица, которая ведет
себя с точки зрения пользователя точно также, как обычная
таблица, но не существует самостоятельно.
Хранимая процедура (Stored procedure) — независимая
процедурная функция, выполняемая на сервере.
Домены (Domains) — допустимый набор значений для
атрибута или столбца.
Кроме данных сущностей могут быть введены и некоторые
дополнительные сущности, отражающие специфические аспекты
модели БД.

На основе диаграммы классов модно создать профиль базы

данных (диаграмма реляционных таблиц системы). При этом
следует иметь ввиду, что объектно-ориентированная модель
системы и профиль баз данных далеко не одно и то же.
Реляционная модель не поддерживает наследования, имеет типы
данных, соответствующие используемой СУБД, для обеспечения
связей между таблицами используются специальные кодовые поля.
Подробно о преобразовании объектно-ориентированной
модели в реляционную можно прочитать в [3], мы остановимся на
основных моментах:
 36

1) основные классы, содержащие данные, предназначенные для

хранения, преобразуются в таблицы;
2) при наличии ассоциаций типа «один к одному» хотя бы с
одной стороны нужно добавить дополнительное кодовое поле, где
указать код (ключ) второй записи для обеспечения связи данных;
2) при наличии ассоциаций типа «один ко многим» со стороны
подчиненных записей (со стороны «многие») необходимо ввести
дополнительное поле, где указать код (ключ) записи, которой они
подчиняются (со стороны «один»);
3) при наличии ассоциаций типа «многие ко многим»
необходимо ввести дополнительную таблицу связей, содержащую
минимум два поля: код одного участника и код второго участника,
таким образом, ассоциация типа «многие ко многим» преобразуется
в две ассоциации типа «один ко многим» через таблицу связи;
4) при наличии класса-ассоциации, класс-ассоциация вводится
как таблица связи, имеющая дополнительные атрибуты.
4) при наличии обобщения необходимо дополнить исходную
таблицу полями, соответствующими атрибутам суперкласса (тогда
суперкласс не вводить как таблицу), или ввести таблицу
суперкласса (с полями соответствующими его атрибутам) а в
таблице, соответствующей исходному классу добавить поле,
соответствующее коду (ключу) записи суперкласса.
Если реляционная модель была построена на базе хорошо
продуманной объектно-ориентрованной модели, полученная
реляционная модель обычно не содержит аномалий обновления и
удаления информации и удовлетворяет условиям нормализации.
Однако полезно проверить полученную реляционную модель на
соответствие нормальным формам.
На рис. 9. приводится диаграмма профиля данных для
разрабатываемой информационной системы АРМ секретаря
кафедры.
 37

<<Table>>
<<Table>> ТСтудент
<<Table>> Т_Группа-Преп IDST : SMALLINT
Т_Преподающие ID_PREP : SMALLINT Фамилия : VARCHAR(25)
ID : SMALLINT НомерГруппы : VARCHAR(8) Имя : VARCHAR(25)
Фамилия : VARCHAR(25) 0..* Отчество : VARCHAR(25)
Имя : VARCHAR(25) <<PK>> PK_Т_Группа-Преп5() Индекс : INTEGER
Отчество : VARCHAR(25) Город : VARCHAR(20)
Индекс : INTEGER 1 1..* Улица : VARCHAR(25)
Город : VARCHAR(20) Дом : VARCHAR(6)
Улица : VARCHAR(25) Квартира : VARCHAR(6)
Дом : VARCHAR(6) Группа : VARCHAR(8)
Квартира : SMALLINT 1 1..*
<<PK>> PK_ТСтудент1()
<<PK>> PK_Т_Преподающие0() <<Table>> 1 <<Check>> PostIDX()
<<Check>> PostIDX() <<Table>> Т_Группа
ТДисциплины Название : VARCHAR(8) 1
1 1
1 Номер : SMALLINT Форма Обучения : SMALLINT
Название : VARCHAR(40) Число Студениов : SMALLINT
Цикл : SMALLINT Староста : SMALLINT Староста
1
<<PK>> PK_ТДисциплины6() 1 <<PK>> PK_Т_Группа2()

1..*
руководитель
<<Table>>
Т_Дисц иплины-специальности
Номер Дисциплины : SMALLINT
Номер Спецмалиности : SMALLINT
Курс : SMALLINT
Колмчество часов : SMALLINT
1 Количество семестров : SMALLINT
<<Table>>
ТПреподаватель <<PK>> PK_Т_Дисциплины-специальнос4()
1 1 1..*
ID_PREP : SMALLINT
Должность : SMALLINT 1
УчСтепень : SMALLINT <<Table>>
УчЗвание : SMALLINT Т_Аспиранты <<Table>>
ID_PREP : SMALLINT ТСпециальность
Форма Обучения : SMALLINT Номер : SMALLINT
Дата Поступления : DATE Название : VARCHAR(40)
ID_РУК : SMALLINT Факультет : SMALLINT

<<PK>> PK_ТСпециальность3()

Рис. 9. Диаграмма профиля БД АРМ секретаря кафедры

 38

В соответствии разработанной объектно-ориентированной

моделью определим таблицы на базе классов, соответствующих
основным концептуальным сущностям информационной системы.
Каждой соответствующей таблице дадим имя, начинающиеся на
букву «Т» и включающие имя соответствующего класса, например,
Т_Студент, Т_Дисциплина. Таблицы UML являются
стереотипными классами со стереотипом «Table», вид пиктограммы
может регулироваться опцией Stereotype Display.
Структура классов содержит классы с иерархическими связями
наследования: персона, студент, преподающий, преподаватель,
аспирант. В соответствии с рекомендациями разработки
реляционного профиля при наличии наследования базовых классов
необходимо либо транслировать все атрибуты предков в таблицы,
соответствующие листовым классам иерархии наследования; либо
вводить таблицы, соответствующие всем классам иерархии
наследования с обеспечением связей между таблицами от потомка
к предку. Мы изберем компромиссный вариант: класс персона в
отдельную таблицу преобразовывать не будем, соответствующие
атрибуты транслируем в таблицы, соответствующие классам
преподающий (Т_Преподающие) и студенты (Т_Студенты).
Таблицы T_Преподаватель и Т_Аспиранты будут содержать
столбцы соответствующие только специфическим атрибутам и по
полю ID_PREP связываться с таблицей Т_Преподающие,
содержащий всю основную информацию о преподавателях и
аспирантах. Такой подход позволяет сэкономить внешнюю память,
не прибегая к большому увеличению связей.
Для выполнения условия атомарности атрибутов, атрибуты
класса T_ADR непосредственно транслируем в таблицы
Т_Студенты и Т_Преподающий. Разбиение адреса на несколько
атрибутов позволяет расширить возможности поиска и сортировки
данных по адресу проживающих.
Таблица Т_Аспиранты имеет дополнительную связь к таблице
Т_Преподающие, определяющую руководителя аспиранта, в поле
руководитель находится только код руководителя (ID_PREP),
дополнительные атрибуты которого можно узнать по этому же коду
в таблице T_Преподаватель.
Для обеспечения связи по типу «один ко многим» между
студентами и группами в таблицу Т_Студенты для записи каждого
студента указывается код группы.
 39

Класс-ассоциация Дисциплины-специальности транслируется

в соответствующую таблицу связи Т_Дисциплины-
специальности, содержащую атрибуты для пар идентификаторов
соответствующей дисциплины и специальности: курс, количество
часов, количество семестров.
Чтобы реализовать связь по типу «многие ко многим» между
преподавателями и группами студентов вводится дополнительная
таблица связей Т_Группа-Преп, присоединенная связями типа
«один ко многим» соответственно к таблицам Т_Группа и
Т_Преподающие.
Веденные через перечисления специализированные типы в
реляционных таблицах кодируются типом SMALLINT (короткое
целое), соответствие между кодами и их значением (например, для
класса Т_Должн : 01 – ассистент, 02 – старший преподаватель, 03 –
доцент …) обеспечивается средствами интерфейса конечной
программы (например, с помощью элемента ListBox VCL).
Текстовые атрибуты типа String объектно-ориентированной
модели преобразуются в поля типа VARCHAR с указанием длины в
текстовых символах.
На этапе проектирования реляционного профиля баз данных в
проект могут быть введены существенные изменения: изменены
или введены новые атрибуты сущностей, пересмотрены связи, даже
определены новые сущности, преобразующиеся в классы.

Итак, мы рассмотрели базовые этапы разработки

информационной системы: разработку концепции, вида с точки
зрения прецедентов, вида с точки зрения проектирования,
реляционного профиля баз данных. Последующие этапы
непосредственно связаны с программированием в конкретной
системе программирования.
На этапах непосредственной разработки программы, используя
средства обратного проектирования можно возвращаться к
пересмотру и уточнению разработанной в UML модели. UML также
позволяет отразить завершающие этапы разработки средствами
диаграмм компонентов и размещения, что может в дальнейшем
облегчить установку и сопровождение программного продукта.
Используя UML, разработчик практически не зависит от
организации процесса программирования; он не привязан к какому-
либо конкретному циклу изготовления программного продукта.
Тем не менее, разработчиками UML рекомендуется применять
 40

процесс, который:
- управляется прецедентами использования;
- основан на архитектуре;
- является итеративным и инкрементным.
Управляемость прецедентами использования означает, что
прецеденты должны быть основным артефактом, на основании
которого устанавливается желаемое поведение системы,
проверяется и подтверждается правильность выбранной системной
архитектуры, производится тестирование и осуществляется
взаимодействие между участниками проекта.
Процесс называют основанным на архитектуре (Architecture-
centric), когда системная архитектура является решающим
фактором при разработке концепций, конструировании, управлении
и развитии создаваемой системы.
Итеративным (Iterative) называется процесс, который
предполагает управление потоком исполняемых версий системы.
Инкрементный (Incremental) процесс подразумевает постоянное
развитие системной архитектуры при выпуске новых версий,
причем каждая следующая версия усовершенствована в сравнении
с предыдущей. Процесс, являющийся одновременно итеративным и
инкрементным, называется управляемым рисками (Risk-driven),
поскольку при этом в каждой новой версии серьезное внимание
уделяется выявлению факторов, представляющих наибольший риск
для успешного завершения проекта, и сведению их до минимума.
Средства языка UML дают широкие возможности по
использованию управляемого прецедентами, основанного на
архитектуре, итеративного и инкрементного процесса разработки
программного обеспечения.
 41

5. ВОПРОСЫ РЕАЛИЗАЦИИ ИНФОРМАЦИОННОЙ

СИСТЕМЫ

Выбор конкретных средств реализации предлагается студенту

сделать самостоятельно, единственное требование при этом –
использование объектно-ориентированных средств
программирования.
Наиболее популярными средствами программирования на
сегодняшний день являются Delphi, C++ Builder, Java-Builder,
Visual Basic. Все они предоставляют пользователю развитые
возможности по разработке программных продуктов, содержат
мощные средства визуального программирования. При выполнении
специфических задач работы с текстами, создании WEB-
приложений, могут быть использованы специализированные
средства на основе языков PERL, PHP и др.
Разработанная на предыдущих этапах модель информационной
системы должна, естественно, лечь в основу данной программной
реализации. При этом возможны различные варианты распределения
трудозатрат между разработкой модели средствами моделирования и
разработкой конечной программы средствами разработки программного
обеспечения.
При первом подходе средствами моделирования досконально
прорабатываются модели всех модулей программной системы в
терминах используемого языка программирования и базовых библиотек
вплоть до структуры всех методов и операций, включая элементы
интерфейсов. Очевидно, данный подход применим только для совсем
небольших информационных систем, в противном случае построение
модель получается чрезмерно трудоемким. К тому же очевидно, что
разработка элементов интерфейса, процедур взаимодействия с
операционной системой легче выполняется средствами разработки
программ.
При втором подходе средствами моделирования разрабатывается
некий концептуальный скелет информационной системы, досконально
прорабатываются наиболее важные вопросы, обычно касающиеся
форматов данных и внешнего взаимодействия. Все второстепенные и
вспомогательные элементы разрабатываются средствами разработки
программных систем. Так, при данном подходе интерфейс UML-модели
может быть реализован отдельной экранной формой, содержащей набор
интерфейсных элементов: кнопки, выпадающие списки,
редактированные текстовые окна ввода, представляющие собой
экземпляры соответствующих классов VCL или Java-Beans. Класс
модели может быть реализован посредством целого модуля конечной
 42

программы.
Очевидно, что второй подход как наименее трудоемкий наиболее
привлекателен: с одной стороны мы имеем концептуальную UML-
модель информационной системы, с другой соответствующий ей
исходный код модулей разработанной системы на соответствующем
языке программирования. Однако, при этом связи между моделью и
программным кодом становятся менее жесткими и в крайнем случае
чисто умозрительными. К тому, же в ряде случаев желательно иметь
подробно проработанную модель некоторых модулей системы в
терминах конкретного языка программирования и базовых классов.
Выходом является использование средств обратного проектирования.
Средства обратного проектирования позволяют из исходного кода
программы на языке программирования построить UML-модель.
Средства обратного проектирования являются дополнительными
средствами систем моделирования и встраиваются в них. Кроме того,
сторонними фирмами выпускаются программы, обеспечивающие связь
между средствами UML-моделирования и популярными средствами
разработки программного обеспечения, так фирма Ensamble Systems
выпустила продукт Rose Delphi Link , предназначенная для обеспечения
двухсторонней связи при проектировании между системой
моделирования Rational Rose и популярной системной разработки
приложений Borland Delphi.
Применение средств обратного проектирования может вносить
существенные коррективы в общий цикл разработки информационной
системы. При программировании в Delphi есть особенность,
существенно отличающая разработку в Delphi от разработки в
других средах программирования: программирование
пользовательского интерфейса. Как правило, разработка большей
части программ начинается именно с проектирования интерфейса
пользователя, а при дальнейшем программировании – его
существенного изменения. Поэтому использовать стандартный
подход Rational Rose не совсем удобно. Для решения этой
проблемы компания Ensemble Systems предлагает следующую
методологию проектирования (рис. 10).
 43

В Rose В Delphi

1. Моделируется предметная область

3. Используется обратное
проектирование, элементы
объектной модели Delphi включатся
в базовую архитектуру (Logical
View). Обеспечивается полное
соответствие диаграммы классов
элементам интерфейса Delphi.
5. Разработка диаграммы
компонентов, участвующих в
системе.
2. Определяются требования к
интерфейсу, создается
прототип пользовательского
интерфейса
4. По объектной модели,
спроектированной в Rose,
генерируется код,
обеспечивающий полное
соответствие диаграмм Rose и
кода Delphi.

Рис. 10. Методология проектирования с использованием RDL

При этом реализуется основная идея обратного проектирования:

все изменения, сделанные на уровне программного кода в Delphi,
отображаются в объектной модели, построенной в Rose, и
наоборот, при изменении классов, методов и т.п. в объектной
модели Rose, соответственно, корректируется программный код.
Обратите внимание на пару стрелок, которые соединяют третий и
четвертый блок. Как раз эти стрелки и отображают процесс
обратного проектирования.
На рис. 11. в качестве иллюстрации приводится экранная форма
«Инструменты» (TForm2), реализованная визуальными средствами
Delphi. Данная форма реализует интерфейс управления таблицей
базы данных, содержащей информацию о номенклатуре
инструментов для системы «Электронная кладовая».
 44

Рис 11. Экранная форма «Инструмент»

Для реализации данной табличной формы использовались

следующие компоненты VCL: DBGrid и DBNavigator, которые с
помощью компонентов ADOConnection, ADOTable и DataSours
были подключены к созданной в MS Access базе данных. На рис. 12
приводится фрагмент модели (диаграмма классов),
соответствующий данному программному модулю, полученный
автоматически на базе исходного года посредством утилиты Rose
Delphi Link.
 45

TADOConnection TDBGrid TDBNavigator

(from Unresolved References) (from Unresolved References) (from Unresolved References)

+DBGrid1
+ADOConnection1
+DBNavigator1
TDataSource
(from Unresolved References)

+DataSource1
TLabel
+Label1 (from Unresolved References)
TForm2

Button1Click() +Button1
TButton
(from Unresolved References)

+Table2
+ADOTable1
TADOTable
(from Unresolved References)
TForm
(from Unresolved References)

Рис 12. Uml-модель формы «Инструмент»

Rose Delphi Link также позволяет в автоматическом режиме

построить диаграмму компонентов проекта, отражающую
структуру модулей проекта (рис. 13.).
<<program>>
Project1.dpr

<<Unit>> <<Unit>>
Unit1 Unit7

<<Unit>>
<<Unit>>
Unit5
Unit2
<<Unit>> <<Unit>>
Unit3 Unit4

Рис 13. Структура модулей проекта – диаграмма компонентов

Не стоит забывать, что процесс разработки программного

обеспечения является итеративным, то есть приходится
периодически возвращаться на предыдущие этапы и
 46

пересматривать модель, в этих условиях использование средств

обратного проектирования является эффективным инструментом.

6. ТЕМЫ КУРСОВЫХ РАБОТ

1. Записная книжка- дневник (для заметок).

2. Личный органайзер (телефоны, контакты, записи).
3. Личный телефонный справочник (разделение по категориям,
поиск по фамилии т т.д.).
4. Электронный календарь – органайзер. ( Включает средства
напоминания о встречах, запланированных делах и т.д. ).
5. Мой фотоальбом (фотографии по категориям, возможность
перемещения из одной категории в другую)
6. Справочная система фильмов на CD.
7. Справочная система музыка на CD.
8. Справочная система программное обеспечение на CD.
9. Справочная система «Мои компакт диски».
10. Справочная система «Моя библиотека». (Аудиокассеты, CD-
диски)
11. Справочная система «Моя фонотека».
12. Справочная система «Мои видеофильмы». (С учетом
кому отдал …)
13. Домашний бухгалтер. (Приход/ расход,
предупреждения…)
14. Домашняя кладовая.(Учет инструментов, деталей,
описания, материалы).
15. Маленькая организация. (Сведения об отделах,
сотрудниках, и т.п.)
16. «Погребок» (Реестр домашних заготовок).
17. «Моя коллекция» (Информационная система
коллекционера).
18. Программа проведения тестов. (Имеет два режима
«учитель»-подготовка теста, «ученик» - тестирование.)
19. Домашняя аптечка. (Система учета лекарств, срока
годности лекарств, вспомогательных мед.
принадлежностей.)
20. База рецептов кулинарных блюд, подбор рецепта по
блюдам, и продуктам.
 47

21. Расчет одномерных статистических характеристик

массива данных . (Расчет средних, оценок дисперсии,
асимметрии, эксцесса, вывод гистограммы).

Напомним, что полная тема курсовой работы должна включать

слова «Разработка информационной системы …» или «Разработка
информационно-справочной системы…», так, например, тема №11
полностью будет выглядеть как «Разработка информационно-
справочной системы «Моя фонотека».
Студентом могут быть предложены свои темы курсовых работ.

Библиографический список

1. Буч Г. Рамбо Дж., Джекобсон А. UML Руководство

пользователя: Пер. с англ.- М.: ДМК Пресс, 2001. - 423 с.: ил.
2. Ларман К. Применение UML 2.0 и шаблонов
проектирования,. 3-е издание. Пер. с англ.- Изд-во Вильямс,
2007. - 736с.: ил.
3. Мюллер Р.Дж. Базы данных и UML. Проектирование.
Пер. с англ.- Изд-во ЛОРИ, 2000. - 420с.: ил.
4. Рамбо Д., Блаха М. UML 2.0. Объектно-ориентированное
моделирование и разработка. – СПб.: Питер, 2007. - 545 с.: ил.
5. Розенберг Д., Скотт К. Применение объектного
моделирования с использованием UML и анализ прецедентов. –
М.: ДМК пресс, 2002. – 160 с.: ил.
6. Фаулер М., Скотт К. UML в кратком изложении.
Применение стандартного языка объектного моделирования.
Пер. с англ.- М. Мир, 1999. - 192с.: ил.
7. Червенчук И.В. Моделирование информационных систем
с помощью UML: Учебное пособие по курсу «Информационные
системы и процессы, моделирование и управление». – Омск:
Изд.-во ОГИС, 2006. – 48с.