Некоторые принципы проверки качества и полноты информационной модели (источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

⇐ ПредыдущаяСтр 2 из 6Следующая ⇒

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

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

Качество сущностей

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

Список проверочных вопросов для сущности:

· Отражает ли имя сущности суть данного объекта?

· Нет ли пересечения с другими сущностями?

· Имеются ли хотя бы два атрибута?

· Всего атрибутов не более восьми?

· Есть ли синонимы/омонимы данной сущности?

· Сущность определена полностью?

· Есть ли уникальный идентификатор?

· Имеется ли хотя бы одна связь?

· Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?

· Ведется ли история изменений?

· Имеет ли место соответствие принципам нормализации данных?

· Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?

· Не имеет ли сущность слишком общий смысл?

· Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

· Отсутствуют ли пересечения с другими подтипами?

· Имеет ли подтип какие-нибудь атрибуты и/или связи?

· Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

· Имеется ли исчерпывающий набор подтипов?

· Не является ли подтип примером вхождения сущности?

· Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

Следует выяснить, а действительно ли это атрибуты, то есть, описывают ли они тем или иным образом данную сущность.

Список проверочных вопросов для атрибута:

· Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?

· Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?

· Имеет ли атрибут только одно значение в каждый момент времени?

· Отсутствуют ли повторяющиеся значения (или группы)?

· Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

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

· Не может ли он быть пропущенной связью?

· Нет ли где-нибудь ссылки на атрибут как на " особенность проекта", которая при переходе на прикладной уровень должна исчезнуть?

· Есть ли необходимость в истории изменений?

· Зависит ли его значение только от данной сущности?

· Если значение атрибута является обязательным, всегда ли оно известно?

· Есть ли необходимость в создании домена для этого и ему подобных атрибутов?

· Зависит ли его значение только от какой-то части уникального идентификатора?

· Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

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

Список проверочных вопросов для связи:

· Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?

· Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

· Заданы ли степень связи и обязательность для каждой стороны?

· Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

· Не является ли она избыточной?

· Не изменяется ли она с течением времени?

· Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

· Все ли из них относятся к одной и той же сущности?

· Обычно дуги пересекают разветвляющиеся концы - что вы можете сказать о данном случае?

· Связь может покрываться только одной дугой. Так ли это?

· Все ли концы связей, покрываемые дугой, входят в уникальный идентификатор?

Функции системы

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

Рис. 15. Пример декомпозиции

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

Очевидно, что операция выбора и расчета скидок может быть также разбита на более мелкие операции, например, на расчет скидок за приверженность (клиент покупает товары в течение долгого времени) и на расчет скидок за количество покупаемого товара. Атомарные функции описываются подробно, например, с помощью DFD и STD. Очевидно, что такое описание функций не исключает и дополнительное словесное описание (например, комментарии).

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

Уточнение стратегии

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

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

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

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

⇐ Предыдущая 123 4 5 6 Следующая ⇒