Объектное представление (нисходящее проектирование)

Использование средств автоматизации проектирования (CASE-средств)

Основы концептуального проектирования.

Этап концептуального проектирования связан с описанием разнообразных информационных требований пользователей. Результатом этого этапа является высокоуровневое представление информационных требований, например такое, как диаграмма «сущность – связь». Главное, что здесь необходимо, это чтобы первоначальная информационная структура была хотя бы частично независимой от процесса обработки, что позволит обеспечить гибкость процесса проектирования. Подход к концептуальному проектированию обычно предполагает, что рассматривается представление одного пользователя, например, администратора, который понимает требования всех пользователей и объединяет эти требования в полный набор согласованных спецификаций. Альтернативным является подход, в котором требования отдельных пользователей сливаются в единое глобальное представление. При этом должны быть выявлены и ликвидированы противоречивые и избыточные данные. Если в окончательном варианте системы предусмотрено использование механизма подсхем, то результаты моделирования частных представлений могут быть использованы для проектирования подсхем, а результат интеграции частных представлений после соответствующей обработки может быть преобразован в схему. Концептуальное проектирование оперирует информацией, независимой от любой фактической реализации (т.е. от любой конкретной системы технического или программного обеспечения). Цель концептуального проектирования именно в том и состоит.

В ходе проектирования исследуется возможность преобразования модели в СУБД – зависимое представление.

При проектировании возможно использовать специальные пакеты программ – CASE-средства (Computer Aided System Engeneering). Суть автоматизации в том, что на достаточно простом языке описывается ПО, концептуальная схема, которая потом преобразуется в логическую схему конкретной СУБД. С помощью CASE-технологии

· быстрее создают и внедряют БД при меньших затратах;

· обеспечивают единый простой интерфейс;

· сокращают усилия по обслуживанию приложений;

· осуществляют контроль за взаимодействием и полнотой представления;

· проводят последовательную декомпозицию сложной задачи.

Основной недостаток пакетов CASE – упрощенный подход к концептуальному моделированию. Наиболее известный CASE-пакет – S-Designor (Orаcle Corp.).

.

Существуют два метода концептуального проектирования: объектное представление и моделирование сущностей.

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

1. Что понимается под объектами?

2. Каково контекстное содержание этих объектов?

3. Каковы описательные свойства каждого объекта?

4. Каковы идентификационные свойства каждого объекта?

5. Как связаны объекты?

Процесс проектирования проходит стадии: моделирование представлений и объединение представлений.

Моделирование представлений

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

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

· Обрабатываемая информация. Информация о существующих и будущих приложениях. Сюда включаются все предполагаемые виды обработки базы данных.

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

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

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

Чаще локальное представление соответствует отдельному внешнему приложению (функциональной задаче). Например, в системе приема заказов в качестве локальных представлений могли бы выступать такие функциональные задачи, как прием заказов, расчеты с клиентами, история заказа, новые изделия. Для каждого локального представления определяются объекты, требуемые для описания этого локального представления. Объект (сущность) – это то, о чем должна накапливаться информация. Объекты могут быть атомарными или составными. На этом шаге проектировщик встречается с двумя важными проблемами. Первая из них связана с распознаванием различных категорий сущности. Она разрешается с помощью концепции типа или роли. Например, на предприятии могут быть выделены сущности: ВОДИТЕЛЬ, СЕКРЕТАРЬ, ИНЖЕНЕР. Обобщение этих типов в родовую сущность СЛУЖАЩИЙ рассматривается на следующей стадии концептуального проектирования – стадии объединения представлений.

Вторая проблема заключается в том, что часто некоторая порция информации может быть представлена как атрибут, сущность или связь. Например, тот факт, что деталь входит в состав другой детали, может быть выражен сущностью СБОРНАЯ ЕДИНИЦА, связью ДЕТАЛЬ ВХОДИТ В или атрибутом СОСТАВНАЯ ЧАСТЬ. В таких случаях проектировщик должен пользоваться правилом, которое состоит в том, чтобы использовать ту конструкцию, которая кажется более естественной. Если конструкция выбрана не очень удачно, это обязательно выявится на последующих этапах проектирования. Другое соображение, которое необходимо отметить, касается выбора наименований сущности. Поскольку сущность представляет информационный факт, этому факту должно быть дано четкое наименование (название). Это является важным также и для стадии объединения представлений, где придется иметь дело с синонимами и омонимами. Если понятия будут иметь расплывчатые наименования, то процесс интеграции и объединения представлений будет также расплывчатым.

Объект в конкретный момент времени характеризуется его состоянием, которое описывается свойствами и связями с другими объектами. Свойства могут быть статическими (не зависят от связей с другими объектами, например, НАЗВАНИЕ КНИГИ) или динамическими (например, ДАТА ВЫДАЧИ КНИГИ ЧИТАТЕЛЮ). Необходимо определить все эти свойства и выявить те их них, которые можно использовать для однозначного распознавания отдельных экземпляров объекта.

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

Объединение представлений

Основная цель объединения представлений заключается в идентификации общих аспектов различных представлений, а также в обнаружении и разрешении их основных противоречий. Этот процесс включает анализ на:

· несогласованность наименований. Идентификация синонимов и омонимов среди элементов данных;

· несогласованность идентификации. Различная идентификация одних и тех же типов сущностей (например, служащие могут однозначно идентифицироваться номером страхового полиса в одном приложении и номером служащего в другом);

· несогласованность агрегации. Например, означает ли «суммарные закупки» суммарные для округа, страны и т.д.;

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

· противоречивость требований обновления. Обнаружение несогласованных правил добавления / исключения среди различных представлений пользователей;

· противоречивость ограничений целостности. Идентификация различий в правилах поддержания целостности данных. Например, каждый новый проект создает новый экземпляр сущности СЛУЖАЩИЙ, вызывая тем самым дублирование.

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

Дата добавления: 2014-01-07