Выявление и спецификация атрибутов классов



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

Выделение атрибутов осуществляется параллельно с выделениемклассов. Идентификация атрибутов – своего рода «побочный эффект»установления классов. Это не означает, что выявление атрибутов - простая задача. Напротив, это процесс, требующий значительных усилийи многократных итераций.

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

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

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

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

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)(рекурсивных ассоциаций, которые связывают объекты одного и того жекласса). При задании ролевых имен их следует выбирать с учетом того,что в проектной модели они станут атрибутами классов, расположенныхна противоположных концах ассоциативной связи.


Дата добавления: 2018-04-05; просмотров: 346; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!