Главная Теоретический материал Лабораторные работы Задачи Тесты Контакты

Узбекское Агентство
Связи и Информатизации



Ташкентский Университет Информационных Технологий


Кафедра
«Программное обеспечение информационных технологий»

Направления:

5521900Информатика и
информационные технологии,
5523500Защита информации,
5523600Электронная коммерция,
5811200Сервис (информационный сервис),
5811300Сервис (электронные и
компьютерные технологии),
5320200Информатика и
библиотековедение,
5140900Профессиональное образование
(по направлению
информатика и
информационные технологии).


Преподаватель дисциплины



Доцент
Чернев Дмитрий Алексеевич

Определение классов

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

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

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

Список возможных классов должен быть проанализирован с целью исключения из него «ненужных классов». Такими классами являются:

избыточные классы: если два или несколько классов выражают одинаковую информацию, следует сохранить только один из них;

нерелевантные классы - не имеющие прямого отношения к проблеме, они исключаются;

нечетко определённые классы;

свойства (атрибуты), некоторым существительным больше соответствуют не классы, а свойства (например, имя, возраст, вес, адрес и т.п..);

операции, некоторым  существительным  6ольше  соответствуют не классы, а имена операций, например, телефонный вызов;

роли: некоторые существительные определяют имена ролей и объектной модели, например, владелец, водитель, начальник, служащий (для класса «человек»);

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

Подготовка словаря данных, содержащего четкие и недвус­мысленные определения всех объектов, классов, свойств (ат­рибутов) и пр. Без такого словаря обсуждение проекта с коллегами по разработке и заказчиками системы не имеет смысла, так как каждый может по-своему интерпретировать обсуждаемые термины.

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

Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной поста­новке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов, встречающихся в указанном документе. Так обычно описываются: физическое положение («следует за», «является частью», «содержатся в»), направленное действие («приводит в движение), общение («разговаривает с»), принадлежность («имеет», «является частью») и т.п.

Затем следует убрать ненужные или неправильные зави­симости, используя следующие  критерии:

зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов;

нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены;

тренарные зависимости, большую часть зависимостей между тремя или большим числом классов можно разложить на несколько бинарных зависимостей;

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

Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:

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

имена ролей, их  нужно  добавить  там,  где  это  необходимо;

имя роли описывает роль, которую играет соответствующий класс в данной зависимости с точки зрения другого класса, участвующего в этой зависимости; если имя роли ясно из имени класса, его можно не указывать;

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

- кратность зависимостей, для них необходимо добавить обозначения; при этом следует помнить, что кратность зави­симостей может меняться;

неучтенные зависимости должны быть выявлены и добавлены в модель.

Уточнение свойств (атрибутов). Корректируются свойства классов, вводятся, в случае необходимости, новые.

Свойства, как правило, слабо влияют на структуру объектной модели. Не следует стремиться определить как можно больше свойств: большое количество свойств усложняет модель, затруд­няет понимание проблемы.

Необходимо вводить только те свойства, которые имеют отношение к проектируемой прикладной системе, опуская слу­чайные, малосущественные и производные свойства.

Наряду с атрибутами объектов необходимо ввести и свойства зависимостей между классами (связей между объектами).

При уточнении свойств руководствуются ниже перечисленными критериями.

Замена свойств на объекты. Если наличие некоторой сущности важнее, чем ее значение, то это объект, если же важнее значение, то это свойство.

Примеры. Начальник -  это объект. Зарплата - это свойство (ее значение весьма существенно). Город — всегда объект, хотя в некоторых случаях может показаться, что это свойство (например, город как часть адреса фирмы).

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

Квалификаторы. Если значения свойства зависит от конкрет­ного контекста, его следует сделать квалификатором.

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

Идентификаторы. Идентификаторы объектов связаны с их реализацией. На ранних стадиях проектирования их не следует рассматривать в качестве свойств.

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

Внутренние значения. Свойства, определяющие лишь внутренние состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.

Несущественные детали. Свойства, не влияющие на выпол­нение большей части операции, рекомендуется опустить.

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

Дальнейшее исследование и усовершенствование модели. Лишь в очень редких случаях построенная объектная модель сразу же оказывается корректной. Модель должна быть исследована и отлажена.

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

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

Признаки пропущенного объекта (класса):

— несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;

— несоответствие атрибутов к операции у класса; для исправления ошибки необходимо расщепить класс на несколько других классов так: чтобы атрибуты и операции и новых классов соответствовали друг другу;

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

— обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс.

Признаки ненужного (лишнего) класса:

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

Признаки пропущенных зависимостей:

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

Признаки ненужных (лишних) зависимостей:

— избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости;

— не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость.

Признаки неправильного размещения зависимостей:

-имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.

Признаки неправильного размещения атрибутов:

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


Назад


Главная Теоретический материал Лабораторные работы Тесты Контакты