Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 16)

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

Различные приемы используются и для того, чтобы уменьшить чис­ло пересечений линий на схеме. Так, в системе ProKit*WORKBENCH для этих целей допускается дублирование изображения объекта и размещение дубля рядом с тем объектом, с которым его надо связать. Чтобы показать, что это не новый объект, а дубликат уже изображен­ного в модели объекта, используется какое-либо условное обозначе­ние, например у соответствующих блоков, отражающих дубликат, отчеркивается уголок.

При ручном проектировании изобразить всю ER-модель в виде единой схемы обычно не представляется возможным. В этом случае можно порекомендовать следующий прием: изобразить и описать каж­дый объект самостоятельно, присвоить каждому объекту короткий код. Используя эти кодовые обозначения, для каждого объекта указать его связи с другими объектами в виде отдельных схем. При этом нужно не упускать из виду, что, несмотря на такую дефрагментацию при изображении, модель является единой и связанной.

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

2.3.4. Отсутствующие возможности

Некоторые возможности, имеющиеся в одних системах или мето­диках, отсутствуют в других. В этих случаях возможны различные варианты:

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

• ситуация просто не отображается в модели.

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

Так, в IDEF1X, как и в других широко известных CASE-системах, свойства объекта могут быть только единичные и всегда опреде­ленные (не условные). Если свойство может отсутствовать у каких-либо объектов, то надо выделять отдельные сущности, например СЛУЖАЩИЙ_ШТАТНЫЙ с атрибутом «Оклад» и ПОЧАСОВИК, не имеющий такого атрибута. Это приведет к необходимости выделения большого числа объектов и связей в ИЛМ, к снижению наглядности модели. Например, отдельные экземпляры объекта ЛИЧНОСТЬ могут иметь или не иметь ученое звание, ученую степень, год оконча­ния вуза и много других признаков. По каждому из этих признаков придется выделять подклассы (либо не фиксировать в модели, явля­ются ли эти свойства условными).

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

Кроме указанных сложностей при определении идентификатора агрегированной сущности могут возникнуть и проблемы при перехо­де от ИЛМ к даталогической модели.

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

Связь типа «арк», использованная в базовой модели и имеющая­ся в CASE Oracle, отсутствует в большинстве других рассматривае­мых в данном учебнике систем. Это делает неудобным отображение тех ситуаций, где следовало бы использовать эту возможность (чаще всего при этом приходится вводить лишнюю сущность).

Если методика построения модели не предполагает фиксацию класса принадлежности объекта в связи, то эта информация будет просто потеряна.

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

В некоторых CASE-системах имеет место ситуация, когда какая-то конструкция допускается в системе как промежуточная. Например, в IDEF1X и CASE Oracle связь М:М допускается как так называемое неспецифическое отношение. Его наличие разрешается на ранних стадиях разработки проекта, но в дальнейшем оно должно быть за­менено на специфическое отношение (т.е. отношение типа 1:М). Это достигается посредством введения в модель дополнительной третьей сущности и соединения с ней исходных сущностей связью типа 1:М (другими словами, одна связь М:М заменяется на две 1:М). Это яв­ляется недостатком подобных систем, так как, во-первых, не все це­левые СУБД требуют такого преобразования (некоторые системы поддерживают отношение М:М в явном виде) и, во-вторых, если та­кое преобразование все-таки потребуется, система автоматизации проектирования вполне могла бы выполнить его автоматически на этапе даталогического проектирования. Даже если выполняется руч­ное проектирование, то указанное преобразование должно выполнять­ся проектировщиком на стадии даталогического проектирования, а не при описании предметной области. Кроме того, при рассматривае­мом преобразовании на стадии инфологического проектирования в IDEF вводится новая категория сущностей - сущности пересечения, или ассоциативные сущности. Введение новых сущностей влечет за собой введение в ER-модель и дополнительных связей. Все это вмес­те взятое усложняет и без того нелегкую задачу инфологического про­ектирования.

В предметной области могут быть сущности, идентификаторы которых являются зависимыми от идентификатора какого-то другого объекта. Например, если участки на предприятии нумеруются в пределах цеха, то идентификатор участка будет составным, включа­ющим в себя код цеха и код участка. В инфологической модели мож­но ограничиться указанием этого составного идентификатора. Неко­торые методики построения ER-моделей (например, IDEF1X, ProKit*WORKBENCH) предусматривают введение особых видов сущностей и особых видов отношений для отображения подобных си­туаций. Так, в IDEF1X сущность, для идентификации которой надо рас­сматривать ее отношение с другими сущностями, называется зависи­мой от идентификатора сущностью, и для ее изображения исполь­зуется блок с закругленными углами (в отличие от сущности, не зависимой от идентификации, для обозначения которой используют­ся прямоугольники). Для связи объектов, один из которых нужен для полной идентификации другого, вводится понятие идентифицирую­щего отношения. Дня него также вводится свое условное обозначе­ние. В IDEF1X для идентифицирующего отношения используется сплошная линия, а для неидентифицирующего - пунктирная.

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

Если модель не использует в явном виде указание на способ иден­тификации объекта, то, как указывалось выше, эту ситуацию нужно отразить просто путем соответствующего использования идентифи­каторов. Так, например, если на предприятии участки нумеруются в пределах цеха, то в качестве идентификатора объекта ЦЕХ следует использовать «Код_цеха*Код_участка» (рис. 2.34). Следует обратить внимание на то, что прямоугольник, соответствующий зависимой по идентификации сущности, в этом случае на сектора не делится.

Рис. 2.34. Изображение зависимой по идентификации сущности

в случае отсутствия специальных обозначений

Как отмечалось выше, ИЛМ включает в свой состав много разно­образных компонентов. Методологии моделирования и конкретные системы различаются полнотой и широтой охвата характеристик, отражаемых при описании предметной области. Так, некоторые систе­мы предусматривают описание запросов (в частности, ключей поис­ка), количественных характеристик классов объектов и запросов, огра­ничений целостности и т.д., другие - нет. Указанные описания иногда бывают объединены с ER-моделью (например, в ProKit*WORKBENCH) или оформляются как отдельные самостоятельные компоненты.

2.3.5. Различия в классификации объектов и отношений между ними

Как отмечалось выше при рассмотрении принципов инфологического моделирования, понятия «объект», «свойство», «отношение» являются относительными. Так, в предложенной нами базовой инфологической модели выделяются разные виды объектов: простые, составные, агрегированные, обобщенные. В некоторых системах моде­лирования такой классификации объектов нет и вместо этого исполь­зуются разновидности отношений.

И тот, и другой подход имеет, право на существование. Принци­пиальной разницы, влекущей за собой какие-то серьезные послед­ствия, в сравниваемых подходах нет.

2.3.6. Терминологические различия

Кроме различия в изображении тех или иных сущностей, в тео­рии инфологического моделирования наблюдается расхождение в используемой терминологии. Например, в CASE Oracle родовой объект называется супертип (syper-type), а видовой - подтип (sub-type). Таких различий в терминологии можно привести много, но их фикса­ция не является сейчас нашей целью. Хотя обратить внимание на та­кие различия нужно, чтобы при использовании конкретной системы не возникло ошибочное понимание происходящего. Так, в некоторых CASE-системах (например, Design/IDEF, PowerDesigner и др.) исполь­зуется непривычная для теории проектирования БД трактовка поня­тия физического проектирования: под физическим проектированием в них понимается проектирование (описание) структуры БД для конк­ретной целевой СУБД.

2.3.7. Соглашения по именованию элементов ER-модели

При описании базовой модели мы использовали только имена классов объектов, идентификаторов и свойств объектов.

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

Многие методики требуют обязательного именования связей. Поскольку связи являются двусторонними, то наименование связи будет меняться в зависимости от того, с какой стороны ее рассматри­вать. Поэтому часто в модели предлагается указывать оба эти назва­ния (например, в системах CASE Oracle, ProKit*WORKBENCH). В Design/IDEF1X обязательно надо указывать имя связи от «родителя» к «ребенку», имя связи в обратном направлении также можно ука­зать, но это не является обязательным.

Для того чтобы было понятно, к какому из направлений связи ка­кое название относится, принимают определенные соглашения о том, как располагать эти названия на схемах. Например, сверху линии по­мещать название, относящееся к левой стороне связи, а под линией - к правой; или разделять эти имена наклонной чертой (первым поме­щается имя от «родителя» к «ребенку»).

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

Для CASE-средств важной является также связь вопросов имено­вания элементов ER-модели и соответствующих им элементов даталогической модели. Так как ER-модель описывает предметную об­ласть и используется всеми категориями пользователей для обеспе­чения ее однозначного понимания, то желательно, чтобы имена давались на естественном национальном языке. Но в дальнейшем ER-модель используется для генерации описания структуры БД, а конк­ретные СУБД имеют разные ограничения на задание имен элементов БД. Хорошим решением этой проблемы является наличие в CASE-средстве возможности автоматически преобразовывать имена, исполь­зованные в ER-модели, в соответствии с ограничениями целевой СУБД. К сожалению, далеко не все CASE-средства обладают такими возможностями. Некоторые CASE-средства позволяют при создании ER-модели каждому ее элементу давать несколько имен (одно - для использования в концептуальной модели, другое - в даталогической (или, как она называется во многих современных CASE-средствах, -физической) модели и др.). Это, конечно, лучше, чем полное отсут­ствие возможности использовать разные имена, но не вполне соот­ветствует сути подхода, заключающейся в том, что по исходному опи­санию могут генерироваться проекты для разных целевых систем, так как ограничения на допустимые имена в каждой из этих систем мо­гут быть разными.

К сожалению, многие CASE-средства не только не обеспечивают, но даже и не контролируют правильность задания имен в полученной схеме БД. Это надо иметь в виду при построении ER-модели. При использовании некоторых CASE-средств возникают проблемы с ис­пользованием русского языка.

2.3.8. Дополнительные характеристики CASE-средств

ER-модель является сердцевиной систем проектирования, но, ес­тественно, не единственным ее компонентом. Для CASE-систем^ кро­ме общей характеристики используемой в них методологии ER-моделирования, существенной как для автоматизированного, так и для ручного проектирования, необходимо учитывать и специфические критерии, связанные с реализацией функций автоматизированного проектирования.

Ниже перечислены некоторые характеристики, которые следует учитывать при сравнении CASE-систем:

• число и перечень поддерживаемых целевых СУБД (а если не ограничиваться только рассмотрением вопросов проектирования БД, как делается в этом учебнике, то не только СУБД, но и других инстру­ментальных средств);

• поддержка разных технологий организации БД (локальные, рас­пределенные);

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

• построение концептуальной (ER-модели) по описанию структу­ры существующей БД - ремоделирование (реверс-инжиниринг);

• поддерживаемые виды моделей (кроме концептуальной (ER-мо-дели));

• автоматизируемые функции проектирования и степень их авто­матизации;

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

• надежность работы;

• документирование проекта;

• открытость системы (возможность стыковки с другими средства­ми автоматизации проектирования);

• удобство графического редактора;

• количественные ограничения (общее число объектов, число уров­ней вложенности для обобщенного объекта и др.);

• возможность автоматически оценивать объем памяти для про­ектируемой БД;

• возможность автоматической генерации хранимых процедур, процедур ввода данных и т.п.;

• наличие средств для моделирования хранилищ данных;

• требования к ресурсам компьютера;

• операционная среда;

• стоимость системы.

При оценке автоматизированных систем проектирования необхо­димо сравнивать не только язык модели и алгоритмы проектирова­ния, но и саму реализацию: удобство интерфейса, степень автомати­зации проектных решений, удобство использования и полноту спра­вочной системы и другие характеристики именно программной реализации системы. Так, например, Help в Design/IDEF имеет мно­жество недостатков: помощь неконтекстная; если действие по созда­нию какого-либо объекта не закончено (открыто какое-то окно), то помощь вообще недоступна; подписи, поясняющие назначение кно­пок меню, высвечиваются только при нажатии на них; если кнопка является неактивной (т.е. ее использование невозможно в данной си­туации), то и узнать назначение этой кнопки нельзя; далеко не все термины, сокращения, обозначения можно найти в справке; практи­чески не представлены методические вопросы, нет рекомендаций по моделированию. В противоположность этому можно привести при­мер ERWin: система включает не только Help в привычном понима­нии, но и обширные методические материалы с большим количеством примеров.

Характеристики

Список файлов книги