В начало

ЛЕКЦИЯ

Моделирование предметной области (ПрО).

Анализ предметной области.  Синтез концептуальной модели предметной области

 

8.1. Инфологическое проектирование и семантическая модель

Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью предметной области. Стадии соответствуют также ранее упомянутые термины “инфологическое проектирование” и “инфологическая модель”.

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

 

На слайде 3 (Захман-1) представлена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее "обеспечения", а также их основные взаимосвязи, аналогичная схеме Захмана. Три столбца отражают три раздела обеспечения системы: информационный (ДАННЫЕ), функциональный (ФУНКЦИИ) и коммуникационный (СЕТЬ). Строки таблицы отражают шесть уровней представления системы: реальная среда приложений, концептуальная модель, логическая модель, физическая модель, детальная реализация процедур, представления пользователя. Полезность такой схемы состоит в том, что она помогает рассматривать задачи проекта в полном объеме, упорядочивать состав и структуру требований к системе, определять и фиксировать причинно-следственные связи.

Позднее появилось развитие этой "плоской" модели. На слайде 4 (Захман-2) представлена схема, включающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также "действующие лица" - люди и организационные структуры. В результате есть шесть разделов, которые содержат "ответы на вопросы": почему выполняются действия, когда выполняются и кто их выполняет, а также что делает система, как делает и где. При этом уровни представления (строки таблицы) остались те же, что и в предыдущем варианте. Такое расширение позволило рассматривать потребности в контексте информационных технологий, соединять предметы и действия с человеческим фактором и операционной динамикой процессов.

 

К инфологическим моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к инфологическому уровню описания предметной области можно отнести следующие компоненты (слайд 5): 

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

-       ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними);

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

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

-       формализованность, обеспечивающую возможность автоматизированной обработки и, в том числе, например, автоматический контроль непротиворечивости;

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

 

8.2. Анализ ПрО - Определение информационных потребностей пользователей

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

Пользовательские представления

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

Любое пользовательское представление определяет требования к приложению базы данных в части хранимых в ней данных и транзакций, выполняемых над данными (т.е. оно определяет, какие действия и над какими данными должен выполнять тот или иной пользователь). Требования пользовательского представ­ления могут относиться только к данному представлению или частично совпа­дать с требованиями других представлений. На слайде (Слайд 6) схематически изображена предметная область приложения базы данных с несколькими пользовательскими представлениями (обозначены цифрами 1-6). Обратите внимание, что требования некоторых пользовательских представлений (1-2, а также 4-6) частично перекрываются (это показано штриховкой), а требования пользовательского представления 3 являются индивидуальными.

Сбор и анализ требований пользователей

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

-       Изучение документации.

-       Собеседование (интервьюирование) – выделяют не структурированные и структурированные интервью.

-       Наблюдение за работой предприятия.

-       Проведение исследований (поиск аналогичных решений).Проведение анкетирования (вопросы могут быть в свободной и фиксированной форме).

 

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

•     Описание применяемых или вырабатываемых данных.

•     Подробные сведения о способах применения или выработки данных.

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

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

Сбор и анализ требований является предварительным этапом концептуального проектирования базы данных. Объем работы зависит от сути проблемы и действующих бизнес-правил пред­приятия. Слишком тщательный анализ легко может привести к параличу сверх-анализа, а слишком поверхностный - к пустой трате средств на проведение работ по реализации решения, которое окажется ошибочным в результате неполной формулировки проблемы. Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впослед­ствии потребуется преобразовать и представить в виде более четко сформулиро­ванных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся, например, технология структурного анализа и проектирования (Structured Analysis and Design – SAD), диаграммы массивов данных (Data Flow Diagrams – DFD) и графики "вход-процесс-выход" (Hierarchical Input Process Output – HIPO).

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

•    Централизованный подход.

•    Метод интеграции представлений.

•    Сочетание обоих подходов.

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

Метод интеграции представлении предусматривает оформление требований к каждому пользовательскому представлению в виде отдельного списка требова­ний. На этапе проектирования базы данных вначале создается модель данных для каждого пользовательского представления. Модель данных, соответствующая отдельному пользовательскому представлению, называется локальной моделью данных и состоит из схем и документации, которые формально описывают требования к конкретному пользовательскому представлению базы данных. Локальные модели данных затем объединяются на одном из последую­щих этапов проектирования базы данных для создания глобальной модели дан­ных, которая соответствует всем пользовательским требованиям к базе данных. На слайде 10  показана схема управления пользовательскими представлениями 1-3 с использованием метода интеграции представлений. Как правило, такой подход может рассматриваться как предпочтительный, если имеются существенные различия между пользовательскими представлениями и приложением базы данных, а приложение базы данных является достаточно сложным, чтобы имело смысл разделить работу по его созданию на отдельные направления.

 

8.3. Критерии оценки модели

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

 

Проверка концептуальной модели на адекватность (слайд 12)

-       Проверка модели на отсутствие избыточности

-       Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям

-       Обсуждение локальных концептуальных моделей с конечными пользователями.