Пример спецификации классов

Обратимся к примеру системы «Запись на университетскиекурсы». Рассмотрим следующие дополнительные требования, изложенныев документе описания требований.

1. Выбор студентам учебных курсов может быть ограничен из-законфликтов расписания, а также за счет ограничения на количествостудентов, которое может быть набрано на текущий предлагаемыйкурс.

2. Предлагаемая студентом программа обучения вводится винтерактивную систему записи на курсы. Система проверяетпрограмму на непротиворечивость и сообщает о любых проблемах.

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

В первом утверждении упоминаются конфликты расписания, однако достоверно не известно, как следует моделировать эту проблему.

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

Вторая формулировка укрепляет нас во мнении о необходимостивведения класса StudyProgram. Можно видеть, что класс StudyProgramсочетает в себе ряд дисциплин, предлагаемых к изучению в текущиймомент. Поэтому класс StudyProgram также должен обладать атрибутамиyear и semester.

Ближайшее рассмотрение нечетких классов CompulsoryCourse иElectiveCourse приводит нас к выводу, что учебный курс являетсяобязательным или выборочным относительно определенной ученойстепени. Один и тот же курс может быть обязательным по отношению кодной степени, выборочным, что касается другой, и вообще недопустимым применительно к некоторым другим степеням. Раз так, тоCompulsoryCourse и ElectiveCourse не являются классами в полном смыслеслова.

На рисунке 1 представлена модель классов, соответствующаяпроведенным нами рассуждениям. Кроме того, на рисунке используютсясимволы (стереотипы (stereotype)) «PK» и «CK» для обозначенияпервичных ключей и потенциальных ключей, соответственно. Этоуникальные идентификаторы объектов для рассмотренных классов. Здесьже заданы типы данных для атрибутов.

Классы StudyProgram и CourseOffering не имеют покаидентифицирующих атрибутов. Они будут введены в эти классы послеустановления ассоциативных связей между классами.

Рисунок 1 - Модель классов

Выявление ассоциаций

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

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

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

Каждая тернарная ассоциация должна быть заменена циклом илибинарной ассоциацией. Тернарные ассоциации привносят риск неверногосемантического истолкования.

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

Спецификация ассоциаций

Спецификация ассоциаций подразумевает выполнение следующих действий:

1. Присваивание имен ассоциациям.

2. Присваивание имен ассоциативным ролям.

3. Установление кратности ассоциации.

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

Если два класса связаны только одним ассоциативным отношением,задавать имя ассоциации и ассоциативные ролевые имена между этимиклассами необязательно. CASE-средства могут внутренне различатькаждую ассоциацию через системные идентификационные имена.

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