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

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

диаграммы классов

диаграммы объектов;

диаграммы прецедентов;

диаграммы последовательностей;

диаграммы кооперации;

диаграммы состояний;

диаграммы действий (деятельности);

диаграммы компонентов;

диаграммы развертывания.

Концептуальная модель UML

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

На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими "фотографиями" экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.

На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.

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

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

Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.

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

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

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

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

Атрибут адрес имеет собственную структуру, чтобы отразить ее можно ввести дополнительный класс, назовем его T_ADR (как принято во многих системах программирования названия классов начинать с буквы T). Следует иметь ввиду что, атрибут адрес класса персона является экземпляром класса T_ADR, то есть между этими классами устанавливается отношение зависимости (отображается пунктирной стрелкой с открытым наконечником, стрелка направлена от зависимого элемента к независимому). В нашем случае изменение структуры класса T_ADR влечет за собой изменение класса персона через структуру соответствующего атрибута (адрес).

При моделировании класса T_ADR атрибут индекс зададим посредством примитивного типа T_POSTIDX, определяемого как шестизначное десятичное число. Примитивные типы моделируются стереотипом "type", диапазон значений указывается через ограничения, заключенные в фигурные скобки.

В классе преподаватель выделим специфические атрибуты, относящиеся только к преподавателю: должность, уч. степень (ученая степень), уч. звание (ученое звание), разряд (разряд единой тарифной сетки). Атрибуты уч. степень и уч. звание лучше определить специализированными типами через перечисление. Перечисления моделируются классом со стереотипом "enum" (enumeration - перечисление), допустимые значения записываются как атрибуты, метки, определяющие видимость атрибутов при этом подавляются. В рассматриваемом примере через перечисление введем специализированные классы T_Должн, Т_УчСт, Т_УчЗв, определяющие соответственно возможные должности, ученые степени, ученые звания через перечисления. В данном случае, как и везде в подобных случаях при создании классов, специфицирующих атрибуты основного класса, устанавливаются отношения зависимости.

Для класса студент вводится специфический атрибут номер зачетки. Для класса аспирант определяются специфические атрибуты форма обучения и дата поступления. Форма обучения определятся специальным классом через перечисление Т_ФормОбуч (очная, заочная).

Класс группа имеет атрибуты: название, форма обучения, число студ. (число студентов). Учитывая, что преподаватели рассматриваемой кафедры могут вести занятия у групп с других факультетов, вводится дополнительный класс специальность, с атрибутами номер (специальности), название (специальности), факультет, типы которых в данной модели не заданы, хотя могут определяться через перечисления.

Класс дисциплина имеет атрибуты: номер, название, цикл. Атрибут цикл посредством введенного через перечисление специализированного типа Т_Циклы определяет к какому циклу относится дисциплина: к циклу гуманитарных и социально-экономических дисциплин, математических и естественнонаучных дисциплин, общепрофессиональных дисциплин, специальных дисциплин.

Атрибуты количество часов, количество семестров нельзя указать в классе дисциплина, поскольку они зависят от специальности, тем более нельзя указать их в классе специальность. Данные атрибуты относятся к паре специальность-дисциплина и определяются в классе - ассоциации Дисциплины-специальности.

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

При визуализации структуры классов следует обращать внимание на видимость атрибутов. Все рассмотренные атрибуты должны быть доступны и иметь видимость Public (обозначается знаком "+" или пиктограммой без замка). В рассмотренных классах мы делали упор на структуру, а не на поведение (операции не описывались и не предполагается их описывать), поэтому для облегчения восприятия диаграммы желательно изображение операций подавить.

На введенном множестве классов необходимо доопределить связи. Связи обобщения и зависимости были уже определены, осталось определить ассоциации.

Студенты формируются в группы, в данном случае ассоциация будет иметь вид агрегации. Агрегация предполагает отношение типа часть-целое, обозначается сплошной линией с ромбиком на конце со стороны целого (в нашем случае группы). Множественность отношения студенты-группы "многие к одному". Каждая группа относится к определенной специальности, в свою очередь определенной специальности может соответствовать несколько групп, поэтому ассоциация группа-специальность также имеет тип множественности "многие к одному".

В данном случае, как и в большинстве других, направление ассоциаций двухстороннее, поэтому навигацию лучше подавлять (снять галочку в поле Navigable опции Detail Role)

Определим ассоциацию между преподавателями и преподаваемыми дисциплинами по типу "многие ко многим": преподаватель может вести несколько дисциплин, некоторые дисциплины могут преподаваться несколькими преподавателями. Между дисциплинами и специальностями также устанавливается ассоциация "многие ко многим": учебный план специальностей содержит множество дисциплин, большинство дисциплин встречаются в рабочих планах нескольких специальностей. К данной ассоциации прикрепляется класс-ассоциация Дисциплины-специальности с атрибутами, указывающими курс, количество семестров и количество часов данной дисциплины у данной специальности.

Аналогично введем ассоциацию между группами и преподавателями: преподаватели ведут занятия в группах, тип множественности ассоциации "многие ко многим". Прямую ассоциацию между группами и дисциплинами определять не нужно, поскольку данная связь прослеживается через связующий класс специальность.

Для того, чтобы отобразить наличие руководителя у аспиранта необходимо ввести ассоциацию между аспирантом и преподавателем по типу "многие к одному", у одного руководителя может быть несколько аспирантов. На данной ассоциации со стороны преподавателя можно явно указать роль: руководитель.

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

В каждой группе имеется староста группы, этот факт можно отобразить дополнительной ассоциацией (дадим ей имя староста) от группы к студентам с типом множественности "один к одному". В данном случае можно явно указать навигацию.

Аспиранты также могут вести занятии по определенной дисциплине у определенных групп: ассоциации "многие ко многим" аспиранты-группы, аспиранты-дисциплины. Некоторые аспиранты могут не вести занятия, поэтому тип множественности на концах ассоциации будет 0. n.

Итоговая диаграмма классов приводится на рис. 3.

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

Учитывая, что и аспиранты и преподаватели ведут занятия можно ввести дополнительный абстрактный класс, например, преподающие, являющийся потомком класса персона и суперклассом для классов преподаватель и аспирант, что позволит несколько сократить число связей. (рис. 4.). В данном случае от классов дисциплина и группа ассоциации будут идти к классу преподающие, предполагая связь с классами преподаватель и аспирант через наследование (отношение обобщения). В класс преподающие можно вынести атрибуты ставка (0,5 ставки, полная ставка) и разряд.

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

На рис. 5 наряду с основными классами, соответствующими концептуальным элементам системы показан также класс T_ADR, раскрывающий структуру адреса, данный класс также имеет важное значение, поскольку содержит необходимые элементы данных для преподавателей и аспирантов - потомков класса персона.

Перейдем к определению интерфейсов. Классы взаимодействуют с внешним миром через интерфейсы.

Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. Интерфейс всегда предполагает наличие некоторого "контракта" между стороной, которая декларирует выполнение ряда операций и стороной, которая эти операции реализует.

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

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

Использование специального класса электронная таблица и наследование позволило избежать определения специальных свойств и интерфейсов редактирования данных для каждой электронной таблицы.

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

Интерфейс поиск студента отобразим с указанием списка операций через стереотипный класс, при этом отношение реализации отображается пунктирной стрелкой с закрытым наконечником.

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

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

Класс менеджер доступа содержит открытые операции ввод пароля и предоставление прав администратора, средствами которых реализуется авторизация и управление правами доступа.

Укажем зависимость между интерфейсом редактирования данных (редактирование) и менеджером доступа, предполагая, что полные возможности по редактированию данных имеют только пользователи с правами администратора.

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

Итоговая диаграмма приводится на рис. 6.

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

Рассмотрим процесс создания новой записи о студенте средствами диаграммы последовательности.

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

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

Ведем объекты: форма ввода, менеджер записей, запись о студенте Петрове (как конкретный пример записи о студенте), менеджер транзакций. Данный набор объектов является типовым при модификации записи в таблице базы данных.

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

Менеджер записей - объект, обладающий стандартным набором возможностей по управлению данными при работе с электронной таблицей. Данный набор возможностей наследуется классом студенты от класса электронная таблица. Для объекта Менеджер записей явно указывается класс, экземпляром которого он является - студенты.

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

Менеджер транзакций - объект, обеспечивающий выполнение законченной операции над базой данных, в данном случае создание новой записи о студенте Петрове. На данный объект возлагается выполнение также ряда системных функций, сопровождающих трансакцию. Примером менеджеров трансакций являются, например, BDE (используются для доступа из приложений Delphi к базам данных Paradox, Dbase и др.), ADO (используется для доступа к базам MS Access из различных приложений).

Диаграмма последовательности ввода новой записи о студенте в АРМ секретаря кафедры представлена на рис. 7.

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

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

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

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

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

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