Text
                    Л. Г. Гагарина, Д. В. Киселев,
Е. Л. Федотова
РАЗРАБОТКА И ЭКСПЛУАТАЦИЯ
АВТОМАТИЗИРОВАННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
Под редакцией профессора Л. Г. Гагариной
Допущено Министерством образования Российской Федерации
в качестве учебного пособия для студентов учреждений среднего
профессионального образования, обучающихся по группе
специальностей 2200 «Информатика и вычислительная техника»
Москва
ИД «ФОРУМ» - ИНФРА-М
2007

УДК 004(075.32) ББК 32.973я723 Г12 Издание выполнено в рамках реализации национального проекта «Образование» по инновационной образовательной программе «Современное профессиональное образование для российской инновационной системы в области электроники» Рецензенты: доктор техн, наук, профессор кафедры информатики и программного обеспечения вычислительных систем (МИЭТ) Е. М. Портнов', кандидат техн, наук, доцент кафедры информационных технологий (Институт искусства и информационных технологий) А. А. Петров Гагарина Л. Г., Киселев Д. В., Федотова Е. Л. Г12 Разработка и эксплуатация автоматизированных информационных систем: учеб, пособие / Под ред. проф. Л. Г. Гагариной. — М.: ИД «ФОРУМ»: ИНФРА-М, 2007. — 384 с.: ил. — (Профессиональное образование). ISBN 978-5-8199-0316-2 (ИД «ФОРУМ») ISBN 978-5-16-003008-1 (ИНФРА-М) Приведены основные понятия и определения процесса проектирования ав- томатизированных информационных систем на основе анализа предметной области; освещены вопросы разработки программно-информационного ядра АИС на основе систем управления базами данных. Рассмотрены системы ав- томатизированного проектирования АИС, средства автоматизированного про- ектирования структур баз данных, язык структурных запросов SQL, стандарт- ные системы доступа к базам данных. В качестве основополагающих факторов изучения автоматизированного проектирования СУБД приведены клиенты удаленного доступа и дано по- строение запросов к СУБД; разработка клиентского программного обеспече- ния; основные элементы клиентских программ. Изложены также особенности эксплуатации АИС, методы и средства сбора и передачи данных; обеспечение достоверности информации в процессе ее хранения и обработки; экспортиро- вание структур баз данных; восстановление информации в базах данных. Для студентов средних специальных учебных заведений, обучающихся по специальностям 2202 «Автоматизированные системы обработки информации и управления», 2203 «Программное обеспечение вычислительной техники и ав- томатизированных систем»; может быть использовано для самообразования в области информационных технологий. УДК 004(075.32) ББК 32.973я723 ISBN 978-5-8199-0316-2 (ИД «ФОРУМ») ISBN 978-5-16-003008-1 (ИНФРА-М) ©Л. Г. Гагарина, Д. В. Киселев, Е. Л. Федотова, 2007 © ИД «ФОРУМ», 2007
Предисловие В настоящее время в условиях развивающегося информаци- онного общества с учетом всеобщего применения и распростра- нения телекоммуникационных и информационных технологий и систем, а также в связи с реализацией национального проекта «Образование» появление учебного пособия, освещающего не- посредственно теоретические и практические вопросы разработ- ки и эксплуатации автоматизированных информационных сис- тем, более чем актуально. Кроме того, поскольку Интернет в нашей стране доступен в основном пользователям, проживающим в крупных городах, а информатизация общества невозможна без хорошо развитой коммуникационной инфраструктуры, наибольший спрос ожида- ет научно-техническую литературу прикладного характера, к ка- ковой и относится представленная книга. К тому же, системное изложение материала в соответствии с требованиями государст- венного стандарта профессионального образования и богатый иллюстративный материал, несомненно, придают изданию осо- бую ценность. Согласно «Концепции информатизации сферы образования Российской Федерации» и задачам реализации упомянутого выше национального проекта, одной из особенностей перспек- тивной системы образования в нашей стране является опережаю- щее образование, в рамках которого изучаются средства, методы и последние достижения в области информатизации, а также перспективы дальнейшего ее развития и практического исполь- зования. Анализ содержания представленного пособия позволяет утверждать, что его следует рассматривать не только как важное средство информационной поддержки учебного процесса, как эффективный педагогический инструмент, но и как необходи- мый инструментарий опережающего образования. В учебном пособии достаточно полно представлены все ас- пекты изучения автоматизированных информационных систем (АИС): основные термины и определения, классификация, тех- нология проектирования, методология описания предметной об-
4 Предисловие ласти и т. д. Отличие данного пособия от аналогичных изданий заключается в освещении основных дидактических единиц дис- циплины «Разработка и эксплуатация автоматизированных ин- формационных систем» с учетом базовой подготовки потенци- ального читателя — студента среднего профессионального учеб- ного заведения. Именно поэтому только на базе основных понятий и определений АИС возможно корректное освещение проблем разработки программно-информационного ядра указан- ных систем на основе систем управления базами данных (СУБД), выбора СУБД, разработки клиентского программного обеспече- ния и т. д. Весьма интересными и своевременными для будущих специалистов современного глобального общества являются гла- вы о выборе средств автоматизированного проектирования струк- тур баз данных и организация сбора, размещения, хранения, на- копления, преобразования и передачи данных в АИС. Материал пособия прошел апробацию в Московском инсти- туте электронной техники и используется в учебном процессе различных факультетов.
Глава 1 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ 1.1. Понятие и классификация автоматизированных информационных систем Автоматизированные информационные системы (АИС) от- носятся к классу сложных систем, как правило, не столько в связи с большой физической размерностью, сколько в связи с многозначностью структурных отношений между их компонен- тами [1]. В рамках системного анализа сложные системы изуча- ются посредством разбиения на элементы: предполагается, что сложная система есть целое, состоящее из взаимосвязанных час- тей, которые не могут быть определены априорно, а строятся или выбираются в процессе декомпозиции (физической или концептуальной) исходной системы [2]. Поэтому, прежде чем непосредственно перейти к изучению АИС, рассмотрим основ- ные понятия и подходы к классификации информационных сис- тем (ИС) вообще. В настоящее время нет единого определения ИС и нет еди- ной их классификации в связи с динамично протекающими про- цессами накопления знаний в области информационных техно- логий, поэтому приведем для сравнения наиболее существенные. Информационная система [3] — совокупность информацион- ных, экономико-математических методов и моделей, техниче- ских, программных, технологических средств и специалистов, предназначенная для сбора, хранения, обработки и выдачи ин- формации и принятия управленческих решений. Согласно [5] информационная система есть распространенное обозначение человеческого коллектива и процедур, а также раз-
Глава 1. Проектирование АИС работанного, построенного, используемого и обслуживаемого оборудования для сбора, обработки, сохранения, извлечения и отображения информации. Актуальной задачей в информационном плане на сегодняш- ний день для предприятий и корпораций всех организационных форм и видов собственности и в любой предметной области явля- ется обеспечение надежного управления всем объемом разнород- ных данных, которые порождаются, хранятся и используются в различных ИС, существующих на предприятии и связанных с ин- формационной поддержкой продукции (услуг) в течение ее жиз- ненного цикла. Разнообразие проблем, решаемых с помощью ИС, привело к появлению разнотипных систем, различающихся принципами построения и заложенными в них правилами обра- ботки информации. ИС можно классифицировать по различным признакам. В ос- нову нижеприведенной классификации [19] положен ряд сущест- венных признаков, определяющих функциональные возможности и особенности построения современных систем; также принима- лись во внимание объем решаемых задач, используемых техниче- ских средств, организации функционирования и т. д. (рис. 1.1). По типу хранимых данных ИС делятся на фактографические и документальные. Фактографические системы предназначены Рис. 1.1. Классификация информационных систем
1.1. Понятие и классификация АИС 7 для хранения и обработки структурированных данных в виде чи- сел и текстов. Над такими данными можно выполнять различ- ные операции. В документальных системах информация представлена в виде документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществля- ется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится. Основываясь на степени автоматизации информационных про- цессов в системе управления фирмой (организацией), ИС делят- ся на ручные, автоматические и автоматизированные. Ручные ИС характеризуются отсутствием современных тех- нических средств переработки информации и выполнением всех операций человеком. В автоматических ИС все операции по переработке инфор- мации выполняются без участия человека. Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, при- чем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соот- ветствует современному представлению понятий «информацион- ная система» и «автоматизированная система». Так, в ГОСТ 34.003—90 [4] приводится нижеследующее оп- ределение. Автоматизированная система (АС) — это система, состоящая из персонала и комплекса средств автоматизации его деятельно- сти, реализующая информационную технологию установленных функций. Комплекс средств автоматизации (КСА) — совокупность всех компонентов АС, за исключением персонала. Пользователь АС — лицо, участвующее в функционировании АС или использующее результаты ее функционирования. В зависимости от характера обработки данных АИС1 делятся на информационно-поисковые и информационно-решающие. 1 Здесь и далее на основании вышеприведенных объяснений и во избежание разночтений терминов «информационная система» и «авто- матизированная система» используется термин «автоматизированная информационная система, АИС».
8 Глава 1. Проектирование АИС Информационно-поисковые системы производят ввод, систе- матизацию, хранение, выдачу информации по запросу пользова- теля без сложных преобразований данных. Например, ИС биб- лиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр. Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие. Результирующая информация управляющих АИС непосредственно трансформиру- ется в принимаемые человеком решения. Для этих систем свойст- венны задачи расчетного характера и обработка больших объемов данных, например АИС планирования производства или заказов, бухгалтерского учета. Советующие АИС вырабатывают информа- цию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных (например, экспертные системы). В зависимости от сферы применения различают следующие классы АИС [5]. Системы организационного управления предназначены для ав- томатизации функций управленческого персонала как промыш- ленных предприятий, так и непромышленных объектов (гости- ниц, банков, магазинов и пр.). Основными функциями подоб- ных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное пла- нирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи. Системы управления технологическими процессами (ТП) слу- жат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (тем- пературы, давления, химического состава и т. п.), процедур кон- троля допустимости значений параметров и регулирования тех- нологических процессов. Системы автоматизированного проектирования (САПР) пред- назначены для автоматизации функций инженеров-проектиров- щиков, конструкторов, архитекторов, дизайнеров при создании новой техники, сооружений или технологий. Основными функ-
1.1. Понятие и классификация АИС 9 циями подобных систем являются: инженерные расчеты, созда- ние графической документации (чертежей, схем, планов), созда- ние проектной документации, моделирование проектируемых объектов. Интегрированные (корпоративные) АИС используются для ав- томатизации всех функций фирмы (корпорации) и охватывают весь цикл работ — от планирования деятельности до сбыта про- дукции. Они включают в себя ряд модулей (подсистем), работаю- щих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности. Анализ современного состояния рынка АИС показывает устойчивую тенденцию роста спроса на информационные систе- мы организационного управления. Причем продолжает расти спрос именно на интегрированные системы. Автоматизация от- дельной функции, например, бухгалтерского учета или сбыта го- товой продукции, считается уже пройденным этапом для многих предприятий [7]. В табл. 1.1 приведен перечень наиболее популярных в на- стоящее время программных продуктов для реализации АИС ор- ганизационного управления различных классов. Таблица 1.1. Позиционирование на рынке АИС Локальные Малые интегрированные Средние интегрированные Крупные интегрированные Супер-Менеджер Инотек Инфософт БЭСТ Турбо-Бухгалтер Инфо-Бухгалтер Concorde XAL Exact NS-2000 Platinum PRO/MIS Scala SunSystems БЭСТ-ПРО 1С-Предприятие БОСС-Корпорация Галактика Парус Ресурс Эталон Microsoft-Business Solutions-Navision Microsoft-Business Solutions Axapta. MFG-Pro (QAD/BMS) SyteLine (СОКАП/SYMIX) SAP/R3 (SAP AG) Baan(Baan) BPCS (ITS/SSA) Oracle Applications (Oracle) В интегрированных АИС выделяют функциональные и обес- печивающие подсистемы. Функциональные подсистемы инфор- мационно обслуживают определенные виды деятельности, ха- рактерные для структурных подразделений предприятия или функций управления. Интеграция функциональных подсистем
10 Глава 1. Проектирование АИС в единую систему достигается за счет создания и функциониро- вания обеспечивающих подсистем. Функциональная подсистема представляет собой комплекс за- дач с высокой степенью информационных обменов (связей) ме- жду задачами. При этом под задачей понимается некоторый процесс обработки информации с четко определенным множест- вом входной и выходной информации. Состав функциональных подсистем определяется характером и особенностями автомати- зируемой деятельности, отраслевой принадлежностью, формой собственности, размером предприятия. Деление АИС на функ- циональные подсистемы может строиться по различным прин- ципам: • предметному; • функциональному; • проблемному; • смешанному (предметно-функциональному). При использовании предметного принципа [5] выделяют под- системы, отвечающие за управление отдельными ресурсами: управление сбытом, управление производством, управление фи- нансами, управление персоналом и т. д. При этом в подсистемах рассматривается решение задач на всех уровнях управления, обеспечивая интеграцию информационных потоков по вертика- ли (табл. 1.2). Таблица 1.2. Функциональные подсистемы, выделенные по предметному принципу Уровни управления Функциональные подсистемы Сбыт Производство Снабжение Финансы Стратегиче- ский уровень Новые продукты и услуги. Исследования и разработки Производственные мощности. Выбор технологий технологии Материальные ис- точники. Товарный прогноз Финансовые ис- точники. Выбор модели уплаты налогов Тактический уровень Анализ и плани- рование объ- емов сбыта Анализ и планирова- ние производствен- ных программ Анализ и планиро- вание объемов за- купок Анализ и плани- рование денеж- ных потоков Оперативный уровень Обработка зака- зов клиентов. Выписка счетов и накладных Обработка производ- ственных заказов Складские операции. Заказы на закупку Ведение бухгал- терских книг
1.1. Понятие и классификация АИС 11 Применение функционального принципа [5] предполагает вы- деление подсистем по направлениям деятельности: технико-эко- номическое планирование, бухгалтерский учет, анализ хозяйст- венной деятельности, перспективное развитие (рис. 1.2). Рис. 1.2. Структура функциональных подсистем АИС согласно функциональному принципу Состав обеспечивающих подсистем не зависит от конкретных функциональных подсистем и предметной области и рассматри- вается в п. 1.2. Рассмотренная классификация АИС с указанными выше классификационными признаками не является единственной. Приведем пример классификации, где в качестве основного клас- сификационного признака рассматриваются особенности авто- матизируемой профессиональной деятельности — процесса пере- работки входной информации для получения требуемой выход- ной [9]. В соответствии с названиями приведенных на рис. 1.3 систем (аббревиатуры общеприняты среди специалистов по информа-
12 Глава 1. Проектирование АИС Рис. 1.3. Классификация АИС с учетом особенностей автоматизируемой профес- сиональной деятельности: АСУ — автоматизированные системы управления (П — персоналом, ТС — тех- ническими средствами); СППР — системы поддержки принятия решения (Р — руководителя, О — должностного лица органа управления, Д — оперативного де- журного, Оп — оператора); АИВС — автоматизированные информационно-вы- числительные системы; ИРС — информационно-расчетная система; САПР — система автоматизированного проектирования; МЦ — моделирующий центр; ПОИС — проблемно-ориентированная имитационная система; АИИС — авто- матизированные информационно-справочные системы; АА — автоматизирован- ные архивы; АСД — автоматизированные системы делопроизводства; АС — ав- томатизированные справочники и АК — автоматизированные картотеки; АСВЭК — автоматизированные системы ведения электронных карт; АСО — ав- томатизированные системы обучения; АСОДИ — автоматизированные системы обеспечения деловых игр; Т и ТК — тренажеры и тренажерные комплексы ционным технологиям и системам) нетрудно определить назна- чение и особенности каждой из них. 1.2. Обеспечение АИС Различают девять обеспечивающих подсистем или так назы- ваемое обеспечение АИС, в частности [4]: • информационное; • лингвистическое; * математическое; • методическое; • организационное;
J.2. Обеспечение АИС 13 • правовое; • программное; • техническое; • эргономическое. Ниже приведены тестированные определения каждого вида обеспечения, его компоненты и особенности. Информационное обеспечение — совокупность форм докумен- тов, классификаторов, нормативной базы и реализованных ре- шений по объемам, размещению и формам существования ин- формации, применяемой в АИС при ее функционировании [4]. Информационное обеспечение включает: • описание технологических процессов; • описание организации информационной базы; • описание входных потоков; • описание выходных сообщений; • описание систем классификации и кодирования; • формы документов; • описание структуры массивов. Системы классификации [10] позволяют группировать объ- екты, выделяя определенные классы, которые характеризуются рядом общих свойств. Классификаторы представляют собой сис- тематизированные своды, перечни классифицируемых объектов и имеют определенное (обычно числовое) обозначение. Приме- няются государственные, отраслевые, региональные классифи- каторы. Например, классифицированы отрасли промышленно- сти, оборудование, профессии, единицы измерения, статьи за- трат и т. д. Назначение классификаторов: • систематизация наименований кодируемых объектов; • однозначная интерпретация одних и тех же объектов в раз- личных задачах; • возможность обобщения информации по заданной сово- купности признаков; • возможность сопоставления одних и тех же показателей, содержащихся в формах статистической отчетности; • возможность поиска и обмена информацией между под- системами и внешними АИС; • оптимизация использования ресурсов вычислительной тех- ники при работе с кодируемой информацией.
14 Глава 1. Проектирование АИС Используются три метода классификации объектов, которые различаются стратегией применения классификационных при- знаков: • иерархический; • фасетный; • дескрипторный. Иерархический метод реализует достаточно жесткую процеду- ру построения структуры классификации. Предварительно опре- деляется цель — набор свойств, которыми должны обладать классифицируемые объекты. Эти свойства полагают признаками классификации. В иерархической системе классификации каж- дый объект на любом уровне должен быть отнесен к одному классу, характеризуемому конкретным значением выбранного классификационного признака. Количество уровней классифи- кации, соответствующее числу признаков, выбранных в качестве основания деления, характеризует глубину классификации. Достоинства иерархической системы классификации: про- стота построения и использование независимых классификаци- онных признаков в различных ветвях иерархической структуры. Недостатками этой системы являются жесткая структура, ос- ложняющая внесение изменений, так как это приводит к пере- распределению классификатора, и невозможность группировать объекты по заранее не предусмотренным сочетаниям признаков. При использовании фасетного метода классификации до- пустимо выбирать признаки классификации независимо как друг от друга, так и от семантического содержания классифици- руемого объекта. Признаки классификации называются фасета- ми (facet — рамка). Каждый фасет содержит совокупность одно- родных значений данного классификационного признака, при- чем значения в фасете могут располагаться в произвольном порядке, хотя предпочтительнее их упорядочение. Схема по- строения фасетной системы классификации представляется в виде таблицы. Названия столбцов соответствуют выделенным классификационным признакам (фасетам). В каждой клетке таб- лицы хранится конкретное значение фасета. Процедура класси- фикации состоит в присвоении каждому объекту соответствую- щих значений из фасетов [10]. Достоинства фасетной системы классификации: возмож- ность создания большой емкости классификации, т. е. использо- вания большого числа признаков классификации и их значений для создания группировок; возможность простой модификации
1.2. Обеспечение АИС 15 всей системы классификации без изменения структуры сущест- вующих группировок. Недостатком системы является сложность ее построения, так как необходимо учитывать все многообразие классификацион- ных признаков. Для организации поиска информации, для ведения тезауру- сов (словарей) эффективно используется дескрипторная (описа- тельная) система классификации, язык которой приближается к естественному языку описания информационных объектов. Осо- бенно широко она используется в библиотечной системе поиска. Системы классификации принципиально отличаются от сис- тем кодирования в соответствии с определением. Система кодирования — совокупность правил кодового обо- значения объектов. Код строится на базе алфавита, состоящего из букв, цифр и других символов. Код характеризуется: дли- ной — число позиций в коде, и структурой — порядок располо- жения в коде символов, используемых для обозначения класси- фикационного признака. Кодирование применяется для замены названия объекта на условное обозначение (код) в целях обеспечения удобной и бо- лее эффективной обработки информации. Унифицированные системы документации создаются на госу- дарственном, отраслевом и региональном уровнях. Главная цель их использования — обеспечение сопоставимости показателей различных сфер общественного производства. Разработаны стан- дарты, где устанавливаются требования к: • унифицированным системам документации; • унифицированным формам документов различных уровней управления; • составу и структуре реквизитов и показателей; • порядку внедрения, ведения и регистрации унифицирован- ных форм документов. Однако, несмотря на существование унифицированной сис- темы документации, при обследовании большинства организа- ций постоянно выявляют типичные недостатки: • чрезвычайно большой объем документов для ручной обра- ботки; • одни и те же показатели часто дублируются в разных доку- ментах; • работа с большим количеством документов отвлекает спе- циалистов от решения непосредственных задач;
16 Глава 1. Проектирование АИС • наличие показателей, которые создаются, но не использу- ются, и др. Устранение указанных недостатков является одной из задач, стоящих при создании информационного обеспечения. Схемы информационных потоков отражают маршруты движе- ния информации, ее объемы, места возникновения и использо- вания. Анализ таких схем позволяет выработать меры по совер- шенствованию всей системы управления. Для создания информационного обеспечения необходимо: • ясное понимание целей, задач, функций всей системы управления организацией; • выявление движения информации от момента возникнове- ния и до ее использования на различных уровнях управле- ния, представленной для анализа в виде схем информаци- онных потоков; • совершенствование системы документооборота; • наличие и использование системы классификации и коди- рования; • владение методологией создания концептуальных информа- ционно-логических моделей, отражающих взаимосвязь ин- формации; • создание массивов информации на машинных носителях, что требует наличия современного технического обеспе- чения. Лингвистическое обеспечение — совокупность средств и правил для формализации естественного языка, используемых при обще- нии пользователей и эксплуатационного персонала АИС с ком- плексом средств автоматизации при функционировании АИС [4]. Языковые средства лингвистического обеспечения делятся на две группы: традиционные языки (естественные, математиче- ские, алгоритмические, моделирования) и языки, предназначен- ные для диалога с ЭВМ. Математическое обеспечение — совокупность математических методов, моделей и алгоритмов, применяемых в АИС [4]. В состав математического обеспечения входят: • средства математического обеспечения (средства моделиро- вания типовых задач управления, методы многокритери- альной оптимизации, математической статистики, теории массового обслуживания и др.); • техническая документация (описание задач, алгоритмы ре- шения задач, экономико-математические модели);
1.2. Обеспечение АИС 17 • методы выбора математического обеспечения (методы определения типов задач, методы оценки вычислительной сложности алгоритмов, методы оценки достоверности ре- зультатов). Методическое обеспечение — совокупность документов, описы- вающих технологию функционирования АИС, методы выбора и применения пользователями технологических приемов для получе- ния конкретных результатов при функционировании АИС [4]. Организационное обеспечение — совокупность документов, устанавливающих организационную структуру, права и обязан- ности пользователей и эксплуатационного персонала АИС в ус- ловиях функционирования, проверки и обеспечения работоспо- собности АИС [4]. Организационное обеспечение реализует следующие функ- ции: • анализ существующей системы управления предприятием (организацией), где используется АИС, выявление задач, подлежащих автоматизации; • подготовку задач к автоматизации, включая разработку тех- нических заданий и технико-экономических обоснований эффективности; • разработку управленческих решений по изменению струк- туры организации и методологий решения задач, направ- ленных на повышение эффективности системы управления. Организационное обеспечение включает: • методические материалы, регламентирующие процесс со- здания и функционирования АИС; • совокупность средств для эффективного проектирования и функционирования АИС; • техническую документацию, получаемую в процессе обсле- дования предприятия, проектирования, внедрения и со- провождения системы; • персонал (организационно-штатные структуры предпри- ятия), проектирующий, внедряющий, сопровождающий и использующий ИС. Правовое обеспечение — совокупность правовых норм, регла- ментирующих правовые отношения при функционировании АИС и юридический статус результатов ее функционирования. Примечание: правовое обеспечение реализуется в организа- ционном обеспечении АИС [4].
18 Глава 1. Проектирование АИС В состав правового обеспечения входят законы, указы, по- становления государственных органов власти; приказы, инструк- ции и другие нормативные документы министерств, ведомств, организаций, местных органов власти. В правовом обеспечении можно выделить общую часть, регулирующую функционирова- ние любой ИС, и локальную часть, регулирующую функциони- рование конкретной системы. Правовое обеспечение разработки АИС включает норматив- ные акты, связанные с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора. Правовое обеспечение функционирования АИС включает: • статус АИС; • права, обязанности и ответственность персонала; • правовые положения отдельных видов процесса управле- ния; • порядок создания и использования информации. Программное обеспечение — совокупность программ на но- сителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АИС [4]. К программному обеспечению АИС относят: • программное обеспечение, специально разработанное в рамках автоматизации, реализующее разработанные моде- ли разной степени адекватности, отражающие функциони- рование реального объекта; • программное обеспечение общего назначения, предназна- ченное для решения типовых задач обработки информации. Техническая документация на разработку программных средств должна содержать описание задач, задание на алгорит- мизацию, экономико-математическую модель задачи, контроль- ные примеры. Техническое обеспечение — совокупность всех технических средств, используемых при функционировании АИС [4]. К техническим средствам относят: • используемую вычислительную технику разного назначе- ния (серверы, рабочие станции); • специальные устройства сбора, накопления, обработки, пе- редачи и вывода информации; • устройства передачи данных и линии связи; • устройства автоматического съема информации; • оргтехнику, эксплуатационные материалы и т. д.
1.3. Архитектура АИС 19 Выбор технических средств, организация их эксплуатации, технологический процесс обработки данных, технологическое оснащение документально оформляются. Документацию технического обеспечения можно условно разделить на группы: • общесистемная документация, включающая государствен- ные и отраслевые стандарты по техническому обеспече- нию; • специализированная документация, содержащая комплекс методик по всем этапам разработки технического обеспе- чения; • нормативно-справочная документация, используемая при выполнении расчетов по техническому обеспечению. Эргономическое обеспечение — совокупность реализованных решений в АИС по согласованию психологических, психофи- зиологических, антропометрических, физиологических характе- ристик и возможностей пользователей АИС с техническими ха- рактеристиками комплекса средств автоматизации АИС и пара- метрами рабочей среды на рабочих местах персонала АИС [4]. Охрана здоровья трудящихся, обеспечение безопасности ус- ловий труда, ликвидация профессиональных заболеваний и про- изводственного травматизма составляют одну из главных забот человеческого общества. Обращается внимание на необходи- мость широкого применения прогрессивных форм научной ор- ганизации труда, сведения к минимуму ручного, малоквалифи- цированного труда, на создание обстановки, исключающей про- фессиональные заболевания и производственный травматизм. 1.3. Архитектура АИС Термин «архитектура» применительно к вычислительным системам появился задолго до создания первых АИС, тем не ме- нее он является одним из основополагающих и в сфере инфор- мационных технологий. Существуют различные подходы к опре- делению архитектуры АИС, различные точки зрения и различная степень детализации рассмотрения; приведем некоторые из них. Согласно [11] архитектура — это организационная структура автоматизированной системы. Известно и другое определение [12]: архитектура — это концептуальное описание структуры
20 Глава 1. Проектирование АИС системы, включающее описание элементов системы, их взаимо- действия и внешних свойств. Выделяют два уровня архитектуры АИС: • бизнес-архитектуру (бизнес-уровень); • уровень информационных технологий (технический уро- вень). Бизнес-архитектура обычно первична по отношению к тех- ническому уровню; может существовать и реализуема вне зави- симости от существования АИС. Бизнес-архитектура является предметной областью для анализа и проведения автоматизации. На бизнес-уровне определяется набор задач, требований, харак- теристик, осуществляемых с помощью АИС. Соответствие ука- занному уровню технического уровня является основой эффек- тивности функционирования АИС. С другой стороны, новые возможности, предоставляемые ис- пользованием информационных технологий, стимулируют раз- витие и корректировку бизнес-архитектуры, в связи с чем она является неотъемлемой частью архитектуры АИС и всего пред- приятия [13]. Уровень информационных технологий или технический уровень представляет собой интегрированный комплекс технических средств, используемых в АИС для реализации задач предпри- ятия, и включает в себя как логические, так и технические (про- граммные и аппаратные) компоненты. Компонентами этого уровня, в свою очередь, являются следующие подуровни: • архитектура программных систем; • информационная архитектура; • технологическая (инфраструктурная) архитектура. Информационная архитектура представляет собой логическую организацию данных, с которыми работает АИС, т. е. практиче- ски структуры баз данных и баз знаний, а также принципы их взаимодействия. Под архитектурой программных систем понимают совокуп- ность следующих технических решений: • общий архитектурный стиль и общую организацию про- граммной части АИС; • деление программного комплекса на функциональные под- системы и модули; • свойства модулей, методы их взаимодействия и объедине- ния, используемые интерфейсы.
1.4. Жизненный цикл АИС 21 Архитектура программной системы охватывает не только структурные и поведенческие аспекты, но и правила ее использо- вания и интеграции с другими системами, функциональность, производительность, гибкость, надежность, эргономичность, тех- нологические ограничения. Технологическая архитектура описывает инфраструктуру, ис- пользуемую для передачи данных. На этом уровне решаются во- просы сетевой структуры, применяемых каналов связи и т. д. По мере развития программных систем все большее значе- ние приобретает их комплексная интеграция для построения единого информационного пространства предприятия. Обеспе- чение такой интеграции является важнейшим элементом архи- тектуры, в противном случае АИС окажется неэффективной. В современных стандартах четко определены процессы со- здания архитектуры, способной к удовлетворению не только сформулированных, но и потенциальных потребностей пользо- вателей. К числу самых известных и авторитетных разработчи- ков стандартов в области АИС относятся следующие междуна- родные организации: • SEI (Software Engineering Institute); • WWW (консорциум World Wide Web); • OMG (Object Management Group); • организация разработчиков Java — JCP (Java Community Process); • IEEE (Institute of Electrical and Electronics Engineers) и т. д. 1.4. Жизненный цикл АИС Одним из базовых понятий методологии проектирования АИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО — это непрерывный процесс, который начинается с момента принятия решения о необходи- мости его создания и заканчивается в момент его полного изъя- тия из эксплуатации [15]. По аналогии правомерно будет утверждать, что жизненный цикл АИС есть непрерывный процесс с момента принятия ре- шения о необходимости ее создания до полного завершения ее эксплуатации. Продолжительность жизненного цикла современ- ных АИС составляет около 10 лет, что значительно превышает сроки морального и физического старения технических и сис-
22 Глава 1. Проектирование АИС темных программных средств, используемых при реализации АИС. Поэтому, как правило, в течение ЖЦ системы проводится ее модернизация, после чего все функции системы должны вы- полняться с не меньшей эффективностью. Добиться этого на протяжении всего ЖЦ АИС — довольно сложная по ряду объективных и субъективных причин задача, в результате подавляющее большинство проектов АИС внедряется с нарушениями качества, сроков или сметы; почти треть проек- тов прекращают свое существование незавершенными. По дан- ным Standish Group в 1996 г. 84 % проектов АИС не были завер- шены в установленные сроки, в 1998 г. это число сократилась до 74 %, после 2000 г. оно не опускается ниже 50 % [19]. Главной причиной такого положения является то, что уровень техноло- гии анализа и проектирования систем, методов и средств управ- ления проектами не соответствует сложности создаваемых сис- тем, которая постоянно возрастает в связи с усложнением и бы- стрыми изменениями бизнеса [19]. Из мировой практики известно, что затраты на сопровожде- ние прикладного программного обеспечения АИС составляют не менее 70 % его совокупной стоимости на протяжении ЖЦ, по- этому крайне важно еще на проектной стадии предусмотреть не- обходимые методы и средства сопровождения, включая методы конфигурационного управления. Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями) [18, 19]: • ГОСТ 34.601—90 — стандарт на стадии и этапы создания АИС, соответствующие каскадной модели ЖЦ ПО (рас- сматривается ниже). Приводится описание содержания ра- бот на каждом этапе; • ISO/IEC 12207:1995 — стандарт на процессы и организа- цию жизненного цикла; распространяется на все виды за- казного программного обеспечения; не содержит описания фаз, стадий и этапов; • Custom Development Method (методология Oracle) — техно- логический материал по разработке прикладных АИС, де- тализированный до уровня заготовок проектных докумен- тов в расчете на использование Oracle. Применяется для классической модели ЖЦ (предусмотрены все работы, за- дачи и этапы), а также для технологий «быстрой разработ- ки» (Fast Track) или «облегченного подхода», рекомендуе- мых в случае малых проектов;
1.4. Жизненный цикл АИС 23 • Rational Unified Process (методология RUP) — технологиче- ский материал по реализации итеративной модели разра- ботки, включающей четыре фазы (цикл разработки): нача- ло, исследование, построение и внедрение. Каждая фаза разбита на этапы (итерации), результатами которых явля- ются версии для внутреннего или внешнего использова- ния. Каждый цикл завершается генерацией очередной вер- сии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает разви- ваться и снова проходит те же фазы. Суть работы в рамках RUP-методологии — создание и сопровождение моделей на базе UML [14]; • Microsoft Solution Framework (методология MSF) — техно- логический материал по реализации итеративной модели разработки, аналогично RUP включает четыре фазы: ана- лиз, проектирование, разработку, стабилизацию; предпола- гает использование объектно-ориентированного моделиро- вания. MSF в сравнении с RUP в большей степени ориен- тирована на разработку бизнес-приложсний; • Extreme Programming (ХР) — экстремальное программиро- вание (самая новая среди рассматриваемых методологий); сформировалось в 1996 г. Основой методологии является работа в команде, эффективные коммуникации между за- казчиком и исполнителем в течение всего проекта; разра- ботка АИС ведется с использованием последовательно до- рабатываемых прототипов. В качестве определяющего документа на создание и испыта- ния АИС целесообразно рассматривать международный стандарт ISO/IEC 12207, так как ГОСТы серии 34 уже устарели, а ряд эта- пов ЖЦ АИС представлены недостаточно полно. Стандарт ISO/IEC 12207 в структуре жизненного цикла определяет про- цессы, которые выполняются при создании ПО АИС. Эти про- цессы подразделяют на три группы: • основные (приобретение, поставка, разработка, эксплуата- ция и сопровождение); • вспомогательные (документирование, управление конфигу- рацией, обеспечение качества, верификация, аттестация, оценка, аудит и решение проблем); • организационные (управление проектами, создание инфра- структуры проекта, определение, оценка и улучшение са- мого жизненного цикла, обучение).
24 Глава 1. Проектирование АИС Среди основных процессов жизненного цикла самыми важ- ными являются разработка, эксплуатация и сопровождение. Каж- дый процесс характеризуется определенными задачами и мето- дами их решения, исходными данными, полученными на преды- дущем этапе, и результатами [8, 18, 19]. Разработка АИС включает все работы по созданию про- граммного обеспечения и его компонентов в соответствии с за- данными требованиями. Этот процесс также предусматривает: • оформление проектной и эксплуатационной документа- ции; • подготовку материалов, необходимых для тестирования разработанных программных продуктов; • разработку материалов, необходимых для обучения персо- нала. Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реали- зация (программирование). К процессу эксплуатации относятся: • конфигурирование базы данных и рабочих мест пользова- телей; • обеспечение пользователей эксплуатационной документа- цией; • обучение персонала. Основные эксплуатационные работы включают: • непосредственно эксплуатацию; • локализацию проблем и устранение причин их возникно- вения; • модификацию программного обеспечения; • подготовку предложений по совершенствованию системы; • развитие и модернизацию системы. Профессиональное, грамотное сопровождение — необходи- мое условие решения задач, выполняемых АИС. Службы техни- ческой поддержки играют весьма заметную роль в жизни любой АИС. Ошибки на этом этапе могут привести к явным или скры- тым финансовым потерям, сопоставимым со стоимостью самой системы. К предварительным действиям при организации техническо- го обслуживания АИС относятся: • выделение наиболее ответственных узлов системы и опре- деление для них критичности простоя (это позволит выде- лить наиболее критичные составляющие АИС и оптимизи-
1.4. Жизненный цикл АИС 25 ровать распределение ресурсов для технического обслужи- вания); • определение задач технического обслуживания и их разде- ление на внутренние, решаемые силами обслуживающего подразделения, и внешние, решаемые специализированны- ми сервисными организациями (таким образом четко огра- ничивается круг исполняемых функций и производится распределение ответственности); • проведение анализа имеющихся внутренних и внешних ре- сурсов, необходимых для организации технического обслу- живания в рамках описанных задач и разделения компе- тенции (основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалифи- кация персонала); • подготовка плана организации технического обслужива- ния с определением этапов исполняемых действий, сроков их исполнения, затрат на этапах, ответственности испол- нителей. Обеспечение качественного технического обслуживания АИС требует привлечения специалистов высокой квалифика- ции, которые в состоянии решать не только ежедневные задачи администрирования, но и быстро восстанавливать работоспособ- ность системы при сбоях и авариях. В табл. 1.3 ориентировочно приведены описания основных процессов ЖЦ АИС. Среди вспомогательных процессов одним из главных является управление конфигурацией, которое поддерживает основные про- цессы жизненного цикла АИС, прежде всего процессы разработ- ки и сопровождения. Разработка сложных АИС предполагает независимую разра- ботку компонентов системы, что приводит к появлению многих вариантов и версий реализации как отдельных компонентов, так и системы в целом. Таким образом, возникает проблема обеспе- чения сохранения единой структуры в ходе разработки и модер- низации АИС. Управление конфигурацией позволяет организо- вывать, систематически учитывать и контролировать внесение изменений в различные компоненты АИС на всех стадиях ее ЖЦ [2, 5, 6]. Организационные процессы имеют очень большое значение, так как современные АИС — это большие комплексы, в созда-
Таблица 1.3. Содержание основных процессов ЖЦ АИС (ISO/IEC 12207) Процесс(испол- нитель процесса) Действия Вход Результат Приобретение (заказчик) Инициирование. Подготовка заявочных предло- жений. Подготовка договора. Контроль деятельности постав- щика. Приемка АИС Решение о начале работ по внедре- нию АИС. Результаты обследования деятель- ности заказчика. Результаты анализа рынка АИС/тен- дера. План поставки/разработки. Комплексный тест АИС Технико-экономическое обоснование внедрения АИС. Техническое задание на АИС. Договор на поставку/разработку. Акты приемки этапов работы. Акт приемо-сдаточных испытаний Поставка (разработчик АИС) Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка АИС Техническое задание на АИС. Решение руководства об участии в разработке. Результаты тендера. Техническое задание на АИС. План управления проектом. Разработанная АИС и документация Решение об участии в разработке. Коммерческие предпожения/конкурсная заявка. Договор на поставку/разработку. План управления проектом. Реапизация/корректировка. Акт приемо-сдаточных испытаний Разработка (разработчик АИС) Подготовка. Анализ требований к АИС. Проектирование архитектуры АИС. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификацион- ное тестирование ПО. Интеграция ИС и квалификацион- ное тестирование АИС Техническое задание на АИС. Техническое задание на АИС, мо- дель ЖЦ. Техническое задание на АИС. Подсистемы АИС. Спецификации требования к компо- нентам ПО. Архитектура ПО. Материалы детального проектиро- вания ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план ин- теграции ПО. Проект БД, спецификации интерфейсов между ком- понентами ПО, требования к тестам. Тесты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплек- са и комплекта документации требованиям ТЗ Глава 1. Проектирование АИС
1.4. Жизненный цикл АИС 27 нии и обслуживании которых занято много людей разных спе- циальностей. Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков, кон- троля сроков и качества выполнения работ. Техническое и орга- низационное обеспечение проекта включает: • выбор методов и инструментальных средств реализации проекта; • определение методов описания состояния процесса разра- ботки; • разработку методов и средств испытаний созданного про- граммного обеспечения; • обучение персонала. Обеспечение качества проекта связано с проблемами вери- фикации, проверки и тестирования компонентов АИС. Верификация — процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требова- ниям этого этапа. Проверка — процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидаемыми результатами, а также для оценки соответствия характеристик АИС исходным требованиям. Для поддержки практического применения стандарта ISO/IEC 12207 разработаны технологические документы: Руко- водство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology — Guide for ISO/IEC 12207) и Руководство по приме- нению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering — Guide for the application of ISO/IEC 12207 to project management). В 2002 г. был опубликован стандарт на процессы ЖЦ автома- тизированных систем (ISO/IEC 15288 System life cycle processes). В разработке стандарта участвовали специалисты из различных областей деятельности; учитывался практический опыт создания систем в правительственных, коммерческих, военных и академи- ческих организациях. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ включены следующие группы процессов. 1. Договорные процессы: • приобретение (внутренние решения или решения внеш- него поставщика);
28 Глава 1. Проектирование АИС • поставка (внутренние решения или решения внешнего поставщика). 2. Процессы предприятия: • управление окружающей средой предприятия; • инвестиционное управление; • управление ЖЦ ИС; • управление ресурсами; • управление качеством. 3. Проектные процессы: • планирование проекта; • оценка проекта; • контроль проекта; • управление рисками; • управление конфигурацией; • управление информационными потоками; • принятие решений. 4. Технические процессы: • определение требований; • анализ требований; • разработка архитектуры; • внедрение; • интеграция; • верификация; • переход; • аттестация; • эксплуатация; • сопровождение; • утилизация. 5. Специальные процессы: • определение и установка взаимосвязей исходя из задач и целей. В табл. 1.4 приведены перечень стадий и основные результа- ты к моменту их завершения в соответствии с указанным стан- дартом. В 1970-х гг. корпорация IBM предложила методологию Business System Planning (BSP) или методологию организацион- ного планирования. Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных под-
1.4. Жизненный цикл АИС 29 Таблица 1.4. Стадии создания АИС (ISO/IEC 15288) Стадия Описание Формирование концепции Анализ потребностей, выбор концепции и проектных решений Разработка Проектирование системы Реализация Изготовление системы Эксплуатация Ввод в эксплуатацию и использование системы Поддержка Обеспечение функционирования системы Снятие с эксплуатации Прекращение использования, демонтаж, архивирование системы разделений, функций систем обработки данных (информацион- ных систем), информационных объектов, документов и баз дан- ных, предложенный в BSP, используется сегодня не только в проектах создания АИС, но и в проектах реинжиниринга биз- нес-процессов, изменения организационной структуры. Важней- шие шаги процесса BSP, их последовательность (получить под- держку высшего руководства, определить процессы предпри- ятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике [21]. По опубликованным данным [19, 21] каждый этап разработки АИС требует определенных затрат времени. В основном (45—50 %) время уходит на кодирование, комплексное и авто- го % Рнс. 1.4. Распределение времени при разработке АИС
30 Глава 1. Проектирование АИС Сопровождение 67% Анализ требований 3% Комплексное тестирование 7% Кодирование 7% Автономное тестирование 8% Проектирование 5% Рис. 1.5. Распределение времени при разработке, эксплуатации и сопровождении АИС Определение спецификаций номное тестирование (рис. 1.4). В среднем разработка АИС зани- мает лишь одну треть всего жизненного цикла системы (рис. 1.5). 1.5. Модели жизненного цикла АИС Согласно [8, 16—18] рассмотренные выше процессы характе- ризуются определенными задачами и методами их решения, ис- ходными данными, полученными на предыдущем этапе, результ татами. Результатами анализа, в частности, являются функцио- нальные модели, информационные модели и соответствующие им диаграммы. При этом ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в прот ектных решениях, выработанных на более ранних этапах. Из- вестные модели ЖЦ ПО (каскадная, итерационная, спиральная) определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. По аналогии с известным определением модели ЖЦ ПО и в соответствии с устоявшейся среди специалистов терминологией, [18] приведем определение модели ЖЦ АИС. Модель жизненного цикла АИС — это структура, описываю- щая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения в течение всего жизненного цикла системы. Модель ЖЦ АИС отражает состояние системы с момента* осознания необходимости создания данной АИС до полной ее
1.5. Модели жизненного цикла АИС 31 утилизации. Выбор модели жизненного цикла зависит от специ- фики, масштаба, сложности проекта и набора условий, в кото- рых АИС создается и функционирует. Модель ЖЦ АИС вклю- чает: • стадии; • результаты выполнения работ на каждой стадии; • ключевые события или точки завершения работ и приня- тия решений. В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС — каскадную, итерационную, спиральную. Ниже подробно рассмотрена каждая из них. Каскадная модель описывает классический подход к разра- ботке систем в любых предметных областях; широко использо- валась в 1970—80-х гг. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различ- ных отраслях в связи с наличием теоретического обоснования, промышленных методик и стандартов, а также успешного ис- пользования модели в течение десятилетий. Каскадная модель предусматривает последовательную орга- низацию работ, причем основной особенностью модели являет- ся разбиение всей работы на этапы. Переход от предыдущего этапа к последующему происходит только после полного завер- шения всех работ предыдущего. Каждый этап завершается вы- пуском полного комплекта документации для того, чтобы иметь возможность при необходимости всегда продолжить разработку. Периодически названия стадий разработки в каскадной мо- дели менялись; кроме того, в каждый период времени регламент приписывания определенных работ к конкретным этапам нико- гда не являлся жестким и однозначным. Тем не менее выделяют пять устойчивых этапов разработки, практически не зависящих от предметной области (рис. 1.6). На первом этапе проводится исследование проблемной об- ласти, формулируются требования заказчика. Результатом дан- ного этапа является техническое задание (задание на разработ- ку), согласованное со всеми заинтересованными сторонами. В ходе второго этапа, согласно требованиям технического за- дания, разрабатываются те или иные проектные решения. В ре- зультате появляется комплект проектной документации. Третий этап — реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с про- ектными решениями предыдущего этапа. Методы реализации
32 Глава 1. Проектирование АИС Рис. 1.6. Каскадная модель ЖЦ АИС при этом принципиального значения не имеют. Результатом вы- полнения этапа является готовый программный продукт. На четвертом этапе проводится проверка полученного про- граммного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация по- зволяет выявить различного рода скрытые недостатки, прояв- ляющиеся в реальных условиях работы АИС. Последний этап — сдача готового проекта, и главное здесь — убедить заказчика в том, что все его требования выполнены в полной мере. Этапы работ в рамках каскадной модели часто называют час- тями проектного цикла АИС, поскольку этапы состоят из мно- гих итерационных процедур уточнения требований к системе и вариантов проектных решений. ЖЦ АИС существенно сложнее и длиннее: он может включать в себя произвольное число цик- лов уточнения, изменения и дополнения уже принятых и реали- зованных проектных решений. В этих циклах происходит разви- тие АИС и модернизация отдельных ее компонентов. Каскадная модель получила широкое распространение не только среди специалистов, так как обладает достоинствами, проявляющимися при выполнении различных разработок. Ниже приведены основные: 1) на каждом этапе формируется законченный набор проект- ной документации, отвечающий критериям полноты и согласо- ванности. На заключительных этапах разрабатывается пользова- тельская документация, охватывающая все предусмотренные стандартами виды обеспечения АИС (организационное, инфор- мационное, программное, техническое и т. д.);
1.5. Модели жизненного цикла АИС 33 2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты. Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значе- ния для прикладной области до настоящего времени. Кроме того, каскадный подход идеально подходит для разработки АИС, так как уже в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоста- вить разработчикам свободу технической реализации. К таким АИС, в частности, относятся сложные расчетные системы и сис- темы реального времени. Тем не менее модель имеет ряд недостатков, ограничиваю- щих ее применение: • существенная задержка в получении результатов; • ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата; • сложность параллельного ведения работ по проекту; • чрезмерная информационная перенасыщенность каждого из этапов; • сложность управления проектом; • высокий уровень риска и ненадежность инвестиций. Задержка в получении результатов проявляется в том, что при последовательном подходе к разработке согласование ре- зультатов с заинтересованными сторонами производится только после завершения очередного этапа работ. В результате может оказаться, что разрабатываемая АИС не соответствует требова- ниям, и такие несоответствия могут возникать на любом этапе разработки; кроме того, ошибки могут непреднамеренно вно- ситься и проектировщиками-аналитиками, и программистами, так как они не обязаны хорошо разбираться в тех предметных областях, для которых разрабатывается АИС. Кроме того, используемые при разработке АИС модели авто- матизируемого объекта, отвечающие критериям внутренней со- гласованности и полноты, в силу различных причин могут уста- реть за время разработки (например, из-за внесения изменений в законодательство). Возврат на более ранние стадии. Этот недостаток является одним из проявлений предыдущего: поэтапная последовательная работа над проектом может привести к тому, что ошибки, допу- щенные на более ранних этапах, обнаруживаются только на по-
34 Глава 1. Проектирование АИС следующих стадиях. В результате проект возвращается на преды- дущий этап, перерабатывается и только затем передается в по- следующую работу. Это может послужить причиной срыва графика и усложнения взаимоотношений между группами разра- ботчиков, выполняющих отдельные этапы. Самый плохой вариант, когда недоработки предыдущего эта- па обнаруживаются не на следующем этапе, а позднее. Напри- мер, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области. Это означает, что часть проекта должна быть возвращена на начальный этап работы. Вообще, работа может быть возвращена с любого этапа на любой преды- дущий, поэтому в реальности каскадная схема разработки выгля- дит так, как показано на рис. 1.7 [16—18]. Рис. 1.7. Процесс разработки АИС по каскадной схеме Одной из причин возникновения данной ситуации является то, что в качестве экспертов, участвующих в описании предмет- ной области, часто выступают будущие пользователи системы, которые иногда не могут четко сформулировать требования к АИС. Кроме того, заказчики и исполнители часто неправильно понимают друг друга, так как заказчики далеки от программиро- вания, а исполнители обычно не являются специалистами в предметной области. Сложность параллельного ведения работ связана с необходи- мостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависят друг от друга группы разработчиков. В результа- те преимущества параллельного ведения работ просто теряются-;
1.5. Модели жизненного цикла АИС 35 отсутствие параллелизма негативно сказывается и на организа- ции работы всего коллектива. В частности, пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестирова- нием и администрированием, почти не загружены. Кроме того, при последовательной разработке крайне сложно внести измене- ния в проект после завершения этапа и передачи проекта на сле- дующую стадию. Так, если после передачи проекта на следую- щий этап группа разработчиков нашла более эффективное реше- ние, оно не может быть реализовано, поскольку предыдущее решение уже, возможно, реализовано и увязано с другими частя- ми проекта [8, 16—18]. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Дело в том, что при внесении изменений в одну из частей проекта, необходимо оповещать тех разработчиков, которые использовали (могли использовать) ее в своей работе. При наличии большого числа взаимосвязанных подсистем син- хронизация внутренней документации становится отдельной важнейшей задачей: разработчики должны постоянно знако- миться с изменениями и оценивать, как скажутся (или уже ска- зались) эти изменения на полученных результатах. В итоге может потребоваться повторное тестирование и вне- сение изменений в уже готовые части проекта. Причем эти из- менения, в свою очередь, необходимо отразить во внутренней документации и разослать другим группам разработчиков. Как следствие, резко возрастет объем документации и, соответствен- но, понадобится больше времени для ознакомления с ней. Помимо изучения нового материала, не отпадает необходи- мость и в изучении старой информации. Ведь вполне вероятно, что в процессе разработки изменится кадровый состав и новым разработчикам понадобится информация о сделанном ранее. Причем, чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела. Сложность управления проектом в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Рег- ламентированная последовательность работ приводит к тому, что одни группы разработчиков должны ожидать результатов ра- боты других команд, поэтому требуется административное вме-
36 Глава 1. Проектирование АИС шательство для согласования сроков и состава передаваемой до- кументации. В случае же обнаружения ошибок в работе необходим воз- врат к предыдущим этапам; текущая работа тех, кто ошибся, прерывается. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Упростить взаимодействие между разработчиками и умень- шить информационную перенасыщенность документации мож- но, сокращая количество связей между отдельными частями проекта, но далеко не каждую АИС можно разделить на слабо связанные подсистемы. Высокий уровень риска. Чем сложнее проект, тем дольше длит- ся каждый этап разработки и тем сложнее взаимосвязи между от- дельными частями проекта, количество которых также увеличи- вается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, т. е. после завершения ана- лиза, проектирования и разработки — этапов, выполнение кото- рых требует значительного времени и средств [18]. Запоздалая оценка порождает серьезные проблемы при вы- явлении ошибок анализа и проектирования — требуется возврат на предыдущие стадии и повторение процесса разработки. Одна- ко возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. При этом никто не гарантирует, что предметная область снова не из- менится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность «зацикливания» процесса разработки: расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно от- кладываться. Таким образом, сложные проекты, разрабатываемые по кас- кадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой ком- пании The Standish Group в США более 31 % проектов корпора- тивных информационных систем (IT-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, т. е. почти в 2 раза); и толь- ко 16,2 % проектов укладывается и в срок, и в бюджет [13]. Помимо приведенных недостатков каскадной модели есть еще один. Он связан с возникновением конфликтов (не всегда явных) между разработчиками, которые обусловлены тем, что
1.5. Модели жизненного цикла АИС 37 возврат части проекта на предыдущую стадию обычно сопрово- ждается поиском виновных. Поскольку однозначно персонифи- цировать виноватого не всегда возможно, отношения в коллек- тиве усложняются. Как следствие, в рабочей группе часто ценится не тот руко- водитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспе- чить им более удобные условия работы и т. п. В результате появ- ляется опасность снижения и квалификации, и творческого по- тенциала всей команды. Соответственно, техническое руково- дство проектом начинает в большей степени подменяться организационным, более детальной проработкой должностных инструкций и более формальным их исполнением. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дис- циплины и творчества. Чем строже дисциплина, тем менее твор- ческой становится атмосфера в коллективе. Такое положение ве- щей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив [5, 6]. Построение итерационной модели заключается в серии корот- ких циклов (шагов) по планированию, реализации, изучению, действию. Создание сложных АИС предполагает проведение согласова- ний проектных решений, полученных при реализации отдельных задач. Подход к проектированию «снизу — вверх» обусловливает необходимость таких итераций возвратов, когда проектные ре- шения по отдельным задачам объединяются в общие системные решения. При этом возникает потребность в пересмотре ранее сформировавшихся требований. Преимущество итерационной модели в том, что межэтапные корректировки обеспечивают меньшую трудоемкость разработки по сравнению с каскадной моделью. Недостатки итерационной модели: • время жизни каждого этапа растягивается на весь период разработки; • вследствие большого числа итераций возникают рассогла- сования выполнения проектных решений и документации; • запутанность архитектуры; • трудности использования проектной документации на ста- диях внедрения и эксплуатации вызывают необходимость перепроектирования всей системы.
38 Глава 1. Проектирование АИС Спиральная модель, в отличие от каскадной, но аналогично предыдущей предполагает итерационный процесс разработки АИС. При этом возрастает значение начальных этапов, таких как анализ и проектирование, на которых проверяется и обосно- вывается реализуемость технических решений путем создания прототипов. Каждая итерация представляет собой законченный цикл раз- работки, приводящий к выпуску внутренней или внешней вер- сии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать закон- ченной системой (рис. 1.8). Проектирование Реализация Версия 2 Версия 3 Тестирование Разработка требований Рис. 1.8. Спиральная модель ЖЦ АИС Версия 1 Ввод в действие прототипов системы Таким образом, каждый виток спирали соответствует созда- нию фрагмента или версии программного изделия, на нем уточ- няются цели и характеристики проекта, определяется его качест- во, планируются работы на следующем витке спирали. Каждая итерация служит для углубления и последовательной конкрети- зации деталей проекта, в результате этого выбирается обосно- ванный вариант окончательной реализации. Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего, — недоделанную работу можно будет выполнить на следующей итерации. Главная задача каж- дой итерации — как можно быстрее создать работоспособный
1.5. Модели жизненного цикла АИС 39 продукт для демонстрации пользователям. Таким образом, суще- ственно упрощается процесс внесения уточнений и дополнений в проект. Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной моде- ли и, кроме того, обеспечивает ряд дополнительных возможно- стей, делая процесс разработки более гибким. Преимущества итерационного подхода: • итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика; • при использовании спиральной модели отдельные элемен- ты АИС интегрируются в единое целое постепенно. По- скольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (при использовании каскадной модели инте- грация занимает до 40 % всех затрат в конце проекта); • снижение уровня рисков (следствие предыдущего преиму- щества, так как риски обнаруживаются именно во время ин- теграции). Уровень рисков максимален в начале разработки проекта, по мере продвижения разработки он снижается. Данное утверждение справедливо при любой модели разра- ботки, однако при использовании спиральной снижение уровня рисков происходит с наибольшей скоростью, так как интеграция выполняется уже на первой итерации. На на- чальных итерациях выявляются многие аспекты проекта (пригодность используемых инструментальных средств, программного обеспечения, квалификация разработчиков и т. п.). На рис. 1.9 приведено сравнение зависимостей рис- ков от времени разработки для каскадного и итерационного подходов [8, 16—18]; Рис. 1.9. Зависимость рисков от времени разработки
40 Глава 1. Проектирование АИС • итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения такти- ческих изменений в разрабатываемое изделие. Так, можно сократить сроки разработки за счет снижения функциональ- ности системы или использовать в качестве составных час- тей продукцию сторонних фирм вместо собственных разра- боток (актуально при рыночной экономике, когда необхо- димо противостоять продвижению изделия конкурентов); • итерационный подход упрощает повторное использование компонентов, поскольку гораздо проще выявить (иденти- фицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после нескольких начальных ите- раций позволяет выявить общие многократно используе- мые компоненты, которые на последующих итерациях бу- дут совершенствоваться; • спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере разви- тия системы ошибки и слабые места обнаруживаются и ис- правляются на каждой итерации. Одновременно корректи- руются критические параметры эффективности, что в слу- чае каскадной модели доступно только перед внедрением системы; • итерационный подход позволяет совершенствовать процесс разработки — в результате анализа в конце каждой итера- ции проводится оценка изменений в организации разра- ботки; на следующей итерации она улучшается. Основная проблема спирального цикла — трудность опреде- ления момента перехода на следующий этап. Для ее решения не- обходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превра- титься в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее — враг хорошего». Поэтому завершение итерации долж- но производиться строго в соответствии с планом, даже если не вся запланированная работа закончена [5, 8, 16—18]. Планиро- вание работ обычно проводится на основе статистических дан- ных, полученных в предыдущих проектах, и личного опыта раз- работчиков. В основе спиральной модели жизненного цикла ле- жит применение прототипной — Rapid Application Development, RAD-технологии [17, 18]. Эта технология обеспечивает создание
1.6. Методология и технология проектирования АИС 41 на ранней стадии реализации действующей интерактивной моде- ли системы так называемой системы-прототипа, позволяющей наглядно продемонстрировать пользователю будущую систему, уточнить его требования, оперативно модифицировать интер- фейсные элементы — формы ввода сообщений, меню, выходные документы, структуру диалога, состав реализуемых функций. В процессе работы с системой-прототипом пользователь ре- ально осознает возможности будущей системы и определяет наиболее удобный для него режим обработки данных, что значи- тельно повышает качество создаваемых систем. Осуществляется проверка принципиальных проектных решений по составу и структуре АИС и оценка основных ее эксплуатационных харак- теристик. Вовлечение пользователей в процесс проектирования и кон- струирования приложения позволяет получать замечания и до- полнения к требованиям непосредственно в процессе проекти- рования приложения, сокращая время разработки. Представите- ли заказчика получают возможность контролировать процесс создания системы и влиять на ее функциональное наполнение. Результатом является сдача в эксплуатацию системы, учитываю- щей большинство потребностей заказчиков. 1.6. Методология и технология проектирования АИС Современные методологии и реализующие их технологии проектирования АИС поставляются в электронном виде вместе с CASE-средствами (рассмотрены далее) и включают библиоте- ки процессов, шаблонов, методов, моделей и других компонен- тов, предназначенных для построения ПО того класса систем, на который ориентирована методология. Электронные методо- логии и технологии составляют ядро комплекса согласованных инструментальных средств разработки АИС [6, 8, 16—18]. Осо- бенности современных методологических решений проектиро- вания АИС невозможно реализовать без определенных техноло- гий проектирования, соответствующих масштабу и специфике проекта. Технология проектирования АИС — это совокупность методов и средств проектирования АИС, а также методов и средств орга- низации проектирования (управление процессом создания и мо-
42 Глава 1. Проектирование АИС дернизации проекта АИС) [8, 16—18]. В основе технологии про- ектирования лежит технологический процесс (ТП), который оп- ределяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Согласно [20] ТП проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и со- подчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектирова- нии АИС, могут быть определены как неделимые технологиче- ские операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными, которые вырабатывают по установленным критери- ям оценки результатов проектирования. Таким образом, технология проектирования задается регла- ментированной последовательностью технологических опера- ций, выполняемых в процессе создания проекта на основе того или иного метода. Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС. Основные требования, предъявляемые к выбираемой техно- логии проектирования, следующие: • созданный с помощью этой технологии проект должен от- вечать требованиям заказчика; • технология должна максимально отражать все этапы цикла жизни проекта; • технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта; • технология должна способствовать росту производительно- сти труда проектировщиков; • технология должна обеспечивать надежность процесса про- ектирования и эксплуатации проекта; • технология должна способствовать простому ведению про- ектной документации. Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология про- ектирования предполагает наличие некоторой концепции, прин- ципов проектирования и реализуется набором методов и средств.
1.6. Методология и технология проектирования АИС 43 Методы проектирования АИС можно классифицировать по степени использования средств автоматизации, типовых проект- ных решений, адаптивности к предполагаемым изменениям. По степени автоматизации различают: • ручное проектирование, при котором проектирование ком- понентов АИС осуществляется без использования специ- альных инструментальных программных средств; програм- мирование производится на алгоритмических языках; • компьютерное проектирование, при котором генерация или конфигурация (настройка) проектных решений произ- водится с использованием специальных инструментальных программных средств. По степени использования типовых проектных решений разли- чают: • оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответст- вии с требованиями к АИС; • типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программ- ных модулей). Оригинальное проектирование АИС предполагает максималь- ный учет особенностей автоматизированного объекта. Типовое проектирование выполняется на основе готовых ре- шений и является обобщением опыта, полученного ранее при создании родственных проектов. По степени адаптивности проектных решений различаются следующие методы: • реконструкция — адаптация проектных решений выполня- ется путем переработки соответствующих компонентов (перепрограммирования программных модулей); • параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами; • реструктуризация модели — изменяется модель предметной области, что приводит к автоматическому переформирова- нию проектных решений. Сочетание различных признаков классификации методов проектирования обусловливает характер используемой техноло- гии проектирования АИС. Выделяются два основных класса технологии проектирования: каноническая и индустриальная (табл. 1.5). Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (ис-
44 Глава 1. Проектирование АИС пользование CASE-технологий) и типовое (параметриче- ски-ориентированное или модельно-ориентированное) проекти- рование. Использование индустриальных технологий проекти- рования не исключает использования в отдельных случаях канонической технологии [18, 19]. Таблица 1.5. Характеристики классов технологий проектирования Класс технологии проек- тирования Степень автоматизации Степень типизации Степень адаптивности Каноническое проек- тирование Ручное проектирова- ние Оригинальное проек- тирование Реконструкция Индустриальное авто- матизированное про- ектирование Компьютерное проек- тирование То же Реструктуризация мо- дели Индустриальное типо- вое проектирование То же Типовое сборочное проектирование Параметризация и ре- структуризация мо- дели Каноническое проектирование АИС ориентировано на исполь- зование главным образом каскадной модели жизненного цикла АИС. Стадии и этапы работы такого проектирования описаны в ГОСТ 34.601-90. В зависимости от сложности объекта автоматизации и набо- ра задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоемкость. До- пускается объединять последовательные этапы и исключать не- которые из них на любой стадии проекта. Допускается также на- чинать выполнение работ следующей стадии до окончания пре- дыдущей. Стадии и этапы создания АИС, выполняемые организация- ми-участниками, прописываются в договорах и технических за- даниях на выполнение работ. Стадия 1. Формирование требований к АИС: • обследование объекта и обоснование необходимости созда- ния АИС; • формирование требований пользователей к АИС; • оформление отчета о выполненной работе и тактико-тех- нического задания на разработку. Стадия 2. Разработка концепции АИС: • изучение объекта автоматизации;
1.6. Методология и технология проектирования АИС 45 • проведение необходимых научно-исследовательских работ; • разработка вариантов концепции АИС, удовлетворяющих требованиям пользователей; • оформление отчета и утверждение концепции. Стадия 3. Техническое задание: • разработка и утверждение технического задания на созда- ние АИС. Стадия 4. Эскизный проект: • разработка предварительных проектных решений по систе- ме и ее частям; • разработка эскизной документации на АИС и ее части. Стадия 5. Технический проект: • разработка проектных решений по системе и ее частям; • разработка документации на АИС и ее части; • разработка и оформление документации на поставку ком- плектующих изделий; • разработка заданий на проектирование в смежных частях проекта. Стадия 6. Рабочая документация: • разработка рабочей документации на АИС и ее части; • разработка и адаптация программ. Стадия 7. Ввод в действие: • подготовка объекта автоматизации; • подготовка персонала; • комплектация АИС поставляемыми изделиями (программ- ными и техническими средствами, программно-технически- ми комплексами, информационными изделиями); • строительно-монтажные работы; • пусконаладочные работы; • проведение предварительных испытаний; • проведение опытной эксплуатации; • проведение приемочных испытаний. Стадия 8. Сопровождение АИС: • выполнение работ в соответствии с гарантийными обяза- тельствами; • послегарантийное обслуживание. Рассмотрим специфику составляющих некоторых стадий подробнее.
46 Глава 1. Проектирование АИС Обследование — это изучение и анализ организационной структуры предприятия, его деятельности и существующей сис- темы обработки информации [20]. Материалы, полученные в ре- зультате обследования, используются для: • обоснования разработки и поэтапного внедрения систем; • составления технического задания на разработку систем; • разработки технического и рабочего проектов систем. На этапе обследования целесообразно выделить две состав- ляющие: определение стратегии внедрения АИС и детальный анализ деятельности организации. Основная задача первого этапа обследования — оценка ре- ального объема проекта, его целей и задач на основе выявлен- ных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком АИС самостоятельно, или с привлечением кон- салтинговых организаций. Этап предполагает тесное взаимодей- ствие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия — полу- чить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в ре- зультате интервью, бесед или семинаров с руководством, экспер- тами и пользователями. По завершении стадии обследования появляется возмож- ность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (на аппаратное обеспечение, на закупаемое программное обеспечение и на раз- работку нового программного обеспечения). Результатом этапа определения стратегии является документ (технико-экономическое обоснование — ТЭО — проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (гра- фик выполнения работ) и сколько это будет стоить (для крупных проектов — это график финансирования на разных этапах ра- бот). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидае- мый экономический эффект (если его удается оценить). Примерное содержание ТЭО: • ограничения, риски, критические факторы, которые могут повлиять на успешность проекта; • совокупность условий, при которых предполагается экс- плуатировать будущую систему, — архитектура системы, ап-
1.6. Методология и технология проектирования АИС 47 паратные и программные ресурсы, условия функционирова- ния, обслуживающий персонал и пользователи системы; • сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации; • описание выполняемых системой функций; • возможности развития и модернизации системы; • интерфейсы и распределение функций между человеком и системой; • требования к ПО и системам управления базами данных (СУБД). На этапе детального анализа деятельности организации изу- чаются деятельность, обеспечивающая реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчинен- ности вышестоящим органам управления. Здесь следует наметить инструктивно-методические и директивные материалы, на осно- вании которых определяются состав подсистем и перечень задач, а также возможности применения новых методов решения задач. Аналитики собирают и фиксируют информацию в двух взаи- мосвязанных формах: • функции — информация о событиях и процессах, которые происходят в автоматизируемой организации; • сущности — информация о классах объектов, имеющих значение для организации и о которых собираются данные. При изучении каждой функциональной задачи управления определяются: • наименование задачи; сроки и периодичность ее решения; • степень формализуемости задачи; • источники информации, необходимые для решения задачи; • показатели и их количественные характеристики; • порядок корректировки информации; • действующие алгоритмы расчета показателей и возможные методы контроля; • действующие средства сбора, передачи и обработки инфор- мации; • действующие средства связи; • принятая точность решения задачи; • трудоемкость решения задачи; • действующие формы представления исходных данных и ре- зультатов их обработки в виде документов; • потребители результатной информации по задаче.
48 Глава 1. Проектирование АИС Одной из наиболее трудоемких, хотя и хорошо формализуе- мых, задач этого этапа является описание документооборота ор- ганизации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить: • количество документов; • место формирования показателей документов; • взаимосвязь документов при их формировании; • маршрут и длительность движения документа; • место использования и хранения данного документа; • внутренние и внешние информационные связи; • объем документа в знаках. По результатам обследования устанавливают перечень задач управления, подлежащих автоматизации, и очередность их раз- работки. На этапе обследования следует классифицировать планируе- мые функции системы по степени важности. Один из возможных форматов представления такой классификации — MuSCoW [22]. Эта аббревиатура расшифровывается так: Must have — необходи- мые функции; Should have — желательные функции; Could have — возможные функции; Won't have — отсутствующие функции. Функции первой категории обеспечивают критичные для успешной работы системы возможности. Реализация функций второй и третьей категорий ограничивается временными и фи- нансовыми рамками: разрабатывается необходимое, а также мак- симально возможное в порядке приоритета число функций вто- рой и третьей категорий. Последняя категория функций особен- но важна, поскольку нужно четко представлять границы проекта и набор функций, которые будут отсутствовать в системе. Модели деятельности организации создаются в двух видах [6, 16, 18]: • модель «как есть» («as is») — отражает существующие в ор- ганизации бизнес-процессы; • модель «как должно быть» («to be») — отражает необходи- мые изменения бизнес-процессов с учетом внедрения АИС. Уже на этапе анализа необходимо привлекать к работе груп- пы тестирования для решения следующих задач: • получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных сис- тем, СУБД и т. п.;
1.6. Методология и технология проектирования АИС 49 • разработки плана работ по обеспечению надежности АИС и се тестирования. Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Чем позже обна- ружены ошибки в проектных решениях, тем дороже обходится их исправление; худший вариант — их обнаружение на этапе внедрения. Таким образом, чем раньше группы тестирования начнут выявлять ошибки в АИС, тем ниже стоимость работы над системой. Время на тестирование системы и на исправление обнаруженных ошибок должно быть предусмотрено не только на этапе разработки, но и на этапе проектирования. Облегчить и увеличить эффективность тестирования призва- ны специальные системы отслеживания ошибок. Их использова- ние позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффектив- ность исправления ошибок, видеть наиболее нестабильные ком- поненты системы, а также поддерживать связь между группой разработчиков и группой тестирования. Результаты обследования представляют объективную основу для формирования технического задания на АИС [16—18]. Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для раз- работки автоматизированной системы управления. При разработке технического задания (ТЗ) необходимо ре- шить следующие задачи: • установить общую цель создания АИС; • установить общие требования к проектируемой системе; • разработать и обосновать требования, предъявляемые к ин- формационному, математическому, программному, техни- ческому и технологическому обеспечению; • определить состав подсистем и функциональных задач; • разработать и обосновать требования, предъявляемые к подсистемам; • определить этапы создания системы и сроки их выполнения; • провести предварительный расчет затрат на создание сис- темы и определить уровень экономической эффективности ее внедрения; • определить состав исполнителей. Типовые требования к составу и содержанию технического задания приведены в табл. 1.6.
50 Глава 1. Проектирование АИС Таблица 1.6. Состав и содержание технического задания (ГОСТ 34.602—89) Раздел Содержание Общие сведения Полное наименование системы и ее условное обозначение. Шифр темы или шифр (номер) договора. Наименование предприятий разработчика и заказчика системы, их реквизиты. Перечень документов, на основании которых создается ИС. Плановые сроки начала и окончания работ. Сведения об источниках и порядке финансирования работ. Порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств Назначение и цепи созда- ния (развития) системы Вид автоматизируемой деятельности. Перечень объектов, на которых предполагается использование системы. Наименования и требуемые значения технических, технологиче- ских, производственно-экономических и др. показателей объек- та, которые должны быть достигнуты при внедрении ИС Характеристика объектов автоматизации Краткие сведения об объекте автоматизации. Сведения об условиях эксплуатации и характеристиках окру- жающей среды Требования к системе Требования к системе в целом: • требования к структуре и функционированию системы (пере- чень подсистем, уровни иерархии, степень централизации, спо- собы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы разви- тия системы); • требования к персоналу (численность пользователей, квали- фикация, режим работы, порядок подготовки); • показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров) • требования к надежности, безопасности, эргономике, транс- портабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внеш- них воздействий, к патентной чистоте, по стандартизации и уни- фикации. Требования к функциям (по подсистемам): • перечень подлежащих автоматизации задач; • временной регламент реализации каждой функции; • требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точно- сти, достоверности выдачи результатов; • перечень и критерии отказов. Требования к видам обеспечения: • математическому (состав и область применения математиче- ских моделей и методов, типовых и разрабатываемых алго- ритмов);
1.6. Методология и технология проектирования АИС 51 Окончание табл. 1.6 Раздел Содержание • информационному (состав, структура и организация данных, обмен данными между компонентами системы, информацион- ная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информа- ционных массивов, процедуры придания юридической силы вы- ходным документам); • лингвистическому (языки программирования, языки взаимо- действия пользователей с системой, системы кодирования, языки ввода-вывода); • программному (независимость программных средств от плат- формы, качество программных средств и способы его контро- ля, использование фондов алгоритмов и программ); • техническому; • метрологическому; • организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала); • методическому (состав нормативно-технической докумен- тации) Состав и содержание работ по созданию системы Перечень стадий и этапов работ. Сроки исполнения. Состав организаций-исполнителей работ. Вид и порядок экспертизы технической документации. Программа обеспечения надежности. Программа метрологического обеспечения Порядок контроля и прием- ки системы Виды, состав, объем и методы испытаний системы. Общие требования к приемке работ по стадиям. Статус приемной комиссии Требования к составу и со- держанию работ по подго- товке объекта автоматиза- ции к вводу системы в дей- ствие Преобразование входной информации к машиночитаемому виду. Изменения в объекте автоматизации. Сроки и порядок комплектования и обучения персонала Требования к документиро- ванию Перечень подлежащих разработке документов. Перечень документов на машинных носителях Источники разработки Документы и информационные материалы, на основании кото- рых разрабатывается ТЗ и система Эскизный проект предусматривает разработку предваритель- ных проектных решений по системе и ее частям. Выполнение эскизного проектирования не является строго обязательной ста- дией. Если основные проектные решения определены ранее или достаточно очевидны для конкретной АИС и объекта автомата-
52 Глава 1. Проектирование АИС зации, то эта стадия может быть исключена из общей последова- тельности работ. Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются: • функции АИС; • функции подсистем, их цели и ожидаемый эффект от вне- дрения; • состав комплексов задач и отдельных задач; • концепция информационной базы и ее укрупненная струк- тура; • функции системы управления базой данных; • состав вычислительной системы и других технических средств; • функции и параметры основных программных средств. По результатам проделанной работы оформляется, согласо- вывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных реше- ний и достаточном для дальнейшего выполнения работ по созда- нию системы. В соответствии с ГОСТ 19.102—77 стадия эскизного проек- тирования содержит два этапа: разработку эскизного проекта; утверждение эскизного проекта. Первый этап разработки состоит из: • предварительной разработки структуры входных и выход- ных данных; • уточнения методов решения задачи; • разработки общего описания алгоритма решения задачи; • разработки технико-экономического обоснования; • разработки пояснительной записки. При этом допускается объединение и исключение некоторых работ. Ниже приведен набор документов, который должен и может быть подготовлен по окончании эскизного проектирования. Обязательные документы: 1) уточненное техническое задание на проектирование и раз- работку АИС; 2) спецификация квалификационных требований на АИС; 3) комплект спецификаций требований на функциональные программные компоненты и описания данных; 4) спецификация требований на внутренние интерфейсы компонент и интерфейсы с внешней средой;
1.6. Методология и технология проектирования АИС 53 5) описание системы управления базой данных, структуры и распределения программных и информационных объектов в базе данных; 6) проект руководства по защите информации и обеспече- нию надежности функционирования АИС; 7) предварительный вариант руководства администратора АИС; 8) предварительный вариант руководства пользователя АИС; 9) уточненный план реализации проекта; 10) уточненный план управления обеспечением качества АИС; 11) пояснительная записка предварительного проекта АИС; 12) уточненный контракт (договор) с заказчиком на деталь- ное проектирование АИС. Документы, оформляемые по согласованию с заказчиком: 1) предварительное описание функционирования АИС; 2) схема потоков данных между функциональными компо- нентами АИС; 3) уточненная схема архитектуры АИС, взаимодействия программных и информационных компонент, организации вы- числительного процесса и распределения ресурсов; 4) описание показателей качества компонент и требований к ним по этапам разработки АИС; 5) отчет о технико-экономических показателях, графике реализации проекта, распределении ресурсов и бюджета; 6) таблица распределения специалистов по компонентам и по этапам работ; 7) аттестаты разработчиков на право использования техно- логии и средств автоматизации разработки АИС; 8) описание требований к составу и формам результирую- щих документов по этапам работ; 9) план отладки программных компонент, обеспечения ее методами и средствами автоматизации тестирования; 10) предварительное руководство для детального проектиро- вания, программирования и отладки компонент АИС; 11) предварительный план продажи и внедрения; 12) описание предварительной структуры базы данных. На основе технического задания и эскизного проекта разра- батывается технический проект АИС. Технический проект системы — это техническая документа- ция, содержащая общесистемные проектные решения, алгорит- мы решения задач, а также оценку экономической эффективно-
54 Глава 1. Проектирование АИС сти АИС и перечень мероприятий по подготовке объекта к вне- дрению. На этом этапе осуществляется комплекс научно-исследова- тельских и экспериментальных работ для выбора основных про- ектных решений и расчет экономической эффективности систе- мы. Состав и содержание технического проекта приведены в табл. 1.7. Таблица 1.7. Содержание технического проекта Раздел Содержание Пояснительная записка Основания для разработки системы. Перечень организаций разработчиков. Краткая характеристика объекта с указанием основных техни- ко-экономических показателей его функционирования и связей с другими объектами. Краткие сведения об основных проектных решениях по функцио- нальной и обеспечивающим частям системы Функциональная и органи- зационная структура сис- темы Обоснование выделяемых подсистем, их перечень и назначение. Перечень задач, решаемых в каждой подсистеме, с краткой ха- рактеристикой их содержания. Схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы Постановка задач и алго- ритмы решения Организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и вре- мя решения задачи, способы сбора и передачи данных, связь за- дачи с другими задачами, характер использования результатов решения, в которых они используются). Экономико-математическая модель задачи (структурная и раз- вернутая форма представления). Входная оперативная информация (характеристика показателей, диапазон изменения, формы представления). Нормативно-справочная информация (НСИ) (содержание и фор- мы представления). Информация, хранимая для связи с другими задачами. Информация, накапливаемая для последующих решений данной задачи. Информация по внесению изменений (система внесения измене- ний и перечень информации, подвергающейся изменениям). Алгоритм решения задачи (последовательность этапов расчета, схема, расчетные формулы). Контрольный пример (набор заполненных данными форм вход- ных документов, условные документы с накапливаемой и храни- мой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соот- ветствии с разработанным алгоритмом расчета)
1.6. Методология и технология проектирования АИС 55 Окончание табл. 1.7 Раздел Содержание Организация информаци- онной базы Источники поступления информации и способы ее передачи. Совокупность показателей, используемых в системе. Состав документов, сроки и периодичность их поступления. Основные проектные решения по организации фонда НСИ. Состав НСИ, включая перечень реквизитов, их определение, диа- пазон изменения и перечень документов НСИ. Перечень массивов НСИ, их объем, порядок и частота корректи- ровки информации. Структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда. Методы хранения, поиска, внесения изменений и контроля. Определение объемов и потоков информации НСИ. Контрольный пример по внесению изменений в НСИ. Предложения по унификации документации Альбом форм документов Отсутствует Система математического обеспечения Обоснование структуры математического обеспечения. Обоснование выбора системы программирования. Перечень стандартных программ Принцип построения ком- плекса технических средств Описание и обоснование схемы технологического процесса обра- ботки данных. Обоснование и выбор структуры комплекса технических средств и его функциональных групп. Обоснование требований к разработке нестандартного оборудо- вания. Комплекс мероприятий по обеспечению надежности функциони- рования технических средств Расчет экономической эффективности системы Сводная смета затрат, связанных с эксплуатацией систем. Расчет годовой экономической эффективности, источниками ко- торой являются оптимизация производственной структуры хо- зяйства (объединения), снижение себестоимости продукции за счет рационального использования производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений Мероприятия по подготов- ке объекта к внедрению системы Перечень организационных мероприятий по совершенствованию бизнес-процессов. Перечень работ по внедрению системы, которые необходимо вы- полнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц Ведомость документов Отсутствует
56 Глава 1. Проектирование АИС На стадии «Рабочая документация» осуществляется создание программного продукта и разработка всей сопровождающей до- кументации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АИС в действие и ее эксплуатации, а также для поддержа- ния уровня эксплуатационных характеристик (качества) систе- мы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена. На стадии «Ввод в действие» для АИС устанавливают сле- дующие основные виды испытаний: предварительные испытания, опытная эксплуатация и приемочные испытания. При необходи- мости допускается дополнительно проведение других видов ис- пытаний системы и ее частей. В зависимости от взаимосвязей компонентов АИС и объекта автоматизации испытания могут быть автономные и комплекс- ные. В автономных испытаниях участвуют компоненты системы. Их проводят по мере готовности частей системы к сдаче в опыт- ную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных компонентов (подсистем) или для системы в целом. Для планирования проведения всех видов испытаний разра- батывается документ «Программа и методика испытаний». Раз- работчик документа устанавливается в договоре или ТЗ. В каче- стве приложения в документ могут включаться тесты или кон- трольные примеры. Отладка — наиболее трудоемкий процесс проектирования. Скрытые ошибки иногда проявляются после многолетней экс- плуатации системы. Полностью избежать ошибок невозможно, что обусловлено астрономическим числом вариантов работы системы. Проверить их все на правильность работы в обозримые сроки практически невозможно. Затраты на выявление и устранение ошибок на более позд- них этапах проектирования возрастают примерно экспоненци- ально (рис. 1.10) [8, 16, 18]. Исследователи насчитывают 169 типов ошибок, сведенных в 19 больших классов: 1) логические; 2) ошибки манипулирования данными; 3) ошибки ввода-вывода; 4) ошибки в вычислениях; 5) ошибки в пользовательских интерфейсах;
1.6. Методология и технология проектирования АИС 57 Рис. 1.10. Относительные затраты на обнаружение и исправление одной ошибки 6) ошибки в операционной системе и вспомогательных про- граммах; 7) ошибки компоновки; 8) ошибки в межпрограммных интерфейсах; 9) ошибки в интерфейсах «Программа — системное ПО»; 10) ошибки при обращении с внешними устройствами; 11) ошибки сопряжения с базой данных (БД); 12) ошибки инициализации БД; 13) ошибки изменений по запросу извне; 14) ошибки, связанные с глобальными переменными; 15) повторяющиеся ошибки; 16) ошибки в документации; 17) нарушение технических требований; 18) неопознанные ошибки; 19) ошибки оператора. Не все ошибки исходят от разработчика. По данным разных исследователей, от 6 до 19 % ошибок порождаются ошибками в документации [8, 16, 18]. Соотношение разработки и испытаний на различных этапах проектирования АИС приведено на рис. 1.11. Данная цепочка лишь условно «вытягивается» в линию. Внутри нее всегда существуют возвратные циклы. Для выявле- ния ошибок разработчики создают специальные тесты и прово- дят этап отладки. Если ошибок не найдено, это еще не означает, что их нет — может быть, тест оказался слишком слабым.
58 Глава 1. Проектирование АИС Техническое задание и требования к АИС Разработка Испытание Разработка требований к АИС Разработка программных модулей Комплексная отладка АИС Доработка по результатам испытаний главного конструктора Комплексирование модулей, разработка групп программ Разработка технического проекта АИС Проверка совместимости требований к системе в целом Проверка соответствия технологического проекта требованиям Испытание программных модулей Испытание качества решения функциональных задач Комплексные испытания по требованиям главного конструктора Заключительные приемо-сдаточные испытания АИС Эксплуатация АИС Рис. 1.11. Соотношение разработки и испытаний по этапам проектирования АИС Методика отладки учитывает симптомы возможных ошибок: • неверная обработка (неправильный ответ, результат) — до 30 %; • неверная передача управления — 16 %; • несовместимость программ с используемыми данными — 15 %; • несовместимость программ по пересылаемым данным — до 9 %. При разработке отладочных заданий решаются следующие задачи: • составление тестов; • выбор точек, зон и маршрутов контроля; • определение перечня контролируемых величин и порядка фиксации их значений;
1.6. Методология и технология проектирования АИС 59 • задание порядка тестирования; • оценка достоверности и трудоемкости отладки. Отлаживаемая программа должна хотя бы один раз прорабо- тать по каждой ветви алгоритма и при этом присвоить перемен- ным ряд значений, захватывая границы диапазона, несколько значений внутри него, нулевые значения и особые точки (если есть). Для специализированных систем разрабатывают специаль- ные языки отладки. Они могут содержать относительно неболь- шое число команд (20—30) с дополнительными настроечными параметрами для решения следующих задач: • управления выводом; • моделирования процесса исполнения отлаживаемой про- граммы; • выдачи состояния компонент памяти в процессе исполне- ния программ; • проверки условий достижения определенных состояний в процессе исполнения программы; • установления тестовых значений исходных данных; • осуществления условных переходов в тестировании в зави- симости от результатов исполнения других макрокоманд или различных тестов; • выполнения служебных операций по подготовке програм- мы к тестированию. Процесс отладки нельзя отнести к полностью формализован- ному, поэтому существуют эмпирические рекомендации по его проведению, которые приведены ниже. 1. Используйте семантический, заранее продуманный подход к отладке, планируйте процесс отладки и тщательно проекти- руйте тестовые наборы данных с наиболее простых вариантов, исключая наиболее вероятные источники ошибок. 2. Для упорядочения процесса тестирования собирайте и анализируйте информацию: • об особенностях и статистике ошибок; • о специфике исходных данных и последовательности из- менения переменных в программе и их взаимном влиянии; • о структуре алгоритма и особенностях его программной реализации. 3. В каждый момент времени определяйте местоположение только одной ошибки. 4. Используйте средства регистрации и отображения инфор- мации об ошибках, включая в программу специальный отладоч-
60 Глава 1. Проектирование АИС ный код для распечатки выборочных значений переменных, со- общений об окончании отдельных участков программы, трасси- ровки, логических условий и т. п. 5. Внимательно изучайте полученные выходные данные и сравнивайте их с ожидаемыми, заранее рассчитанными результа- тами. 6. Обращайте внимание на данные, тщательно анализируйте работу программы при использовании граничных значений и при неправильном вводе; контролируйте типы данных, диапазо- ны, размеры полей и точность. 7. Используйте анализ потоков данных и потоков управле- ния для проверки корректности и установления областей опре- деления данных для разных маршрутов выполнения программы. 8. Используйте одновременно различные средства отладки, не останавливаясь на одной возможности. Привлекайте автома- тизированные средства и одновременно ручную отладку и тести- рование, проверяя текст программы с точки зрения функциони- рования с учетом наиболее вероятных ошибок. 9. Документируйте все обнаруженные и исправленные ошибки, их отличия, местоположение и тип. Эта информация будет полезна для предупреждения будущих ошибок. 10. Измеряйте сложность программ. В программах с высокой сложностью высока вероятность ошибок спецификаций и про- ектирования, а с низкой сложностью — кодирования и канце- лярских ошибок. 11. Для повышения опыта и тренировки в отладке искусст- венно помещайте в программы ошибки. После определенного периода отладки программисту следует указать на оставшиеся и не обнаруженные им ошибки. Подобное «засевание» широко ис- пользуют для оценки числа необнаруженных ошибок (если рав- номерно обнаруживаются и исправляются и искусственные, и реальные ошибки, то по процентному соотношению обнаружен- ных внесенных и реальных ошибок можно предположить, сколь- ко еще их осталось). Предварительные испытания проводят для определения рабо- тоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления соответствующих документов об их го-
1.7. Типовое проектирование АИС 61 товности к испытаниям, а также после ознакомления персонала АИС с эксплуатационной документацией. Опытную эксплуатацию системы проводят с целью определе- ния фактических значений количественных и качественных ха- рактеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффек- тивности и корректировки, при необходимости, документации. Приемочные испытания проводят для определения соответст- вия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки систе- мы в постоянную эксплуатацию. 1.7. Типовое проектирование АИС Методы типового проектирования АИС достаточно подроб- но рассмотрены в литературе [8, 16—18]. Здесь приведены ос- новные определения и представлено задание для разработки проекта АИС методом типового проектирования. Как было отмечено выше, типовое проектирование АИС пред- полагает создание системы из готовых типовых элементов. При этом основным требованием метода является возможность де- композиции проектируемой АИС на множество составляющих компонентов (подсистем, комплексов задач, программных моду- лей и т. д.). Для реализации выделенных компонентов выбира- ются имеющиеся на рынке типовые проектные решения, кото- рые настраиваются на особенности конкретного предприятия. Типовое проектное решение (ТПР) — это тиражируемое (при- годное к многократному использованию) проектное решение. ТПР классифицируются по уровням декомпозиции системы. Приняты следующие классы: • элементные ТПР. Типовое решение задачи или отдельного вида обеспечения задачи (информационного, программно- го, технического, технологического, математического, ор- ганизационного); • подсистемные ТПР. Решение является отдельной функцио- нально полной подсистемой; • объектные ТПР. Типовой проект, включающий полный набор функциональных и обеспечивающих подсистем АИС (для вида деятельности, отрасли и т. п.).
62 Глава 1. Проектирование АИС ТПР должно содержать не только функциональные элементы (программные или аппаратные), но и документацию с деталь- ным описанием состава компонентов и процедуры настройки в соответствии с задачами проекта. В табл. 1.8 приведены особенности различных классов ТПР. Таблица 1.8. Достоинства н недостатки ТПР Класс ТПР. реализация ТПР Достоинства Недостатки Элементные ТПР. Библиотеки методоори- ентированных программ Обеспечивается применение мо- дульного подхода к проектирова- нию и документированию АИС Большие затраты времени на сопряжение разнородных эле- ментов вследствие информа- ционной, программной и тех- нической несовместимости. Большие затраты времени на доработку ТПР отдельных эле- ментов Подсистемные ТПР. Пакеты прикладных программ Достигается высокая степень ин- теграции элементов АИС. Позволяют осуществлять модуль- ное проектирование; параметри- ческую настройку программных компонентов на различные объ- екты управления. Обеспечивают сокращение затрат на проектирование и программи- рование взаимосвязанных компо- нентов; хорошее документирова- ние отображаемых процессов об- работки информации Адаптивность ТПР недостаточ- на с позиции непрерывного ин- жиниринга деловых процессов. Возникают проблемы в ком- плексировании разных функ- циональных подсистем, особенно в случае использова- ния решений нескольких произ- водителей программного обес- печения Объектные ТПР. Отраслевые проекты ИС Комплексирование всех компо- нентов АИС за счет методологи- ческого единства и информаци- онной, программной и техниче- ской совместимости. Открытость архитектуры позволяет устанавливать ТПР на разных программно-технических платформах. Масштабируемость допускает конфигурацию ИС для перемен- ного числа рабочих мест. Конфигурируемость позволяет выбирать необходимое подмно- жество компонентов Проблемы привязки типового проекта к конкретному объекту управления, что вызывает в не- которых случаях даже необхо- димость изменения организа- ционно-экономической струк- туры объекта автоматизации
1.7. Типовое проектирование АИС 63 Для реализации типового проектирования могут использо- ваться два подхода: параметрически-ориентированное и модель- но-ориентированное проектирование. Параметрически-ориентированное проектирование включает следующие этапы: • определение критериев оценки пригодности пакетов при- кладных программ (ППП) для решения поставленных задач; • анализ и оценка доступных ППП по сформулированным критериям; • выбор и закупка наиболее подходящих пакетов; • настройка параметров (доработка) закупленных ППП. Ниже приведены группы, на которые делятся критерии оценки ППП: • назначение и возможности пакета; • характеристики и свойства пакета; • требования к аппаратным и программным средствам; • документация пакета; • финансовые факторы; • особенности установки и настройки пакета; • особенности эксплуатации пакета; • обязательства поставщика по внедрению и сопровождению пакета; • оценка качества пакета и опыт его использования; • перспективы развития пакета. Внутри каждой группы критериев выделяется некоторое под- множество частных показателей, детализирующих каждый из приведенных аспектов анализа выбираемых ППП [8, 16—18]. Числовые значения показателей для конкретных ППП устанав- ливаются экспертами по выбранной шкале оценок. На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормирован- ные взвешивающие коэффициенты также получаются эксперт- ным путем. Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой АИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечи- вать единые средства для работы с моделями типовой АИС и ав- томатизируемого объекта (предприятия).
64 Глава 1. Проектирование АИС На рис. 1.12 приведена конфигурация АИС, проектируемая на основе модельно-ориентированной технологии [18]. Специальная база метаданных — репозиторий — содержит модель объекта автоматизации, на основе которой осуществляет- ся конфигурирование программного обеспечения. Модель объ- екта автоматизации строится с помощью специального про- граммного инструментария (например, SAP Business Engineering Workbench — BEW, BAAN Enterprise Modeler). Альтернативный способ — создание системы на базе типо- вой модели из репозитория, который поставляется вместе с про- граммным продуктом и расширяется по мере накопления опыта проектирования АИС для различных отраслей и типов произ- водства. Репозиторий содержит базовую (ссылочную) модель АИС, типовые (референтные) модели определенных классов АИС, мо- дели конкретных АИС предприятий. Типовая \ модель: \ Типовая ' модель: Типовая модель: Объекты Функции Процессы Орг, структура Рис. 1.12. Конфигурация АИС на основе модельно-ориентированной технологии
1.7. Типовое проектирование АИС 65 Базовая модель АИС содержит описание бизнсс-функций, бизнес-процессов, бизнес-объсктов, бизнес-правил, организаци- онной структуры, которые поддерживаются программными мо- дулями типовой АИС. Типовые модели описывают конфигурации АИС для опреде- ленных отраслей или типов производства. Модель конкретного предприятия строится либо путем вы- бора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enter- prise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engi- neering Workbench). Построенная модель предприятия в виде метаописания хра- нится в репозитории и при необходимости может быть откор- ректирована. На основе этой модели автоматически осуществля- ются конфигурирование и настройка АИС. Бизнес-правила определяют условия корректности совместно- го применения различных компонентов АИС и используются для поддержания целостности создаваемой системы. Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнсс-функций. Для отображения процессов используется модель управления собы- тиями. Модель бизнес-процессов позволяет выполнить настрой- ку программных модулей — приложений АИС в соответствии с характерными особенностями конкретного предприятия. Модели бизнес-объектов используются для интеграции при- ложений, поддерживающих исполнение различных бизнес-про- цессов. Модель организационной структуры предприятия представля- ет собой традиционную иерархическую структуру подчинения подразделений и персонала. Внедрение типовой АИС начинается с анализа требований, которые выявляются на основе результатов предпроектного об- следования объекта автоматизации. Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора про- граммного продукта на базе имеющихся в нем референтных моде- лей строится предварительная модель АИС, в которой отражают- ся все особенности реализации АИС для конкретного предпри-
66 Глава 1. Проектирование АИС ятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программ- ных средств или потребуют разработки с помощью имеющихся в составе типовой АИС инструментальных средств [18, 19]. Реализация типового проекта предусматривает выполнение следующих операций: • установку глобальных параметров системы; • задание структуры объекта автоматизации; • определение структуры основных данных; • задание перечня реализуемых функций и процессов; • описание интерфейсов; • описание отчетов; • настройку авторизации доступа; • настройку системы архивирования. Контрольные вопросы 1. Дайте определение информационной и автоматизированной инфор- мационной систем. 2. Приведите примеры классификационных признаков и классификаций АИС. 3. Перечислите виды обеспечения (обеспечивающих подсистем) АИС. 4. Дайте определение архитектуры АИС. 5. Перечислите этапы и стадии жизненного цикла АИС. 6. Перечислите модели жизненного цикла АИС. 7. Перечислите требования технологии проектирования АИС. 8. Объясните разницу в терминологии «методология» и «технология» проектирования. 9. Назовите этапы типового проектирования. 10. Перечислите достоинства и недостатки типового проектного решения. Литература 1. Попов И. И. Автоматизированные информационные системы (по об- ластям применения): учеб, пособие / под ред. К. И. Курбакова. М.: Изд-во Рос. экон, акад., 1998. 103 с. 2. Месарович М., Мако Д., Такахара Ю. Теория иерархических много- уровневых систем. М.: Мир, 1974. 3. Информационные технологии: толковый словарь аббревиатур / Э. Наян; пер. с англ. К. Г. Финогенова. М.: БИНОМ; Лаборатория знаний, 2003. 646 с.
1.7. Типовое проектирование АИС 67 4. ГОСТ 34-003—90. Автоматизированные системы. Термины и опреде- ления. Комплекс стандартов на автоматизированные системы. ИПК «Изда- тельство стандартов», 1997. 5. Избачков Ю. С., Петров В. Н. Информационные системы. СПб.: Питер, 2005. 656 с. 6. Ковалев С. М., Ковалев В. М. Современные методологии описания бизнес-процессов: просто о сложном. Ч. 6. // Консультант директора. 2004. № 12. 7. Кузнецов С. Д. Основы современных баз данных. Информацион- но-аналитические материалы Центра Информационных технологий, www/citmgu.ru. 8. Проектирование экономических информационных систем / Г. Н. Смир- нова и др. М.: Финансы и статистика, 2003. 512 с. 9. Балдин К. В., Уткин В. Б. Информационные системы в экономике: учебник. 2-е изд. М.: Дашков и К°, 2006. 395 с. 10. Информационные технологии управления: учеб, пособие для ву- зов / под ред. проф. Г. А. Титоренко. 2-е изд., доп. М.: ЮНИТИ-ДАНА, 2004. 439 с. 11. IEEE Std. 610.12—1990. 12. ГОСТ 34.601—90. Автоматизированные системы. Стадии создания. Комплекс стандартов на автоматизированные системы. ИПК «Издательство стандартов», 1997. 13. Грабауров В. А. Информационные технологии для менеджеров. 2-е изд., перераб. и доп. М.: Финансы и статистика, 2005. 512 с. 14. Буч Г., Рамбо Д., Джекобсон А. Язык UML: Руководство пользова- теля. Пер. с англ. М.: ДМК, 2000. 142 с. 15. Балдин К. В. Моделирование жизненного цикла сложных систем. Ч. I и II. М.: Издательство РДЛ, 2000. 16. Трояновский В. М. Проектирование информационных систем. М.: МИЭТ, 2002. 108 с. 17. Вендров А. М. Проектирование программного обеспечения эконо- мических информационных систем. 2-е изд., перераб. и доп. М.: Финансы и статистика, 2005. 180 с. 18. Грекул В. И. Проектирование информационных систем, http://www.intuit.ru. 19. Модели и методологии разработки информационных систем, http://www.stormsystemst.ru. 20. Верников Г. Н. Основы методологии обследования организаций, http: //www.vernikov.ru. 21. Емельянов А. А., Власов Е. А. Информационное моделирование в экономических системах: учеб, пособие. М.: МЭСИ, 2003. 22. Clegg, Dai, and Richard Barker. CASE-Method Fast-track. A RAD Approach. Adison-Wesley, 1994.
Глава 2 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ АИС С ПРИМЕНЕНИЕМ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ 2.1. Этапы анализа предметной области Проект разработки АИС для любой предметной области и любого предприятия следует рассматривать как крупные инве- стиции, которые должны окупиться за счет повышения эффек- тивности деятельности, поэтому сначала необходимо определить, какие именно функциональные области и какие типы производ- ства нужно охватить, т. е. провести анализ предметной области АИС [ 1]. В свою очередь, для эффективного анализа предметной области необходимо: 1) разработать стратегию комплексной автоматизации; 2) провести анализ деятельности предприятия; 3) рассмотреть вопросы реорганизации деятельности. Рассмотрим каждый из пунктов подробнее. Понятие страте- гии автоматизации основывается на базовых принципах автома- тизации предприятия, которая включает в себя следующие ком- поненты: • цели — области деятельности предприятия и последова- тельность, в которой они будут автоматизированы; • способ автоматизации — по участкам, направлениям, ком- плексная автоматизация; • долгосрочная техническая политика — комплекс внутрен- них стандартов, поддерживаемых на предприятии; • ограничения; • процедура управления изменениями плана.
2.1. Этапы анализа предметной области 69 Стратегия автоматизации в первую очередь должна соответст- вовать приоритетам и стратегии (задачам) бизнеса и определять пути достижения этого соответствия. Стратегический план авто- матизации составляется с учетом: • среднего периода между сменой технологий основного производства; • среднего времени жизни выпускаемых предприятием про- дуктов и их модификаций; • анонсированных долгосрочных планов поставщиков техни- ческих решений в плане их развития; • сроков амортизации используемых систем; • стратегического плана развития предприятия, включая пла- ны слияния и разделения, изменения численности и но- менклатуры выпускаемой продукции; • планируемых изменений функций персонала. Автоматизация — один из способов достижения стратегиче- ских бизнес-целей, а не процесс, развивающийся по своим внутренним законам. Во главе стратегии автоматизации должна лежать стратегия бизнеса предприятия: миссия предприятия, направления и модель бизнеса. Таким образом, стратегия авто- матизации представляет собой план, согласованный по срокам и целям со стратегией организации. Второй важной особенностью автоматизации является сте- пень соответствия приоритетов автоматизации стратегии бизне- са, т. е. достижению поставленных целей, к которым можно от- нести: • снижение стоимости продукции; • увеличение количества или ассортимента; • сокращение цикла: разработка новых товаров и услуг, вы- ход на рынок; • переход от производства «на склад» к производству «под конкретного заказчика» с учетом индивидуальных требова- ний и т. д. Стратегические цели бизнеса с учетом ограничений (финан- совых, временных и технологических) конвертируются в страте- гический план автоматизации предприятия. Автоматизация предприятия является инвестиционной дея- тельностью и к ней применимы все подходы оценки эффектив- ности инвестиций. К основным ограничениям, которые необходимо учитывать при выборе стратегии автоматизации, относятся: финансовые;
70 Глава 2. Анализ предметной области АИС... временные; ограничения, связанные с влиянием человеческого фактора; технические. Финансовые ограничения определяются величиной инвести- ций, которые предприятие способно вложить в развитие автома- тизации. Этот тип ограничений наиболее универсален, так как остальные три вида могут быть частично конвертированы в фи- нансовые. Временные ограничения обычно связаны со сменой техноло- гий основного производства, рыночной стратегией предприятия, государственным регулированием экономики. К ограничениям, связанным с влиянием человеческого факто- ра, относятся корпоративная культура или отношение персонала к автоматизации и особенности рынка труда в части трудового законодательства. Технические ограничения определяются степенью материаль- ного и морального износа технического парка предприятия (ор- ганизации). Кроме рассмотренных выше ограничений, существуют ти- пичные проблемы, возникающие при разработке стратегии авто- матизации и, как правило, связанные со следующими факторами: • состоянием рынка информационных технологий; • определением эффективности инвестиций в информацион- ные технологии; • необходимостью реорганизации деятельности предприятия при внедрении информационных технологий. Под анализом деятельности предприятия здесь понимается сбор и представление информации о деятельности предприятия в фор- мализованном виде, пригодном для принятия решения о разра- ботке определенного класса АИС. В зависимости от выбранной стратегии автоматизации предприятия технологии сбора и пред- ставления информации могут быть различными. Итоговое пред- ставление информации на этапе анализа деятельности играет одну из ключевых ролей во всей дальнейшей работе. Желательно, что- бы анализ предприятия закончился построением набора моделей, соответствующих стандартам IDEF (будут рассмотрены далее). Реорганизация деятельности преследует, как правило, цель повышения эффективности деятельности предприятия в целом и может предусматривать применение методологий BSP, TQM или BPR.
2.1. Этапы анализа предметной области 71 Методология BSP (см. также гл. 1) определяется как «подход, помогающий предприятию определить план создания информа- ционных систем, удовлетворяющих его ближайшим и перспек- тивным информационным потребностям». Информация является одним из основных ресурсов и должна планироваться в масшта- бах всего предприятия, АИС должна проектироваться независимо от текущего состояния и структуры предприятия. BSP основыва- ется на нисходящем анализе информационных объектов и регла- ментирует 13 этапов выполнения работ. Подход TQM (Total Quality Management) успешно применял- ся при реорганизации предприятий еще в середине XX в. В ос- нове подхода лежит очевидная концепция управления качеством выпускаемой продукции. Качество должно быть направлено на удовлетворение текущих и будущих потребностей потребителя как самого важного звена производственной линии. Достижение соответствующего уровня качества требует постоянного совер- шенствования производственных процессов. Для решения этой задачи Э. Демингом было предложено 14 принципов, в совокуп- ности составляющих теорию управления качеством и примени- мых для предприятий произвольных типов и различных масшта- бов. Безусловно, этих принципов недостаточно для полного ре- шения стоящих перед современными предприятиями проблем, тем не менее они являются основой трансформации промыш- ленности Японии и США. BPR (Business Process Reengineering) — реинжиниринг биз- нес-процессов — определяется как фундаментальное переосмыс- ление и радикальное перепланирование бизнес-процессов ком- паний, имеющее целью резкое улучшение показателей их дея- тельности, таких как затраты, качество, сервис и скорость. При этом используются следующие положения. 1. Несколько работ объединяются в одну. 2. Исполнителям делегируется право по принятию решений. 3. Этапы процесса выполняются в естественном порядке. 4. Реализуются различные версии процесса. 5. Работа выполняется там, где ее целесообразно делать (вы- ход работы за границы организационных структур). 6. Снижаются доли работ по проверке и контролю. 7. Минимизируется количество согласований.
72 Глава 2. Анализ предметной области АИС... 8. Ответственный менеджер является единственной точкой контакта с клиентом процесса. 9. Используются и централизованные и децентрализованные операции. Для того чтобы выполнить пп. 1—9, необходимо использо- вать так называемый «инжиниринговый подход» [2]. 2.2. Реинжиниринг бизнес-процессов Организационный анализ компании при таком подходе про- водится по определенной схеме с помощью полной бизнес-модели компании. Компания рассматривается как целевая, открытая, социально-экономическая система, принадлежащая иерархиче- ской совокупности открытых внешних надсистем (рынок, госу- дарственные учреждения и пр.) и внутренних подсистем (отде- лы, цеха, бригады и пр.). Возможности компании определяются характеристиками ее структурных подразделений и организаци- ей их взаимодействия. На рис. 2.1 представлена обобщенная схе- ма организационной бизнес-модели [3]. Рис. 2.1. Обобщенная схема организационного бизнес-моделирования
2.2. Реинжиниринг бизнес-процессов 73 Построение бизнес-модели компании начинается с модели- рования ее взаимодействия с внешней средой, т. е. с определе- ния миссии компании. Миссия согласно стандарту ISO 15704 — это: 1) деятельность, осуществляемая предприятием для того, что- бы выполнить функцию, для которой оно было учреждено, — предоставление заказчикам продукта или услуги; 2) механизм, с помощью которого предприятие реализует свои цели и задачи. Миссия компании по удовлетворению социально значимых потребностей рынка определяется как компромисс интересов рынка и компании. При этом миссия как атрибут открытой сис- темы разрабатывается, с одной стороны, исходя из рыночной конъюнктуры и позиционирования компании относительно дру- гих участников внешней среды, а с другой — исходя из объек- тивных возможностей компании и ее субъективных ценностей, ожиданий и принципов. Миссия является своеобразной мерой устремлений компании и, в частности, определяет рыночные претензии компании (предмет конкурентной борьбы). Определе- ние миссии позволяет сформировать дерево целей компании — иерархические списки уточнения и детализации миссии. Дерево целей формирует дерево стратегий — иерархические списки уточнения и детализации целей. При этом на корпора- тивном уровне разрабатываются стратегии роста, интеграции и инвестиции бизнесов. Блок бизнес-стратегий определяет продук- товые и конкурентные стратегии, а также стратегии сегментации и продвижения. Ресурсные стратегии определяют стратегии при- влечения материальных, финансовых, человеческих и информа- ционных ресурсов. Функциональные стратегии определяют стра- тегии в организации компонентов управления и этапов жизнен- ного цикла продукции. Одновременно выясняется потребность и предмет партнерских отношений (субподряд, сервисные услуги, продвижение и пр.). Это позволяет обеспечить заказчикам необ- ходимый продукт требуемого качества, в нужном количестве, в нужном месте, в нужное время и по приемлемой цене. При этом компания может занять в партнерской цепочке создаваемых цен- ностей оптимальное место, где ее возможности и потенциал бу- дут использоваться наилучшим образом. Это дает возможность сформировать бизнес-потенциал компании — набор видов ком- мерческой деятельности, направленный на удовлетворение по- требностей конкретных сегментов рынка.
74 Глава 2. Анализ предметной области АИС... Далее, исходя из специфики каналов сбыта, формируется первоначальное представление об организационной структуре (определяются центры коммерческой ответственности). Возни- кает понимание основных ресурсов, необходимых для воспроиз- водства товарной номенклатуры. Бизнес-потенциал, в свою очередь, определяет функционал компании — перечень бизнес-функций, функций менеджмента и функций обеспечения, требуемых для поддержания на регуляр- ной основе указанных видов коммерческой деятельности. Кроме того, уточняются необходимые для этого ресурсы (материаль- ные, человеческие, информационные) и структура компании. Построение бизнес-потенциала и функционала компании позволяет с помощью матрицы проекций определить зоны от- ветственности менеджмента. Матрица проекций — модель, представленная в виде матри- цы, задающей систему отношений между классификаторами в любой их комбинации. Матрица коммерческой ответственности закрепляет ответст- венность структурных подразделений за получение дохода в ком- пании от реализации коммерческой деятельности. Ее дальнейшая детализация (путем выделения центров финансовой ответствен- ности) обеспечивает построение финансовой модели компании, что, в свою очередь, позволяет внедрить систему бюджетного управления. Матрица функциональной ответственности закрепляет ответст- венность структурных звеньев (и отдельных специалистов) за вы- полнение бизнес-функций при реализации процессов коммерче- ской деятельности (закупка, производство, сбыт и пр.), а также функций менеджмента, связанных с управлением этими процес- сами (планирование, учет, контроль в области маркетинга, фи- нансов, управления персоналом и пр.). Дальнейшая детализация матрицы (до уровня ответственности отдельных сотрудников) позволит получить функциональные обязанности персонала, что в совокупности с описанием прав, обязанностей, полномочий обеспечит разработку пакета должностных инструкций. Описание бизнес-потенциала, функционала и соответствую- щих матриц ответственности представляет собой статическое описание компании. При этом процессы, протекающие в компа- нии, идентифицируются, классифицируются и закрепляются за исполнителями (будущими хозяевами этих процессов) [2].
2.2. Реинжиниринг бизнес-процессов 75 На этом этапе бизнес-моделирования формируется обще- признанный набор основополагающих внутрифирменных регла- ментов [3|: • базовое Положение об организационно-функциональной структуре компании; • пакет Положений об отдельных видах деятельности (фи- нансовой, маркетинговой и т. д.); • пакет Положений о структурных подразделениях (цехах, отделах, секторах, группах и т. п.); • должностные инструкции. Это вносит прозрачность в деятельность компании за счет четкого разграничения и документального закрепления зон от- ветственности менеджеров. Дальнейшее развитие (детализация) бизнес-модели происхо- дит на этапе динамического описания компании на уровне процесс- ных потоковых моделей. Процессная потоковая модель [3] — это модель, описывающая процесс последовательного во времени преобразования матери- альных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. Снача- ла (на верхнем уровне) описывается логика взаимодействия уча- стников процесса, а затем (на нижнем уровне) — технология ра- боты отдельных специалистов на своих рабочих местах (рис. 2.2). Рис. 2.2. П отоковая процессная модель
76 Глава 2. Анализ предметной области АИС... Завершается организационное бизнес-моделирование разра- боткой модели структур данных, которая определяет перечень и форматы документов, сопровождающих процессы в компании, а также задает форматы описания объектов внешней среды, ком- понентов и регламентов самой компании. При этом создается система справочников, на основании которых получают пакеты необходимых документов и отчетов. Такой подход позволяет описать деятельность компании с помощью универсального множества управленческих регистров (цели, стратегии, продукты, функции, организационные звенья и т. д.). Управленческие регистры по своей структуре представляют собой иерархические классификаторы. Объединяя классифика- торы в функциональные группы и закрепляя между собой эле- менты различных классификаторов с помощью матричных про- екций, можно получить полную бизнес-модель компании. При этом происходит процессно-целевое описание компании, позволяющее получить взаимосвязанные ответы на следующие вопросы: зачем, что, где, кто, как, когда, кому, сколько (рис. 2.3). Рис. 2.3. Основные этапы процессно-целевого описания компании Следовательно, полная бизнес-модель компании [3] — это со- вокупность функционально ориентированных информационных моделей, обеспечивающая взаимосвязанные ответы на перечис- ленные выше вопросы (рис. 2.4).
2.2. Реинжиниринг бизнес-процессов 77 Рис. 2.4. Полная бизнсс-молель компании Таким образом, организационный анализ предполагает по- строение комплекса взаимосвязанных информационных моде- лей компании, который включает: • стратегическую модель целеполагания (отвечает на вопро- сы: зачем компания занимается именно этим бизнесом, почему предполагает быть конкурентоспособной, какие цели и стратегии для этого необходимо реализовать); • организационно-функциональную модель (отвечает на во- прос: кто — что делает в компании и кто за что отвечает); • функционально-технологическую модель (отвечает на во- прос: что — как реализуется в компании); • процессно-ролевую модель (отвечает на вопрос: кто — что — как — кому); • количественную модель (отвечает на вопрос: сколько необ- ходимо ресурсов); • модель структуры данных (отвечает на вопрос: в каком виде описываются регламенты компании и объекты внеш- него окружения).
78 Глава 2. Анализ предметной области АИС... Представленная совокупность моделей обеспечивает необхо- димую полноту и точность описания компании и позволяет вы- рабатывать понятные требования к проектируемой информаци- онной системе. 2.3. Методы сбора материалов обследования Для построения рассмотренных выше моделей необходимо получить и проанализировать соответствующую информацию и здесь существуют разнообразные методы сбора данных (материа- лов) обследования [2—5]. Метод бесед и консультаций с руководителями чаще всего про- водится в форме обычной беседы с руководителями предприятий и подразделений или в форме деловой консультации со специа- листами по вопросам, носящим глобальный характер и относя- щимся к определению проблем и стратегий развития и управле- ния предприятием. Метод опроса исполнителей на рабочих местах используется в процессе сбора сведений непосредственно у специалистов путем бесед, которые требуют тщательной подготовки. Заранее состав- ляют список сотрудников, с которыми намереваются беседовать, разрабатывают перечень вопросов о роли и назначении работ в деятельности объекта автоматизации, порядке их выполнения. Метод анализа операций заключается в расчленении рассмат- риваемого делового процесса и работы на составные части, зада- чи, расчеты, операции и даже элементы. После этого анализиру- ется каждая часть в отдельности, выявляется повторяемость от- дельных операций, многократное обращение к одной и той же операции, степень зависимости друг от друга. Метод анализа представленного материала применим, в основ- ном, при выяснении таких вопросов, на которые нельзя получить ответ от исполнителей. Как было сказано ранее (см. п. 1.4), «об- следование — это изучение и анализ оргструктуры предприятия», и процедура эта является обязательной при анализе предметной области АИС, причем проводить ее можно различными метода- ми. Рассмотрим наиболее употребительные. Метод фотографии рабочего дня исполнителя работ предпола- гает непосредственное участие проектировщиков и применение рассчитанного для регистрации данных наблюдения специаль-
2.3. Методы сбора материалов обследования 79 ного листа фотографии рабочего дня и распределения его между работами. Метод выборочного хронометража отдельных работ требует предварительной подготовки, известных навыков и наличия спе- циального секундомера. Данные хронометража позволяют уста- новить нормативы на выполнение отдельных операций и собрать подробный материал о технике осуществления некоторых работ. Метод личного наблюдения применим, если изучаемый во- прос понятен по существу и необходимо лишь уточнение дета- лей без существенного отрыва исполнителей от работы. Метод документальной инвентаризации управленческих работ заключается в том, что на каждую работу в отдельности откры- вается специальная карта обследования, в которой приводятся все основные данные о регистрируемой работе или составляе- мых документах. Метод ведения индивидуальных тетрадей — дневников. Записи в дневнике производятся исполнителем в течение месяца еже- дневно, сразу же после выполнения очередной работы. Метод самофотографии рабочего дня заключается в том, что наблюдение носит более детальный характер и происходит в ко- роткий срок. Этот метод дает сведения о наиболее трудоемких или типичных отдельных работах, которые используются для оп- ределения общей трудоемкости выполнения всех работ. Расчетный метод применяется для определения трудоемкости и стоимости работ, подлежащих переводу на выполнение с по- мощью ЭВМ, а также для установления объемов работ по от- дельным операциям. Метод аналогии основан на отказе от детального обследова- ния какого-либо подразделения или какой-либо работы. Ис- пользование метода требует наличия тождественности и не ис- ключает общего обследования и выяснения таких аспектов, на которые аналогия не распространяется. На рис. 2.5 представлен вариант формы плана-графика вы- полнения работ [4]. № п/п Наименова- ние работы Код работы Исполнитель Дата начала Длительность выполнения Дата окончания Рис. 2.5. «Шапка» формы плана-графика выполнения работ по сбору материма обследования
80 Глава 2. Анализ предметной области АИС... 2.4. Формализация материалов обследования Сбор материалов обследования проводится с помощью стан- дартных форм и таблиц (рис. 2.6) |5]. Результатом прсдпроектного обследования является «Отчет об экспресс-обслсдовании предприятия». Его типовая структура приведена ниже. 1. Краткое схематичное описание бизнес-процессов: • управление закупками и запасами; • управление производством; • управление продажами; • управление финансовыми ресурсами. 2. Основные требования и приоритеты автоматизации. 3. Оценка необходимых для обеспечения проекта ресурсов заказчика. 4. Оценка возможности автоматизации, предложения по со- зданию автоматизированной системы с оценкой примерных сро- ков и стоимости. Рис. 2.6. Формализация материалов обследования
2.5. Методологии описания предметной области 81 Проведение предпроектного обследования решает следую- щие задачи: • предварительное выявление требований к будущей системе; • определение перечня целевых функций организации; • определение структуры организации; • анализ распределения функций по подразделениям и со- трудникам; • выявление функциональных взаимодействий между под- разделениями, информационных потоков внутри подразде- лений и между ними, внешних информационных воздейст- вий; • анализ существующих средств автоматизации организации. Информация, полученная в результате предпроектного об- следования, анализируется с помощью методов структурного и/или объектного анализа и используется для построения моде- лей деятельности организации. Модель организации предполагает построение двух видов мо- делей: 1) модели «как есть» («as is»), отражающей существующее на момент обследования положение дел в организации и описы- вающей, каким образом функционирует данная организация. Использование такой модели позволяет выявить узкие места и сформулировать предложения по улучшению; 2) модели «как должно быть» («to be»), отражающей пред- ставление о новых, преобразованных технологиях работы орга- низации. Каждая из моделей включает в себя полную функциональ- ную и информационную модель деятельности организации, а также модель, описывающую динамику поведения организации (в случае необходимости). 2.5. Методологии описания предметной области Бизнес-моделирование может быть реализовано с помощью различных методик, отличающихся подходами к моделированию организации. В соответствии с различными представлениями об организации принято различать методики объектные и функ- циональные (структурные) [5]. Сущность функционального подхода к моделированию биз- нес-процессов сводится к построению схемы технологического
82 Глава 2. Анализ предметной области АИС... процесса в виде последовательности операций, на входе и выхо- де которых отражаются объекты различной природы: материаль- ные и информационные объекты, используемые ресурсы, орга- низационные единицы. Достоинство функционального подхода заключается в на- глядности и понятности представления бизнес-процессов на раз- личных уровнях абстракции, что особенно важно на стадии вне- дрения разработанных бизнес-процессов в подразделениях пред- приятия. Существенным недостатком функционального подхода является некоторая субъективность детализации операций и, как следствие, большая трудоемкость в адекватном построении биз- нес-процессов. Объектно-ориентированный подход предполагает выделение классов объектов и определение действий, в которых участвуют объекты. При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются дейст- вия, и активные объекты (организационные единицы, конкрет- ные исполнители, информационные подсистемы), которые со- вершают эти действия. Такой подход позволяет выделять операции над объектами и решать задачи целесообразности существования самих объектов. Недостаток объектно-ориентированного подхода заключает- ся в меньшей наглядности конкретных процессов для лиц, при- нимающих решения. Вместе с тем выявленные операции в даль- нейшем могут быть представлены для наглядности в виде функ- циональных диаграмм. В настоящее время для проведения моделирования деловых и информационных процессов разработаны различные методо- логии и соответствующие инструментальные средства, большин- ство из которых имеют узкую направленность применения. Методологии функционального моделирования (диаграммы потоков данных, структурные диаграммы процессов) ориенти- рованы на отображение последовательности функций. При их использовании трудно определить конкретные альтернативы процессов, не видна схема взаимодействия объектов. Объектные модели, наоборот, отражают только обобщенную схему взаимо- действия объектов без детализации последовательности выпол- нения функций. Методологии объектно-ориентированного под- хода отражают объекты, функции и события, при которых объ- екты инициируют выполнение конкретных процессов; при этом теряется общая наглядность модели [2|.
2.5. Методологии описания предметной области 83 2.5.1. Функциональное моделирование бизнес-процессов с использованием стандарта IDEFO Методология 1DEF0 является развитием хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). IDEFO как стандарт был разработан в 1981 г. в рамках об- ширной программы автоматизации промышленных предприятий Integrated Computer Aided Manufacturing (ICAM) предложенной департаментом военно-воздушных сил США. Семейство стан- дартов унаследовало свое обозначение от названия этой про- граммы — ICAM DEFinition — IDEF. В процессе практической реализации участники программы ICAM столкнулись с необхо- димостью разработки новых методов анализа процессов взаимо- действия в промышленных системах. При этом, кроме усовер- шенствованного набора функций для описания бизнес-процес- сов, одним из требований к новому стандарту было наличие эф- фективной методологии взаимодействия в рамках «аналитик — специалист». Другими словами, новый метод должен был обес- печить групповую работу над созданием модели с непосредст- венным участием всех аналитиков и специалистов, занятых в рамках проекта [2, 5, 8, 11, 13]. Со времени появления стандарт IDEFO претерпел несколько незначительных изменений, в основном, ограничивающего ха- рактера; последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST). Графический язык IDEFO прост и гармоничен. В основе ме- тодологии лежат четыре основных понятия, первым из которых является понятие функционального блока (Activity Box). Функ- циональный блок графически изображается в виде прямоуголь- ника (рис. 2.7) и представляет собой некоторую конкретную функцию в рамках рассматриваемой системы [5, 8, 11, 13]. По требованиям стандарта название каждого функционального бло- ка должно быть сформулировано в глагольном наклонении (на- пример, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока имеет свое определенное значение (играет свою роль): • верхняя сторона имеет значение «Управление» (Control); • левая сторона имеет значение «Вход» (Input);
84 Глава 2. Анализ предметной области АИС... Управление Механизм Рис. 2.7. Функциональный блок • правая сторона имеет значение «Выход» (Output); • нижняя сторона имеет значение «Механизм» (Mechanism). Каждый функциональный блок в рамках единой рассматри- ваемой системы должен иметь свой уникальный идентификаци- онный номер. Второе основное понятие методологии IDEF0 — интерфейс- ная дуга (Arrow). Интерфейсные дуги также называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказыва- ет иное влияние на функцию, отображенную данным функцио- нальным блоком. Графическим отображением интерфейсной дуги является од- нонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требова- нию стандарта, наименование должно быть оборотом существи- тельного. С помощью интерфейсных дуг отображают различные объек- ты, в той или иной степени определяющие процессы, происхо- дящие в системе. Такими объектами могут быть элементы реаль- ного мира (детали, вагоны, сотрудники и т. д.) или потоки дан- ных и информации (документы, данные, инструкции и т. д.). Интерфейсные дуги бывают «входящими», «исходящими» и «управляющими» в зависимости от стороны блока, к которой они подходят. «Источником» (началом) и «приемником» (концом) функ- циональной дуги могут быть только функциональные блоки. При этом «источником» может быть только выходная сторона блока, а «приемником» — любая из трех остальных. Каждый функциональный блок должен иметь, по крайней мере, одну управляющую интерфейсную дугу (т. е. каждый про-
2.5. Методологии описания предметной области 85 цесс протекает по каким-то правилам) и одну исходящую (выда- ча некоторого результата). При построении диаграмм по стандарту IDEF0 необходимо правильно разделять входящие и управляющие интерфейсные дуги, что не всегда просто. На рис. 2.8 приведен пример диаграммы, изображающий функциональный блок «Обработать заготовку» [5, 8, II, 13]. Для получения детали рабочему выдают заготовку и технологические указания. Неверно считать, что технологические указания (ка- кой-то документ или документы) и заготовка являются входящими объектами. На самом деле в этом процессе заготовка обрабатыва- ется по правилам, отраженным в технологических указаниях, кото- рые должны изображаться управляющей интерфейсной дугой. Другой пример [5, 8, II, 13] приведен на рис. 2.9, где описы- вается процесс обработки и изменения главным технологом тех- нологических указаний. Здесь технологические указания отобра- Технологические указания Рабочий Рис. 2.8. Функциональный блок «Обработать заготовку» Новые промышленные стандарты Технологические указания Корректировать технологические указания АО Новые технологические указания Главный технолог Рис. 2.9. Функциональный блок «Корректировать технологические указания»
86 Глава 2. Анализ предметной области АИС... жаются входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, учитывая которые производятся изменения. Теперь понятно, что входящие и управляющие интерфейс- ные дуги имеют схожую природу. Тем не менее для систем одно- го класса всегда есть определенные разграничения. Так, напри- мер, в случае рассмотрения предприятий и организаций сущест- вуют пять основных видов объектов: • материальные потоки (детали, товары, сырье и т. д.); • финансовые потоки (наличные и безналичные, инвестиции и т. д.); • потоки документов (коммерческие, финансовые и органи- зационные); • потоки информации (информация, данные о намерениях, устные распоряжения и т. д.); • ресурсы (сотрудники, станки, машины и т. д.). При этом в разных случаях входящими и исходящими интер- фейсными дугами могут отображаться все виды объектов, управ- ляющими — только относящиеся к потокам документов и инфор- мации, а дугами-механизмами — только ресурсы [5, 7, 10, II, 13]. Одно из главных отличий стандарта 1DEF0 от других ме- тодологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram) — обязательное наличие управляющих интер- фейсных дуг. Третье основное понятие стандарта 1DEF0 — это декомпози- ция (Decomposition). Декомпозиция применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция дает возможность представлять модель систе- мы в виде иерархической структуры отдельных диаграмм. Это делает диаграммы менее перегруженными и легко читаемыми. Модель 1DEF0 всегда начинается с представления системы как единого целого — одного функционального блока с интер- фейсными дугами, входящими и выходящими за пределы рас- сматриваемой области. Такая диаграмма с одним функциональ- ным блоком называется контекстной диаграммой и обозначается идентификатором «АО». В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диа- граммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
2.5. Методологии описания предметной области 87 Определение и формализация цели разработки модели IDEF0 — важнейшие аспекты функционального моделирова- ния. Цель, прежде всего, определяет первоочередные области исследования. Так, моделирование деятельности одного и того же предприятия с целью разработки АИС или, например, опти- мизации логистических цепочек даст в результате различные модели. Точка зрения определяет основное направление развития мо- дели и уровень необходимой детализации. Четкая фиксация точ- ки зрения позволяет разгрузить модель, отказаться от детализа- ции и исследования второстепенных элементов для разрабаты- ваемой АИС. Например, функциональные модели одного и того же предприятия, построенные главным технологом и финансо- вым директором, будут существенно различаться по направлен- ности их детализации. Финансового директора в меньшей степе- ни интересуют аспекты обработки сырья на производственных станках, а главному технологу не нужны детализированные схе- мы финансовых потоков. Правильный выбор точки зрения суще- ственно сокращает временные затраты на построение конечной модели. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child diagram) по отношению к нему. Каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком — Child Box. В свою очередь, функциональный блок «предок» называется родительским блоком (Parent Box) по отношению к дочерней диа- грамме, а диаграмма, к которой он принадлежит, — родитель- ской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может затем де- тализироваться с помощью аналогичной декомпозиции соответ- ствующего ей функционального блока. В каждом случае деком- позиции функционального блока все интерфейсные дуги, входя- щие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEFO-модели. Наглядно принцип декомпозиции представлен на рис. 2.10 [3, 5, 7, 8, II, 13]. Следует обратить внимание на
88 Глава 2. Анализ предметной области АИС... Рис. 2.10. Декомпозиция функциональных блоков
2.5. Методологии описания предметной области 89 взаимосвязь нумерации функциональных блоков и диаграмм — каждый блок имеет свой уникальный порядковый номер на диа- грамме (цифра в правом нижнем углу прямоугольника), а обо- значение под ним указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что де- композиция для данного блока не существует. Возможны ситуации, когда отдельные интерфейсные дуги нет смысла рассматривать в дочерних диаграммах ниже како- го-то определенного уровня в иерархии, или наоборот, отдель- ные дуги не имеют практического смысла выше какого-то уров- ня. Например, интерфейсную дугу, изображающую «деталь» на входе функционального блока «Обработать на токарном станке», не имеет смысла отражать на диаграммах более высоких уров- ней — это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, бывает необходи- мо избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEFO предусмот- рено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок у начала интерфейсной дуги означает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение у конца (стрелки) интерфейсной дуги рядом с блоком-приемником озна- чает, что в дочерней по отношению к этому блоку диаграмме эта дуга не будет отображаться и рассматриваться. Чаще всего от- дельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерар- хии, т. е. они сначала «погружаются в туннель», а затем при не- обходимости «возвращаются из туннеля». Четвертое базовое понятие стандарта IDEFO — глоссарий (Glossary). Для каждого из элементов IDEFO (диаграмм, функ- циональных блоков, интерфейсных дуг) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Такой набор называется глоссарием и является опи- санием сущности данного элемента. Например, для управляю- щей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге доку- мента, необходимый набор виз и т. д. Глоссарий гармонично до-
90 Глава 2. Анализ предметной области АИС... полняет наглядный графический язык, снабжая диаграммы не- обходимой поясняющей информацией. Обычно IDEFO-модели несут в себе сложную и концентри- рованную информацию, и для того, чтобы не перегружать их и сделать удобочитаемыми, в соответствующем стандарте приняты следующие принципиальные ограничения сложности'. • ограничение числа функциональных блоков на диаграмме тремя и шестью. Верхний предел (шесть) заставляет разра- ботчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на со- ответствующей диаграмме достаточно деталей, чтобы оп- равдать ее создание; • ограничение числа подходящих к одному функционально- му блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя. Следовать этим ограничениям необязательно, однако их ис- пользование весьма целесообразно в практической работе. Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большим коллективом специалистов — профессионалов в разных областях деятельно- сти. Обычно процесс разработки является итерационным и со- стоит из следующих условных этапов [3, 5, 7, 8, II, 13]. 1. Создание модели группой специалистов из разных сфер деятельности предприятия. Эта группа в терминах IDEF0 назы- вается авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процес- сов. На основе имеющихся положений, документов и результа- тов опросов создается черновик (Model Draft) модели. 2. Распространение черновика для рассмотрения, согласова- ний и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каж- дая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою оче- редь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает от- корректированный черновик на дальнейшее рассмотрение. Этот цикл продолжается до тех пор, пока авторы и читатели не при- дут к единому мнению.
2.5. Методологии описания предметной области 91 3. Официальное утверждение модели. Утверждение согласо- ванной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногла- сия по поводу ее адекватности. Окончательная модель представ- ляет собой согласованное представление о предприятии (систе- ме) с заданной точки зрения и для заданной цели. Наглядность графического языка IDEF0 делает модель впол- не читаемой и для лиц, не принимавших участия в ее создании, и эффективной для проведения показов и презентаций. В даль- нейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе) [5]. 2.5.2. Моделирование потоков данных (процессов) — DFD Диаграммы потоков данных — основные средства моделиро- вания функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связан- ной потоками данных. Главная цель таких средств — продемон- стрировать, как каждый процесс преобразует свои входные дан- ные в выходные, а также выявить отношения между этими про- цессами [ 10]. В соответствии с методологией модель системы определя- ется как иерархия диаграмм потоков данных (DFD — Data Flow Diagram), описывающих асинхронный процесс преобра- зования информации от ее ввода в систему до выдачи пользо- вателю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы АИС с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня. Декомпозиция, создавая многоуровневую иерархию диаграмм, продолжается до тех пор, пока не будет достигнут такой уровень, на котором про- цессы становятся элементарными и детализировать их далее невозможно [14]. При построении DFD можно использовать различные нота- ции (табл. 2.1). Эти нотации незначительно отличаются друг от друга графическим изображением символов.
92 Глава 2. Анализ предметной области АИС... Таблица 2.1. Графическое отображение объектов DFD Объект Методика Йодана Гейна — Сарсона SADT SAG 1. Процесс । Имя, ) к № J № № Имя Имя Имя 2. Поток данных Имя Имя Имя Имя 3. Хранилище данных Имя БД Имя Нет Имя 4. Источник/прием- ник информации Имя ~^Им^^|| Текстовая метка Имя 5. Сущность Нет Нет Нет Имя Атрибуты 6. Чтение/запись Нет Нет Нет Чтение Чтение/Запись Запись 7. Группировка (сцеп- ление) потоков 1 Групповой узел J J J J у D Надо делать дополнительный процесс 8. Разгруппировка Нет 9. Неиспользуемый узел Нет ► 10. Узлы-предки (на- следование узлов) Серого цвета Серого - цвета 1С0М-метки Автоматическое наследование не происходит Для построения DFD используются следующие понятия. Потоки данных — механизмы, которые отображают передачу информации от одного процесса другому. На схеме они обычно изображаются направленной стрелкой, которая показывает на- правление движения информации или материалов (если рас- сматриваются материальные потоки). Информация может двигаться в одном направлении, обраба- тываться и возвращаться назад, в источник. Такая ситуация мо- жет моделироваться либо двумя различными потоками, либо од- ним — двунаправленным.
2.5. Методологии описания предметной области 93 Процесс преобразует значения данных. Назначение процес- са — генерация выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно со- держать глагол в неопределенной форме с последующим допол- нением (например, «вычислить максимальную высоту»). Каж- дый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться со- вместно с номером диаграммы для получения уникального ин- декса процесса во всей модели. Хранилище (накопитель) данных — пассивный объект в соста- ве DFD, в котором данные сохраняются для последующего до- ступа. Такой объект позволяет на определенных участках опре- делять данные, которые будут сохраняться в памяти между про- цессами [10]. Фактически хранилище представляет «срезы» потоков дан- ных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существи- тельным. В случае, когда поток данных входит или выходит в/из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Внешняя сущность (источник/приемник информации) — сущ- ность вне контекста системы, являющаяся источником или при- емником системных данных. Ее имя должно содержать сущест- вительное, например, «склад». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в ка- кой обработке. Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня [10]. Важную специфическую роль в модели играет специальный вид DFD — контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает взаимодействие системы с внешним миром, а именно, информа- ционные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности и, как правило, единственный процесс, отра- жающий главную цель или природу системы, насколько это воз- можно. Каждый проект должен иметь только одну контекстную
94 Глава 2. Анализ предметной области АИС... диаграмму, при этом нет необходимости в нумерации ее единст- венного процесса. Диаграмма первого уровня строится как декомпозиция про- цесса, который присутствует на контекстной диаграмме. По- строенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могу быть декомпозированы в диаграмму нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Декомпозиция продолжается до тех пор, пока процессы эффективно описыва- ются с помощью коротких (до одной страницы) мини-специфи- каций обработки (спецификаций процессов). При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Например, если детализируется процесс но- мер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь сле- дующую нумерацию: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т. с. для процесса 2.2 получим 2.2.1, 2.2.2 и т. д. Потоки могут группироваться с помощью введения нового потока. Такой поток называется потоком-предком или групповым потоком и состоит из потоков-потомков. Обратная операция (расщепление потоков на подпотоки) осуществляется с использованием группового узла (рис. 2.11) [7, 10]. Поток может быть расщеплен на любое число подпото- ков. При расщеплении подпотоки также должны быть фор- мально определены в словаре данных. Аналогичным образом осуществляется и декомпозиция пото- ков через границы диаграмм, позволяющая упростить детализи- Рис. 2.11. Расширения диаграммы потоков данных
2.5. Методологии описания предметной области 95 рующую DFD. Пусть имеется поток ЗАГОТОВКИ, входящий в детализируемый процесс. На диаграмме, детализирующей этот процесс, декомпозируемого потока может не быть совсем, но вместо него могут быть детализирующие потоки (как будто бы переданные из детализируемого процесса). Применение таких операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм. Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов [7, 10]. Групповой узел. Объект предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (фактически вырождаться в точку слияния/расщепления пото- ков на диаграмме). Узел-предок. Объект позволяет увязывать входящие и выхо- дящие потоки между детализируемым процессом и детализирую- щей диаграммой. Неиспользуемый узел. Объект применяется в случае, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока. Узел изменения имени. Объект позволяет неоднозначно име- новать потоки, при этом их содержимое эквивалентно. Напри- мер, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквива- лентность соответствующих потоков данных обеспечивается уз- лом изменения имени. При этом один из потоков данных явля- ется входным для данного узла, а другой — выходным. Также можно использовать текст в свободном формате в лю- бом месте диаграммы. Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понят- ными на каждом уровне детализации, а также разбить эти требо- вания на части с однозначно определенными отношениями ме- жду ними. При этом целесообразно пользоваться следующими рекомендациями [7, 10]: • размещать на каждой диаграмме от 3 до 6—7 процессов. Верхняя граница соответствует человеческим возможно- стям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, ниж- няя граница выбрана исходя из соображений здравого
96 Глава 2. Анализ предметной области АИС... смысла: нет необходимости детализировать процесс диа- граммой, содержащей всего один или два процесса; • не загромождать диаграммы несущественными на данном уровне деталями; • декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны вы- полняться одновременно, а не последовательно; • выбирать ясные, отражающие суть дела, имена процессов и потоков для обеспечения читабельности диаграмм, при этом стараться не использовать аббревиатуры; • однократно определять функционально идентичные про- цессы на самом верхнем уровне (где они необходимы) и ссылаться на них на нижних уровнях; • пользоваться простейшими диаграммными техниками: по возможности описывать что-либо с помощью DFD, а не с помощью более сложных объектов; • отделять управляющие структуры от обрабатывающих структур (процессов), локализовывать управляющие струк- туры. В соответствии с рекомендациями моделирование включает следующие этапы [7,10]. 1. Расчленение множества требований и организация их в основные функциональные группы. 2. Идентификация внешних объектов, с которыми должна быть связана система. 3. Идентификация основных видов информации, циркули- рующей между системой и внешними объектами. 4. Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты — внешними сущностями, основ- ные виды информации — потоками данных между процессами и внешними сущностями. 5. Изучение предварительной контекстной диаграммы и вне- сение в нее изменений по результатам ответов на возникающие вопросы по всем се частям. 6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также диаграммы сгруппированых потоков. 7. Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы. 8. Проверка основных требований по DFD первого уровня.
2.5. Методологии описания предметной области 97 9. Декомпозиция каждого процесса текущей DFD с помо- щью детализирующей диаграммы или спецификации процесса. 10. Проверка основных требований по DFD соответствующе- го уровня. 11. Добавление определений новых потоков в словарь дан- ных при каждом их появлении на диаграммах. 12. Параллельное процессу декомпозиции изучение требова- ний (в том числе и вновь поступающих), разбиение их на эле- ментарные и идентификация процессов или спецификаций про- цессов, соответствующих этим требованиям. 13. После построения двух-трех уровней проведение ревизии с целью коррекции и улучшения читабельности модели. 14. Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или не- возможно выразить комбинацией процессов. 2.5.3. Методология ARIS Одной из современных методологий бизнес-моделирования, получившей широкое распространение в России, является мето- дология ARIS (Architecture of Integrated Information Systems) — проектирование интегрированных АИС [2, 8]. В настоящий мо- мент методология ARIS является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описа- ния, анализа и оптимизации различных аспектов деятельности организации. Часть моделей используется в настроечном модуле интегрированной АИС SAP/R3, который применяется при вне- дрении системы и ее настройки в соответствии с деятельностью компании. Методология ARIS предусматривает четыре группы биз- нес-моделей (рис. 2.12). 1. «Оргструктура» состоит из моделей, с помощью которых описывается организационная структура компании, а также эле- менты внутренней инфраструктуры организации. 2. «Функции» состоят из моделей, используемых для описа- ния стратегических целей компании, функций и прочих элемен- тов функциональной деятельности организации. 3. «Информация» состоит из моделей, с помощью которых описывается информация, используемая в деятельности органи- зации.
98 Глава 2. Анализ предметной области АИС... Рис. 2.12. Группы моделей методологии ARIS 4. «Процессы» состоят из моделей, используемых для описа- ния бизнес-процессов, а также различных взаимосвязей между структурой, функциями и информацией. Большим преимуществом методологии ARIS является эрго- номичность и высокая степень визуализации бизнес-моделей, что делает методологию удобной и доступной в использовании всеми сотрудниками компании, начиная от топ-менеджеров и заканчивая рядовыми сотрудниками. В методологии ARIS смы- словое значение имеет цвет, что повышает восприимчивость и читабельность схем бизнес-моделей. Например, структурные подразделения по умолчанию изображаются желтым цветом, бизнес-процессы и операции — зеленым. Помимо большего числа моделей по сравнению с другими методологиями, методология ARIS имеет наибольшее число раз- личных объектов, используемых при построении бизнес-моде- лей, что увеличивает их аналитичность. Например, материаль- ные и информационные потоки на процессных схемах обознача- ются разными по форме и цвету объектами, что позволяет быстро определить тип потока. Несмотря на большое число моделей в методологии ARIS, в проектах по описанию и оптимизации деятельности в общем случае их используется не более десяти. Методология AR1S по- зиционирует себя как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается ло-
2.5. Методологии описания предметной области 99 кальная методология, состоящая из небольшого количества тре- буемых бизнес-модслей и объектов. Наиболее часто используе- мые в проектах модели приведены в табл. 2.2 [8]. Таблица 2.2. Наиболее часто используемые на практике модели методологии ARIS Название модели Описание и предназначение модели Английский вариант Русский вариант 0D — Objective diagram Диаграмма целей Модель описывает стратегические цели компании и их взаимосвязь с другими элементами организации PST — Product/Service tree Дерево продуктов и услуг Модель описывает продукты и услуги, производимые компанией, и их взаи- мосвязь с другими элементами орга- низации FT — Function tree Дерево функций Модель описывает функции, выпол- няемые в компании, и их иерархию FAD — Function allocation diagram Диаграмма окружения процесса Процессная модель описывает окруже- ние бизнес-процесса VACD — Value added chain diagram Диаграмма цепочки до- бавленной стоимости Процессная модель — прототип клас- сического стандарта DFD; применяется для описания бизнес-процессов верх- него уровня PSM — Process selection matrix Матрица выбора процесса Процессная модель — прототип клас- сического стандарта DFD; является аль- тернативой модели VACD и применяет- ся для описания бизнес-процессов верхнего уровня eEPC — Extended event driven Process Chain Расширенная цепочка про- цессов, управляемая со- бытиями Процессная модель — прототип клас- сического стандарта WFD; применяется дня описания бизнес-процессов ниж- него уровня. ORG — Organizational chart Модель организационной структуры Модель описывает организационную структуру компании ASTD — Application system type diagram Диаграмма типов инфор- мационных систем Модель описывает структуру информа- ционных систем, используемых в ком- пании
100 Глава 2. Анализ предметной области АИС... Модель «Диаграмма целей» — OD — применяется для описа- ния стратегических целей компании, их иерархической упорядо- ченности, а также взаимосвязи целей с продуктами и услугами, производимыми компанией, и бизнес-процессами, поддержи- вающими их производство (рис. 2.13) [8]. Рис. 2.13. Модель «Диаграмма целей» — OD/AR1S Модель «Дерево продуктов и услуг» — PST — применяется для описания продуктов и услуг, производимых в компании, а также для взаимосвязи со стратегическими целями компании, бизнес- процессами, поддерживающими их производство (рис. 2.14) [8]. Модель «Дерево функций» — FT — описывает функции, вы- полняемые в компании, и их иерархию. Модель часто применяется для построения дерева бизнес-процессов компании (рис. 2.15) [8]. Модель «Диаграмма окружения процесса» — FAD — позво- ляет описать окружение или границы бизнес-процесса, показы- вая его входы, выходы, поставщиков и клиентов (рис. 2.16). Модель «Диаграмма цепочки добавленной стоимости» — VACD — является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Существенным различием этой и других процессных моделей является то, что информационные и материальные потоки на
Рис. 2.14. Модель «Дерево продуктов и услуг» — PST/AR1S Рис. 2.15. Модель «Дерево функций» — FT/ARIS
102 Глава 2. Анализ предметной области АИС... Рис. 2.16. Модель «Диаграмма окружения процесса» — FAD/ARIS схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. В отличие от классического подхода здесь также используются логические связи между работами, которые позволяют отобразить логиче- скую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характер- но для классического подхода WFD (рис. 2.17) [8]. Рис. 2.17. Модель «Диаграмма цепочки добавленной стоимости» — VACD/ARIS Модель «Матрица выбора процесса» — PSM — является про- тотипом классического DFD-стандарта и используется как аль- тернатива VACD-модели. Матрица выбора процессов по отно- шению к диаграмме цепочки добавленной стоимости является, с одной стороны, более упрощенным вариантом описания процес- са, с другой — содержит дополнительные объекты, позволяющие выявить другие аспекты бизнес-процесса. Простота матрицы вы- бора бизнес-процессов в том, что на этой модели не отражаются информационные и материальные потоки. Что касается других
2.5. Методологии описания предметной области 103 аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения описывае- мого бизнес-процесса. Матрицу выбора процессов целесообразно применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет несколько вариантов ис- полнения, каждый из которых ложится на базовую схему. При- мер применения матрицы выбора процессов для описания дея- тельности компании, имеющей функциональную организацион- ную структуру, показан на рис. 2.18 [8]. Рис. 2.18. Модель «Матрица выбора процессов» — PSM/AR1S Модель «Расширенная цепочка процессов, управляемая собы- тиями» — еЕРС — является прототипом классического WFD-стан- дарта и используется для описания бизнес-процессов нижнего уровня. Существенным отличием еЕРС-модели от классической WFD-схемы является наличие в модели объекта, который называ- ется событием. С помощью событий изображается факт, время или событие, инициирующие начало выполнения работ процесса, а также факт или время их завершения (рис. 2.19) [8]. Модель «Организационная структура» — ORG — использует- ся для описания организационной структуры компании; отобра- жает структурные подразделения, группы, должности, роли и прочие элементы организационной структуры и связи между ними (рис. 2.20) [8]. Модель «Диаграмма типов информационных систем» — ASTD — используется для описания структуры информационных систем, применяемых в компании. Здесь отображаются типы
104 Глава 2. Анализ предметной области АИС... Рис. 2.19. Модель «Расширенная цепочка процессов, управляемая событиями» — eEPC/ARIS
2.5. Методологии описания предметной области 105 Рис. 2.20. Модель «Организационная структура» — ORG/AR1S Информа- ционные системы компании Рис. 2.21. Модель «Диаграмма типов информационных систем» — ASTD/AR1S и модули информационных систем, программные продукты, взаимосвязь между ними и автоматизируемыми бизнес-процес- сами организации (рис. 2.21) [8].
106 Глава 2. Анализ предметной области АИС... 2.5.4. Объектно-ориентированный подход. Язык унифицированного моделирования UML Использование языка ИМЬдля моделирования организации и се бизнес-процессов позволяет в полной мере отобразить структурное, статическое и динамическое представление. Полу- чаемая в ходе объектно-ориентированного анализа и проектиро- вания UML-модель организации представляет собой совокуп- ность взаимосвязанных диаграмм, идентифицирующих биз- нес-процессы, описывающих их жизненный цикл, структуру организации и взаимодействие процессов функционирования во времени и пространстве с привязкой к используемым ресурсам и получаемым результатам [9]. UML-модель применительно к бизнес-моделированию мо- жет включать в себя следующие диаграммы. [.Структурный аспект: Use-Casc-диаграммы, идентифици- рующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчинснность и взаимодействие; Package-диаграммы, струк- турно организующие предметную область и иерархически упоря- доченную структуру организации. 2. Динамический аспект: Behavior-диаграммы (Activity, State- chart, Collaboration, Sequence), описывающие поведение (жиз- ненный цикл) бизнес-процессов в их взаимодействии во време- ни и в пространстве с привязкой к используемым ресурсам и по- лучаемым результатам. 3. Статический аспект: Class-диаграммы, отражающие сово- купность взаимосвязанных объектов. В этих диаграммах рас- сматриваются логическая структура предметной области, ее внутренние концепции, иерархия объектов и статические связи между ними, структуры данных и объектов; Deployment-диа- граммы, отражающие технологические ресурсы организации. Не обязательно строить все диаграммы: аналитик или разра- ботчик сам определит нужные ему уровень детализации, полноту описания и точку зрения. UML-модель позволяет получить подробные ответы на стан- дартные вопросы о деятельности организации, в частности: • каковы виды деятельности организации и предметные об- ласти управления (предметно-структурный аспект); • каковы бизнес-процессы организации (функциональный аспект);
2.5. Методологии описания предметной области 107 • кто и где выполняет бизнсс-процессы (организационный аспект); • как выполняются бизнес-процсссы (методический аспект); • когда выполняются бизнес-процессы (динамический ас- пект); • что, откуда и куда перемешается, обрабатывается, получа- ется в материальных и в связанных с ними информацион- ных потоках (сущностно-элементный аспект); • с помощью чего (какими инструментами) выполняются бизнес-процсссы (ресурсный и технологический аспекты). В табл. 2.3 представлена связь между различными аспектами моделирования деятельности организации и их отражение на UML-диаграммах [9]. Таблица 2.3. Связь между аспектами моделирования и UML-диаграммами Аспект моделирования UML-диаграмма Предметно-структурный Package-диаграммы Функциональный Use-Case-диаграммы Организационный Package-диаграммы, Class-диаграммы Методический Activity-диаграммы Динамический Statechart-, Collaboration-, Sequence-диаграммы Сущностно-элементный Class-диаграммы Технологический Deployment-диаграммы Ядро UML поддерживает использование расширений стан- дартных элементов в виде стереотипов, именованных значений, графических обозначений, позволяющих уточнить синтаксис и семантику модели и таким образом лучше понять моделируемую предметную область. Для бизнес-моделирования деятельности организации используют следующие расширения (табл. 2.4) [9]. Activity-диаграммы раскрывают методический аспект биз- нес-процессов. Каждая бизнес-транзакция есть полная или час- тичная реализация некоторой управленческой функции, итогом выполнения которой является значимый на том или ином уров- не управления результат. Для достижения данного результата
108 Глава 2. Анализ предметной области АИС... Таблица 2.4. Расширения UML Элемент UML Расширение Обозначение Package Пакеты предметных областей управления или видов деятельности. Стереотип — «Business System» На «Bus именован!/ iness Systt е т» Пакеты организационных единиц (структурных под- разделений). Стереотип — «Organization Unit» н Наймет «Organiza о ti вание эп Unit » Class Бизнес-сущности, обозначающие владельцев биз- нес-процессов. Стереотип — «Business Actor» Наименование «Business Actor» Бизнес-сущности, обозначающие деловых работни- ков (исполнителей). Стереотип — «Business Worker» Наименование «Business Worker» Бизнес-сущности, обозначающие объект учета. Сте- реотип — «Business Object» е Ct» Наименовани «Business Obje Бизнес-сущности, обозначающие субъекты учета. Стереотип — «Business Subject» е Ct» Наименовани «Business Subjr Бизнес-сущности, обозначающие первичные доку- менты. Стереотип — «Document» На « именова Documen ние t»
2.5. Методологии описания предметной области 109 при выполнении бизнес-транзакции используются некоторые материальные, информационные и иные объекты (бизнес-сущ- ности), идентифицированные на Class-диаграммах. Выполнение бизнес-транзакции закрепляется за определенным исполните- лем, также идентифицированным на Class-диаграмме со стерео- типом «Organization Unit». Бизнес-сущности в ходе выполнения бизнес-транзакции могут менять свое внутреннее состояние, что также находит отражение на Activity-диаграммах, а полная карта состояний и переходов между ними — на соответствующих Statechart-диаграммах [9]. Кроме того, каждая бизнес-транзакция или состояние могут быть детализованы на вложенных Activity- и Statechart-диаграм- мах соответственно. Таким образом, Activity-диаграммы, отражая реализацию бизнес-процесса, выступают как связующее звено между други- ми диаграммами и элементами UML-модели.
по Глава 2. Анализ предметной области АИС... Идентифицированный однажды элемент модели может быть использован на других диаграммах, отражая многообразие его связей, взаимодействий и особенностей. Использование такого подхода — серьезное преимущество UML-моделей. Таким образом, UML-модсль выступает как средство доку- ментирования и анализа существующих бизнес-процессов, их оптимизации или перепроектирования, моделирования новых бизнес-процессов во взаимосвязи с организационной структу- рой, предметными областями и функциями управления органи- зацией, а также выступает как фундаментальная основа для фор- мирования требований к построению АИС, автоматизирующей деятельность организации. 2.6. Системы автоматизированного проектирования АИС 2.6.1. Этапы развития CASE-систем За последнее десятилетие сформировалось новое направле- ние в проектировании информационных систем — автоматизи- рованное проектирование с помощью CASE-средств. Термин CASE (Computer Aided System/Software Engineering) первона- чально относился только к автоматизации разработки программ- ного обеспечения; сейчас он охватывает процесс разработки сложных АИС в целом [11, 15, 16]. Изначально CASE-технологии развивались с целью преодо- ления недостатков структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости ис- пользования, трудности внесения изменений в проектные спе- цификации и т. д.) за счет автоматизации и интеграции поддер- живающих средств. CASE-технологии не существуют сами по себе, не являются самостоятельными. Они автоматизируют и оптимизируют ис- пользование соответствующей методологии, дают возможность повысить эффективность ее применения. Другими словами, CASE-технологии представляют собой со- вокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения,
2.6. Системы автоматизированного проектирования АИС 111 поддержанную комплексом взаимосвязанных средств автомати- зации, которые позволяют в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения АИС и разрабатывать приложения в соответствии с информационными потребностями пользовате- лей [2]. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования АИС — от простых средств анализа и документирования до полномас- штабных средств автоматизации, покрывающих весь жизненный цикл АИС. Наибольшая потребность в использовании CASE-сис- тем испытывается на начальных этапах разработки — на этапах анализа и спецификации требований к АИС. Допущенные здесь ошибки практически фатальны, их цена значительно превышает цену ошибок поздних этапов разработки. Основные задачи CASE-средств состоят в том, чтобы отде- лить начальные этапы (анализ и проектирование) от последую- щих и не обременять разработчиков деталями среды разработки и функционирования системы. В большинстве современных CASE-систем применяются ме- тодологии структурного и/или объектно-ориентированного анали- за и проектирования, основанные на использовании наглядных диаграмм, графов, таблиц и схем. При грамотном применении CASE-инструментария достига- ется значительный рост производительности труда, составляю- щий (по оценкам зарубежных фирм пользователей CASE-техно- логий) от 100 до 600 % в зависимости от объема, сложности ра- бот и опыта работы с CASE. При этом изменяются все фазы жизненного цикла АИС, но наибольшие изменения касаются фаз анализа и проектирования (табл. 2.5, 2.6) [11, 15, 16]. Таблица 2.5. Оценки трудозатрат по фазам жизненного цикла АИС Способ разработки Анализ, % Проектирование, % Кодирование, % Тестирование,% Традиционная разработка 20 15 20 45 Использование структурной методологии 30 30 15 25 Использование CASE-техно- логий 40 40 5 15
112 Глава 2. Анализ предметной области АИС... Таблица 2.6. Сравнение использования CASE и традиционной разработки Традиционная разработка Разработка с CASE-средствами Основные усилия — на кодирование и тестирование Основные усилия — на анализ и проектирование «Бумажные» спецификации Быстрое итеративное прототипирование Ручное кодирование Автоматическая кодогенерация Ручное документирование Автоматическая генерация документации Тестирование кодов Автоматический контроль проекта Сопровождение кодов Сопровождение спецификаций проектирования Применение CASE-средств не только автоматизирует струк- турную методологию и дает возможность использовать совре- менные методы системной и программной инженерии, но и пре- доставляет другие преимущества (рис. 2.22), в частности: • улучшает качество разрабатываемого программного обес- печения за счет средств автоматической генерации и кон- троля; • позволяет уменьшить время создания прототипа АИС, что дает возможность на ранних этапах оценить качество и эф- фективность проекта; • ускоряет процесс проектирования и разработки; • позволяет многократно использовать разработанные ком- поненты; • поддерживает сопровождение АИС; • освобождает от рутинной работы по документированию проекта, так как использует встроенный документатор; • облегчает коллективную работу над проектом. Рис. 2.22. Преимущества разработки АИС с использованием CASE-технологий: а — коэффициент уменьшения стоимости проекта; б — коэффициент уменьше- ния временных затрат на разработку
2.6. Системы автоматизированного проектирования АИС 113 В основе большинства CASE-средств лежат четыре главных понятия: методология, метод, нотация, средство (И, 15, 16]. Методология определяет руководящие указания для оценки и выбора решений при проектировании и разработке АИС, этапы работы, их последовательность, правила распределения и назна- чения методов. Методы — процедуры генерации компонентов и их описа- ний. Нотации предназначены для описания общей структуры сис- темы, элементов данных, этапов обработки, могут включать гра- фы, диаграммы, таблицы, блок-схемы, формальные и естествен- ные языки. Средства — инструментарий для поддержки и усиления ме- тодов; поддерживает работу пользователей при создании и ре- дактировании проекта в интерактивном режиме, помогает орга- низовать проект в виде иерархии уровней абстракции, осуществ- ляет проверки соответствия компонентов. 2.6.2. Классификация CASE-средств До сих пор не существует устойчивой классификации CASE-средств, определены только подходы к классификации в зависимости от различных классификационных признаков. Ниже приведены некоторые из них [II, 12]. Ориентация на технологические этапы и процессы жизненного цикла АИС: • средства анализа и проектирования. Используются для со- здания спецификаций системы и ее проектирования. Они поддерживают широко известные методологии проектиро- вания; • средства проектирования баз данных. Обеспечивают логи- ческое моделирование данных, генерацию структур БД; • средства управления требованиями; • средства управления конфигурацией программного обеспе- чения. Поддерживают программирование, тестирование, автоматическую генерацию ПО из спецификаций; • средства документирования; • средства тестирования; • средства управления проектом. Поддерживают планирова- ние, контроль, взаимодействие;
114 Глава 2. Анализ предметной области АИС... • средства реверсного инжиниринга, предназначенные для переноса существующей системы в новую среду. Поддерживаемые методологии проектирования [11, 12, 15, 16]: • функционально-ориентированные (структурно-ориентиро- ванные); • объектно-ориентированные; • комплексно-ориентированные (набор методологий проек- тирования). Поддерживаемые графические нотации построения диаграмм: • с фиксированной нотацией; • с отдельными нотациями; • с наиболее распространенными нотациями. Степень интегрированности: • вспомогательные программы (Tools), самостоятельно ре- шающие автономную задачу; • пакеты разработки (Toolkit), представляющие собой сово- купность средств, обеспечивающих помощь для одного из классов программных задач; • наборы интегрированных средств, связанных общей базой проектных данных — репозиторием, автоматизирующие все или часть работ разных этапов создания АИС (Workbench). Коллективная разработка проекта: • без поддержки коллективной разработки; • ориентированные на разработку проекта в режиме реально- го времени; • ориентированные на режим объединения подпроектов. Типы CASE-средств: • средства анализа (Upper CASE); среди специалистов назы- ваются средствами компьютерного планирования. С помо- щью этих CASE-средств строят модель, отражающую всю существующую специфику. Она направлена на понимание общего и частного механизмов функционирования, имею- щихся возможностей, ресурсов, целей проекта в соответст- вии с назначением фирмы. Эти средства позволяют прово- дить анализ различных сценариев, накапливая информа- цию для принятия оптимальных решений; • средства анализа и проектирования (Middle CASE); счита- ются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры АИС. Основ- ной результат использования среднего CASE-срсдства со-
2.6. Системы автоматизированного проектирования АИС 115 стоит в значительном упрощении проектирования систе- мы, так как проектирование превращается в итеративный процесс работы с требованиями к АИС. Кроме того, сред- ние CASE-средства обеспечивают быстрое документирова- ние требований; • средства разработки ПО (Lower); поддерживают системы разработки программного обеспечения АИС. Содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций — имеются системные спецификации, которые непосредст- венно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80 % ко- дов). Главными преимуществами нижних CASE-средств являются значительное уменьшение времени на разработ- ку, облегчение модификаций, поддержка возможностей ра- боты с прототипами. CASE-средства, кроме того, классифицируют по типу и архи- тектуре вычислительной техники, а также по типу операционной системы [11, 12, 16]. В настоящее время рынок программных продуктов представ- лен самым разнообразным ПО, в том числе и CASE-средствами практически любого из перечисленных классов. 2.6.3. Характеристики CASE-средств Silverrun. CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и проектирования АИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для под- держки любой методологии, основанной на раздельном построе- нии функциональной и информационной моделей (диаграмм потоков данных и диаграмм «сущность—связь») [7, 11, 16]. Настройка на конкретную методологию обеспечивается вы- бором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеет- ся возможность добавления собственных описателей. Архитекту-
116 Глава 2. Анализ предметной области АИС... pa Silverrun позволяет наращивать среду разработки по мере не- обходимости. Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продук- том и может приобретаться и использоваться отдельно. 1. Модуль построения моделей бизнес-процессов в форме диа- грамм потоков данных Business Process Modeler (BPM) позволяет моделировать функционирование автоматизируемой организа- ции или создаваемой АИС. Возможность работы с моделями большой сложности обеспечена функциями автоматической пе- ренумерации, работы с деревом процессов (включая визуальное перетаскивание ветвей), отсоединения и присоединения частей модели для коллективной разработки. Диаграммы могут изобра- жаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, например в число изображае- мых на схеме дескрипторов добавлять определенные пользовате- лем поля. 2. Модуль концептуального моделирования данных Entity-Rela- tionship eXpert (ERX) обеспечивает построение моделей данных «сущность—связь», не привязанных к конкретной реализации. Встроенная экспертная система позволяет создавать корректную нормализованную модель данных посредством ответов на содер- жательные вопросы о взаимосвязи данных. Предусмотрено авто- матическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям треть- ей нормальной формы и обеспечить их выполнение. Проверен- ная модель передается в модуль Relational Data Modeler. 3. Модуль реляционного моделирования Relational Data Modeler (RDM) позволяет создавать детализированные модели «сущ- ность-связь», предназначенные для реализации в реляционной БД. В этом модуле документируются все конструкции, связан- ные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Воз- можность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы БД. На языке подсхем модели- руются как узлы распределенной обработки, так и пользователь- ские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных БД.
2.6. Системы автоматизированного проектирования АИС 117 4. Менеджер репозитория рабочей группы Workgroup Repository Manager (WRM) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает ин- теграцию модулей Silverrun в единую среду проектирования. Достоинством CASE-срсдства Silverrun являются высокая гибкость и разнообразие изобразительных средств построения моделей, а недостатком — отсутствие жесткого взаимного кон- троля между компонентами различных моделей (например, воз- можности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отме- тить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели жизненного цикла [7, 11, 16]. В Silverrun включены средства: • автоматической генерации схем баз данных для наиболее распространенных СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase; • передачи данных средствам разработки приложений: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Таким образом, можно полностью определить ядро БД с ис- пользованием всех возможностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации ин- терфейсных объектов, либо для быстрого их создания вручную. Для обмена данными с другими средствами автоматизации проектирования, создания специализированных процедур ана- лиза и проверки проектных спецификаций, составления специа- лизированных отчетов в соответствии с различными стандартами в системе Silverrun предусмотрено три способа выдачи проект- ной информации во внешние файлы. 1. Система отчетов. Отчеты выводятся в текстовые файлы. 2. Система экспорта/импорта. Задается не только содержи- мое экспортного файла, но и разделители записей, полей в запи- сях, маркеры начала и конца текстовых полей. Такие экспорт- ные файлы можно формировать и загружать в репозиторий. Это дает возможность обмениваться данными с различными систе- мами: другими CASE-средствами, СУБД, текстовыми редактора- ми и электронными таблицами. 3. Хранение репозитория во внешних файлах с доступом с помощью ODBC-драйверов. Для доступа к данным репозитория
118 Глава 2. Анализ предметной области АИС... из наиболее распространенных СУБД обеспечена возможность хранить всю проектную информацию непосредственно в форма- те этих СУБД. Silverrun поддерживает два способа групповой работы: 1) в стандартной однопользовательской версии имеется меха- низм контролируемого разделения и слияния моделей. Модель может быть разделена на части и распределена между несколь- кими разработчиками. После детальной проработки части снова собираются в единую модель; 2) сетевая версия Silverrun позволяет вести параллельную групповую работу с моделями, хранящимися в сетевом репози- тории на базе СУБД Oracle, Sybase или Informix. При этом не- сколько разработчиков могут работать с одной и той же моде- лью, так как блокировка объектов происходит на уровне отдель- ных элементов модели. JAM. Средство разработки приложений JYACC's Application Manager (JAM) — продукт фирмы JYACC. Главной особенностью является соответствие методологии RAD, так как JAM позволяет достаточно быстро реализовать цикл разработки приложения, за- ключающийся в формировании очередной версии прототипа приложения с учетом требований, выявленных на предыдущем шаге, и предъявить его пользователю [7, 11, 16]. JAM имеет модульную структуру и состоит из следующих компонентов: • ядра системы; • JAM/DBi — специализированных модулей интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т. д.); • JAM/RW — модуля генератора отчетов; • JAM/CASEi — специализированных модулей интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Inno- vator и т. д.); • JAM/TPi — специализированных модулей интерфейса к ме- неджерам транзакций (например, JAM/TPi-Server TUXEDO и т. д.); • Jterm — специализированного эмулятора Х-терминала. Ядро системы является законченным продуктом и может са- мостоятельно использоваться для разработки приложений. Все остальные модули — дополнительные и самостоятельно исполь- зоваться не могут.
2.6. Системы автоматизированного проектирования АИС 119 Ядро системы включает в себя следующие основные ком- поненты: • редактор экранов. В состав редактора экранов входят среда разработки экранов, визуальный репозиторий объектов, собственная СУБД JAM — JDB, менеджер транзакций, от- ладчик, редактор стилей; • редактор меню; • набор вспомогательных утилит; • средства изготовления промышленной версии приложения. При использовании JAM разработка внешнего интерфейса приложения представляет собой визуальное проектирование и сводится к созданию экранных форм путем размещения на них интерфейсных конструкций и определению экранных полей ввода/вывода информации. Проектирование интерфейса в JAM осуществляется с помощью редактора экранов. Приложения, разработанные в JAM, имеют многооконный интерфейс. Разра- ботка экрана заключается в размещении на нем интерфейсных элементов, их группировке, задании значений их свойств. Редактор меню позволяет разрабатывать и отлаживать систе- мы меню. Реализована возможность построения пиктографиче- ских меню. Назначение пунктов меню объектам приложения осуществляется в редакторе экранов. В ядро JAM встроена однопользовательская реляционная СУБД JDB. Основным назначением JDB является прототипиро- вание приложений в тех случаях, когда работа со штатной СУБД невозможна или нецелесообразна. В JDB реализован необходи- мый минимум возможностей реляционных СУБД, в который не входят индексы, хранимые процедуры, триггеры и представле- ния. С помощью JDB можно построить БД, идентичную целевой БД (с точностью до отсутствующих в JDB возможностей), и раз- работать значительную часть приложения. Отладчик позволяет проводить комплексную отладку разра- батываемого приложения. Осуществляется трассировка всех со- бытий, возникающих в процессе исполнения приложения. Утилиты JAM включают три группы: 1) конверторы файлов экранов JAM в текстовые. JAM сохра- няет экраны в виде двоичных файлов собственного формата; 2) конфигурирование устройств ввода-вывода. JAM и прило- жения, построенные с его помощью, не работают непосредст- венно с устройствами ввода-вывода. Вместо этого JAM обраща-
120 Глава 2. Анализ предметной области ЛИС... ется к логическим устройствам ввода-вывода (клавиатура, тер- минал, отчет); 3) обслуживание библиотек экранов. Одним из дополнительных модулей JAM является генератор отчетов. Компоновка отчета осуществляется в редакторе экра- нов JAM. Описание работы отчета осуществляется с помощью специального языка. Генератор отчетов позволяет определить данные, выводимые в отчет, группировку выводимой информа- ции, форматирование вывода и т. д. Приложения, разработанные с использованием JAM, могут быть изготовлены в виде исполняемых модулей. Для этого раз- работчики должны иметь компилятор С и редактор связей. JAM содержит встроенный язык программирования JPL (JAM Procedural Language), с помощью которого в случае необходимо- сти могут быть написаны модули, реализующие специфические действия. Данный язык является интерпретируемым. Существу- ет возможность обмена информацией между средой визуально построенного приложения и такими модулями. Кроме того, в JAM реализована возможность подключения внешних модулей, написанных на языках, совместимых по вызовам функций с языком С. JAM является событийно-ориентированной системой, состоя- щей из набора событий — открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера, получе- ние и передача управления каждым элементом экрана. Разработ- чик реализует логику приложения путем определения обработ- чика каждого события. Обработчиками событий в JAM могут быть как встроенные функции JAM, так и функции, написанные разработчиком на С или JPL. Набор встроенных функций включает более 200 функ- ций различного назначения; они доступны для вызовов из функ- ций, написанных как на JPL, так и на С. Промышленная версия приложения, разработанного с помо- щью JAM, состоит из следующих компонентов: • исполняемого модуля интерпретатора приложения; • экранов, составляющих приложение (поставляются в виде отдельных файлов, в составе библиотек экранов или встраиваются в тело интерпретатора); • внешних JPL-модулсй (поставляются в виде текстовых файлов или в прекомпилированном виде; прекомпилиро-
2.6. Системы автоматизированного проектирования АИС 121 ванные внешние JPL-модули — в виде отдельных файлов и в составе библиотек экранов); • файлов конфигурации приложения — файлов конфигура- ции клавиатуры и терминала, файла системных сообще- ний, файла обшей конфигурации. Непосредственное взаимодействие с СУБД реализуют моду- ли JAM/DBi (Database interface). Способы реализации взаимо- действия в JAM разделяются на два класса: ручные и автомати- ческие. При ручном способе разработчик самостоятельно пишет запро- сы на SQL, в которых источниками и адресатами приема резуль- татов выполнения запроса могут быть как интерфейсные элемен- ты визуально спроектированного внешнего уровня, так и внут- ренние, невидимые для конечного пользователя переменные. Автоматический режим реализуется менеджером транзакций JAM. Он осуществим для типовых распространенных видов опе- раций с БД, так называемых QBE (Query By Example — запросы по образцу), с учетом достаточно сложных взаимосвязей между таблицами БД и автоматическим управлением атрибутами эк- ранных полей ввода-вывода в зависимости от вида транзакции (чтение, запись и т. д.), в которой участвует сгенерированный запрос. JAM позволяет строить приложения для работы с более чем 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые СУБД и др. Отличительной чертой JAM является высокий уровень пере- носимости приложений между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Opcn VMS и др.); возможно требование «перерисо- вать» статические текстовые поля на экранах с русским текстом при переносе между средами DOS—Windows—UNIX. Кроме того, переносимость облегчается тем, что в JAM приложения разрабатываются для виртуальных устройств ввода-вывода, а не для физических. Таким образом, при переносе приложения с платформы на платформу, как правило, требуется лишь опреде- лить соответствие между физическими устройствами ввода-вы- вода и их логическими представлениями для приложения. Использование SQL в качестве средства взаимодействия с СУБД также помогает обеспечивать переносимость между СУБД. В случае переноса структуры БД приложения могут не требовать никакой модификации, за исключением инициализа-
122 Глава 2. Анализ предметной области АИС... ции сеанса работы. Это возможно, если р приложении не ис- пользовались специфические для СУБД расширения SQL. При росте нагрузки на систему и сложности решаемых задач (распределенность и гетерогенность используемых ресурсов, ко- личество одновременно подключенных пользователей, сложность логики приложения) применяется трехзвенная модель архитекту- ры «клиент — сервер» с использованием менеджеров транзакций. Компоненты JAM/TPi-Client и JAM/TPi-Scrver позволяют доста- точно просто перейти на трехзвенную модель. При этом ключе- вую роль играет модуль JAM/TPi-Servcr, так как основная труд- ность внедрения трехзвенной модели заключается в реализации логики приложения в сервисах менеджеров транзакций. Интерфейс JAM/CASE позволяет осуществлять обмен ин- формацией между репозиторием объектов JAM и репозиторием CASE-средства. Обмен происходит аналогично тому, как струк- тура БД импортируется в репозиторий JAM непосредственно из БД. Отличие заключается в том, что обмен между репозитория- ми является двунаправленным. Кроме модулей JAM/CASEi, существует также модуль JAM/ CASEi Developer's Kit. С помощью этого модуля можно само- стоятельно разработать интерфейс (т. е. специализированный модуль JAM/CASEi) для конкретного CASE-средства, если гото- вого модуля JAM/CASEi для него не существует. Существует интерфейс, реализующий взаимодействие между CASE-средством Silverrun и JAM. Он производит перенос схемы БД и экранных форм приложения между CASE-средством Silverrun-RDM и JAM версии 7.0; имеет два режима работы: 1) прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASE-словаря и элементов репозитория JAM на основе представления схем в Silverrun-RDM. Исходя из пред- ставления моделей данных интерфейса в Silverrun-RDM произ- водится генерация экранов и элементов репозитория JAM. Мост преобразует таблицы и отношения реляционных схем RDM в последовательность объектов JAM соответствующих типов. Ме- тодика построения моделей данных интерфейса в Silverrun-RDM предполагает применение механизма подсхем для прототипиро- вания экранов приложения. По описанию каждой из подсхем RDM мост генерирует экранную форму JAM; 2) обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций объектов CASE-словаря в реляционную модель Silverrun-RDM.
2.6. Системы автоматизированного проектирования АИС 123 Режим реинжиниринга позволяет переносить модификации всех свойств экранов JAM, импортированных ранее из RDM, в схему Silverrun. Для контроля целостности БД не допускаются изменения схемы в виде добавления или удаления таблиц и по- лей таблиц. Ядро JAM имеет встроенный интерфейс к средствам конфи- гурационного управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под управлением этих систем передаются библиотеки экранов и/или репозитории. При отсутствии таких систем JAM самостоятельно реализует часть функций поддержки групповой разработки. На платформе MS-Windows JAM имеет встроенный интер- фейс к PVCS, и действия по выборке/возврату производятся не- посредственно из среды JAM. Vantage Team Builder (Westmount I-CASE). Vantage Team Builder представляет собой интегрированный программный про- дукт, ориентированный на реализацию и полную поддержку кас- кадной модели жизненного цикла [7, И, 16]. Vantage Team Builder обеспечивает выполнение следующих функций: • проектирование диаграмм потоков данных, диаграмм «сущность—связь», структур данных, структурных схем программ и последовательностей экранных форм; • проектирование диаграмм архитектуры системы — SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа «клиент — сер- вер», анализ использования менеджеров транзакций и осо- бенностей функционирования систем в реальном времени); • генерация кода программ на языке целевой СУБД с пол- ным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур; • программирование на языке С со встроенным SQL; • управление версиями и конфигурацией проекта; • многопользовательский доступ к репозиторию проекта; • генерация проектной документации по стандартным и ин- дивидуальным шаблонам; • экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).
124 Глава 2. Анализ предметной области АИС... Vantage Team Builder поставляется в различных конфигура- циях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных частичной ориентацией на спиральную модель жиз- ненного цикла за счет возможностей быстрого прототипирова- ния. Для описания проекта АИС используется большой набор диаграмм. При построении всех типов диаграмм обеспечивается кон- троль соответствия моделей синтаксису используемых методов, а также контроль соответствия одноименных элементов и их ти- пов для различных типов диаграмм. При построении диаграмм потоков данных DFD обеспечива- ется контроль соответствия диаграмм различных уровней деком- позиции. Контроль за правильностью верхнего уровня DFD осу- ществляется с помощью матрицы списков событий ELM. Для контроля за декомпозицией составных потоков данных исполь- зуется несколько вариантов их описания: в виде диаграмм струк- тур данных DSD или в нотации БНФ (форма Бэкуса — Наура). Для построения SAD используется расширенная нотация DFD, дающая возможность вводить понятия процессоров, задач и периферийных устройств, что обеспечивает наглядность про- ектных решений [16]. При построении модели данных в виде ERD выполняется ее нормализация и вводится определение физических имен элемен- тов данных и таблиц, которые будут использоваться в процессе генерации физической схемы данных конкретной СУБД. Обес- печивается возможность определения альтернативных ключей сущностей и полей, составляющих дополнительные точки входа в таблицу (поля индексов), и мощности отношений между сущ- ностями. Наличие универсальной системы генерации кода, основан- ной на специфицированных средствах доступа к репозиторию проекта, позволяет поддерживать высокий уровень исполнения проектной дисциплины разработчиками: жесткий порядок фор- мирования моделей; жесткую структуру и содержимое докумен- тации; автоматическую генерацию исходных кодов программ и т. д.; все это обеспечивает повышение качества и надежности разрабатываемых ИС. Для подготовки проектной документации могут использо- ваться издательские системы FrameMaker, Interleaf или Word
2.6. Системы автоматизированного проектирования АИС 125 Perfect. Структура и состав проектной документации настраива- ются в соответствии с заданными стандартами. Настройка вы- полняется без изменения проектных решений. При разработке крупных АИС вся система в целом соответст- вует одному проекту как категории Vantage Team Builder. Проект может быть декомпозирован на ряд систем, каждая из которых соответствует некоторой относительно автономной подсистеме АИС и разрабатывается независимо от других. В дальнейшем системы проекта могут быть интегрированы. Процесс проектирования АИС с использованием Vantage Team Builder реализуется в виде четырех последовательных фаз (стадий) — анализа, архитектуры, проектирования и реализации, при этом законченные результаты каждой стадии полностью или частично переносятся (импортируются) в следующую фазу. Все диаграммы, кроме ERD, преобразуются в другой тип или изме- няют вид в соответствии с особенностями текущей фазы. Так, DFD преобразуются в фазе архитектуры в SAD, DSD — в DTD. После завершения импорта логическая связь с предыдущей фа- зой разрывается, т. е. в диаграммы можно вносить все необходи- мые изменения. Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой техноло- гической среды проектирования, при этом схемы БД (SQL-модс- ли) переносятся в репозиторий Uniface, и наоборот, прикладные модели, сформированные средствами Unifacc, могут быть пере- несены в репозиторий Vantage Team Builder. Возможные рассо- гласования между репозиториями двух систем устраняются с по- мощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм FSD после импорта SQL-модели. Технология разработки АИС на базе данной конфигурации показана на рис. 2.23 [7]. Структура репозитория, хранящегося в целевой СУБД, и ин- терфейсы Vantage Team Builder являются открытыми, что в принципе обеспечивает возможность интеграции с любыми дру- гими средствами. Uniface. Продукт фирмы Compuware представляет собой сре- ду разработки крупномасштабных приложений в архитектуре «клиент—сервер» и имеет следующую компонентную архитекту- ру 17, 11, 16]: • Application Objects Repository (репозиторий объектов при- ложений) содержит метаданные, автоматически используе-
126 Глава 2. Анализ предметной области АИС... Разработчик приложений Рис. 2.23. Взаимодействие Vantage Team Builder и Uniface мыс всеми остальными компонентами на протяжении жиз- ненного цикла АИС (прикладные модели, описания дан- ных, бизнес-правил, экранных форм, глобальных объектов и шаблонов). Репозиторий может храниться в любой из БД, поддерживаемых Uniface; • Application Model Manager поддерживает прикладные моде- ли (E-R-модели), каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения, и включает соответствующий графический редактор;
2.6. Системы автоматизированного проектирования АИС 127 • Rapid Application Builder — средство быстрого создания эк- ранных форм и отчетов на базе объектов прикладной моде- ли. Включает графический редактор форм, средства прото- типирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления Open Widget Interface для существую- щих графических интерфейсов — MS Windows (включая VBX), Motif, OS/2. Универсальный интерфейс представле- ния Universal Presentation Interface позволяет использовать одну и ту же версию приложения в среде различных графи- ческих интерфейсов без изменения программного кода; • Developer Services (службы разработчика) используются для поддержки крупных проектов и реализуют контроль версий (Uniface Version Control System), права доступа (разграниче- ние полномочий), глобальные модификации и т. д. Это обеспечивает разработчиков средствами параллельного про- ектирования, входного и выходного контроля, поиска, про- смотра, поддержки и выдачи отчетов по данным системы контроля версий; • Deployment Manager (управление распространением прило- жений) — средства, позволяющие готовить созданное при- ложение для распространения, устанавливать и сопровож- дать его (при этом платформа пользователя может отли- чаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления БД. Unifacc поддерживает интерфейс практиче- ски со всеми известными программно-аппаратными плат- формами, СУБД, CASE-средствами, сетевыми протокола- ми и менеджерами транзакций; • Personal Series (персональные средства) используются для создания сложных запросов и отчетов в графической фор- ме (Personal Query и Personal Access — PQ/PA), а также для переноса данных в такие системы, как WinWord и Excel; • Distributed Computing Manager — средство интеграции с менеджерами транзакций Tuxedo, Encina, CICS, OSF DCE. Версия Uniface 7 полностью поддерживает распределенную модель вычислений и трехзвенную архитектуру «клиент—сервер» (с возможностью изменения схемы декомпозиции приложений на этапе исполнения). Приложения, создаваемые с помощью Uniface 7, могут исполняться в гетерогенных операционных сре-
128 Глава 2. Анализ предметной области АИС... дах, использующих различные сетевые протоколы, одновремен- но на нескольких разнородных платформах (в том числе и в* Internet). В состав компонент Uniface 7 входят: • Uniface Application Server — сервер приложений для рас- пределенных систем; • WebEnabler — серверное ПО для эксплуатации приложе- ний в Internet и intranet; • Name Server — серверное ПО, обеспечивающее использо- вание распределенных прикладных ресурсов; • PolyServer — средство доступа к данным и интеграции раз- личных систем. В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS. Designer/2000 + DeveIoper/2000. Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспе- чивающим в совокупности со средствами разработки приложе- ний Developer/2000 поддержку полного ЖЦ ПО для систем, ис- пользующих СУБД ORACLE [7, 11, 16]. Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методоло- гия Designer/2000 (CASE*Method) — структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла АИС. На этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабаты- вается системная архитектура и план разработки АИС. В процес- се анализа строятся: модель информационных потребностей (диаграмма «сущность—связь»), диаграмма функциональной иерархии (на основе функциональной декомпозиции АИС), мат- рица перекрестных ссылок и диаграмма потоков данных. На этапе проектирования разрабатывается подробная архи- тектура АИС, проектируется схема реляционной БД и про- граммные модули, устанавливаются перекрестные ссылки между компонентами АИС для анализа их взаимного влияния и кон- троля за изменениями. На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и со- ответствия требованиям пользователей. Создается системная до- кументация, материалы для обучения и руководства пользовате- лей. На этапах эксплуатации и сопровождения анализируются
2.6. Системы автоматизированного проектирования АИС 129 производительность и целостность системы, выполняется под- держка и, при необходимости, модификация АИС. Designer/2000 обеспечивает графический интерфейс при раз- работке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компо- ненты: • Repository Administrator — средства управления репозито- рием (создание и удаление приложений, управление досту- пом к данным со стороны различных пользователей, экс- порт и импорт данных); • Repository Object Navigator — средства доступа к репозито- рию, обеспечивающие многооконный объектно-ориентиро- ванный интерфейс доступа ко всем элементам репозитория; • Process Modeller — средство анализа и моделирования де- ловой деятельности, основывающееся на концепциях реин- жиниринга бизнес-процессов BPR и глобальной системы управления качеством TQM (см. гл. 2); • Systems Modeller — набор средств построения функцио- нальных и информационных моделей проектируемой АИС, включающий средства для построения диаграмм «сущ- ность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagram- mer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репози- тория различных типов (Matrix Diagrammer); • Systems Designer — набор средств проектирования АИС, включающий средство построения структуры реляционной БД (Data Diagrammer), а также средства построения диа- грамм, отображающих взаимодействие с данными, иерар- хию, структуру и логику приложений, реализуемую храни- мыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator); • Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т. д.). Помимо продуктов ORACLE, генерация и реинжи- ниринг БД могут выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется по- средством ODBC;
130 Глава 2. Анализ предметной области АИС... • Forms Generator — генератор приложений для ORACLE Forms. Генерируемые приложения включают в себя различ- ные экранные формы, средства контроля данных, провер- ки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000; • Repository Reports — генератор стандартных отчетов, и итог- рированный с ORACLE Reports и позволяющий русифици- ровать отчеты, а также изменять структурное представле- ние информации. Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользователь- ском режиме, обеспечивая параллельное обновление информа- ции несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря; генераторы более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE. Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic. Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Средство ORACLE CASE Exchange под- держивает экспорт/импорт объектов репозитория с целью обме- на информацией с другими CASE-средствами. Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими сред- ствами реализуется через механизм OLE и управляющие элемен- ты VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API. S-Designor. S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных БД. По своим функциональ- ным возможностям и стоимости аналогично средству ErWin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД. S-Designor совместимо со средствами разработки приложе- ний (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экс-
2.6. Системы автоматизированного проектирования АИС 131 портировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений. CASE-Аналитик. CASE-Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отече- ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных [7, 11, 16]. Его основные функции: • построение и редактирование DFD; • анализ диаграмм и проектных спецификаций на полноту и непротиворечивость; • получение разнообразных отчетов по проекту; • генерация макетов документов в соответствии с требова- ниями ГОСТ серий 19 и 34. БД проекта реализована в формате СУБД Paradox и открыта для доступа. С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ErWin. При этом из проекта, выполненного в CASE-Аналитике, экспортиру- ется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов. Rational Rose. CASE-средство фирмы Rational Software Corporation (США), предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированно- го анализа и проектирования, основанную на подходах трех веду- щих специалистов в данной области — Г. Буча, Д. Рамбо и А. Дже- кобсона. Разработанная ими универсальная нотация для модели- рования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определя- ется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проект- ную документацию в виде диаграмм и спецификаций, а также ге- нерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечиваю- щие повторное использование программных компонент в новых проектах.
132 Глава 2. Анализ предметной области АИС... В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сце- нариев, модулей, процессов [7, 11, 16]. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор доку- ментов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для C++, обеспечивающий ре- инжиниринг — восстановление модели проекта по исходным текстам программ. Репозиторий представляет собой объектно-ориентированную БД. Средства просмотра обеспечивают «навигацию» по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средст- ва контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завер- шения его описания. Генератор отчетов формирует тексты вы- ходных документов на основе содержащейся в репозитории ин- формации. Средства автоматической генерации кодов программ на языке C++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким обра- зом скелет программы может быть уточнен путем прямого про- граммирования на языке C++. Анализатор кодов C++ реализо- ван в виде отдельного программного модуля. Его назначение со- стоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на C++. В процессе работы анализатор осуществляет контроль правильности исходных тек- стов и диагностику ошибок. В результате полученная модель мо- жет целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями на- стройки по входу и выходу (определение типов исходных фай- лов, базового компилятора, задание требований к информации для формируемой модели и т. д.). Таким образом, Rational Rose/C++ обеспечивает возможность повторного использования программных компонентов.
2.6. Системы автоматизированного проектирования АИС 133 В результате разработки проекта АИС с помощью Rational Rose формируются следующие документы: • диаграммы классов; • диаграммы состояний; • диаграммы сценариев; • диаграммы модулей; • диаграммы процессов; • спецификации классов, объектов, атрибутов и операций; • заготовки текстов программ; • модель разрабатываемой программной системы. Последний из перечисленных документов является тексто- вым файлом, содержащим всю необходимую информацию о проекте. Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .срр (заголовки программ для методов). Система включает в программные файлы собственные комментарии, которые начи- наются с последовательности символов //##. Состав информа- ции, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноцен- ные программы. Rational Rose интегрируется со средством PVCS для органи- зации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose возмож- но разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема. Для управляемой подмодели предусмотрены операции: • загрузка подмодели в память; • выгрузка подмодели из памяти; • сохранение подмодели на диске в виде отдельного файла; • установка защиты от модификации; • замена подмодели в памяти на новую. Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управле- ния конфигурацией и контроля версий (PVCS). В этом случае
134 Глава 2. Анализ предметной области АИС... защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разра- ботчику. В этом случае признак защиты от записи устанавлива- ется для файлов, которые содержат подмодели, поэтому при считывании «чужих» подмоделей защита их от модификации со- храняется, и случайные воздействия окажутся невозможными. ErWin, BpWin. Разработаны фирмой Logic Works; с 1998 г. выпускаются под логотипом PLATINUM technology и включены в состав комплекса продуктов и технологий разработки приклад- ного ПО PLATINUM Advantage [7, 11, 16]. BpWin — средство моделирования бизнес-процессов, реали- зующее метод IDEF0 (см. гл. 2). Текущая версия поддерживает также диаграммы потоков данных и потоков работ. В процессе моделирования BpWin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Семейство продуктов ErWin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X (новая версия метода IDEF1, позволяющего по- строить модель данных, эквивалентную реляционной модели в третьей нормальной форме). ErWin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и ре- версный инжиниринг существующей БД. Интегрируется с попу- лярными средствами разработки клиентской части приложений PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложений. Для разных сред разработки реа- лизована различная техника генерации кода. Семейство ErWin не поддерживает непосредственно генерацию кода для Delphi. Его можно сгенерировать с помощью продукта MetaBASE. Для управления групповой разработкой используется средст- во Model Mart, обеспечивающее многопользовательский доступ к моделям, созданным с помощью ErWin и BpWin. Модели хра- нятся на центральном сервере и доступны для всех участников группы проектирования. Модель Model Mart удовлетворяет ряду требований, предъяв- ляемых к средствам управления разработкой крупных АИС, а именно: • совместное моделирование; • создание библиотек решений; • управление доступом.
2.6. Системы автоматизированного проектирования АИС 135 Model Mart включает специальную утилиту — Model Mart Synchronizer, позволяющую проводить синхронизацию моделей процессов (BpWin) и данных (ErWin), хранящихся в библиотеках Model Mart. ErWin поддерживает взаимодействие с Rational Rose: модуль ErWin Translation Wizard позволяет конвертировать объектную модель Rational Rose в модель данных ErWin и обратно и затем с помощью ErWin генерировать схему БД для любой из поддержи- ваемых в ErWin СУБД. Для связывания объектной модели, созданной средствами Pa- radigm Plus, с моделью данных не требуется дополнительных ути- лит. Версия Paradigm Plus 3.6 полностью интегрирована с ErWin. Существует также возможность импорта/экспорта данных из/в репозиторий ErWin и из репозиториев BpWin и Oracle Designer. Oracle Designer. Интегрированное CASE-средство фирмы Oracle, обеспечивающее в совокупности со средствами разработки приложений Oracle Developer и Oracle Application Server поддерж- ку полного ЖЦ ПО для систем, использующих СУБД Oracle. Oracle Designer представляет собой семейство методов и под- держивающих их программных продуктов. Базовый метод Oracle Designer — структурный метод проектирования систем, охваты- вающий полностью все стадии ЖЦ ПО. В настоящее время дан- ный метод продолжает развиваться и поставляется корпорацией Oracle как самостоятельный продукт под названием Custom Development Method (CDM) в совокупности с методами и средст- вами управления проектом Project Management Method (РММ). Версия Oracle Designer для объектно-реляционной СУБД Oracle8i содержит также расширение в виде средств объектного моделирования, базирующихся на стандарте UML. Oracle Designer обеспечивает графический интерфейс при разработке различных моделей предметной области. В процессе построения моделей информация о них заносится в репозито- рий. В состав Oracle Designer входят компоненты: • Repository Administrator — средства управления репозито- рием; • Repository Object Navigator — средство доступа к репозито- рию, обеспечивающее многооконный объектно-ориентиро- ванный интерфейс доступа ко всем элементам репозитория; • Process Modeler — средство анализа и моделирования дея- тельности организации, основывающееся на концепциях
136 Глава 2. Анализ предметной области АИС... реинжиниринга бизнес-процессов и глобальной системы управления качеством; • Systems Modeler — набор средств построения функцио- нальных и информационных моделей проектируемой АИС, включающий средства для построения диаграмм «сущ- ность-связь», диаграмм функциональных иерархий, диа- грамм потоков данных и средство анализа и модификации связей объектов репозитория различных типов; • Systems Designer — набор средств проектирования ПО, включающий средство построения структуры реляционной базы данных, а также средства построения диаграмм, ото- бражающих взаимодействие с данными, иерархию, струк- туру и логику приложений, реализуемых хранимыми про- цедурами на языке PL/SQL; • Server Generator — генератор описаний объектов БД Oracle; • Forms Generator — генератор приложений для Oracle Forms. Генерируемые приложения включают в себя различные эк- ранные формы, средства контроля данных, проверки огра- ничений целостности и автоматические подсказки; • Repository Reports — генератор стандартных отчетов, интег- рированный с Oracle Reports и позволяющий русифициро- вать отчеты, а также изменять структурное представление информации; • репозиторий Oracle Designer представляет собой хранилище всех проектных данных и может работать в многопользова- тельском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически могут генерироваться бо- лее 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных Oracle. Oracle Designer интегрируется с другими средствами с помо- щью открытого интерфейса приложений API. Кроме того, мож- но использовать средство Oracle CASE Exchange для экспор- та/импорта объектов репозитория в целях обмена информацией с другими CASE-средствами. Oracle Developer обеспечивает разработку переносимых при- ложений, работающих в графической среде Windows, Macintosh, Motif. В среде Windows интеграция приложения Oracle Developer с другими средствами реализуется через механизм OLE и управ- ляющие элементы VBX. Взаимодействие приложений с другими
2.6. Системы автоматизированного проектирования АИС 137 СУБД реализуется с помощью средств Oracle Client Adapter для ODCB, Oracle Open Gateway и API. Sybase PowerDesigner 9.0. Полнофункциональный инстру- мент для моделирования бизнес-приложений, включающий в себя средства моделирования бизнес-процессов, сочетающий возможности моделирования UML-объектов с возможностями традиционного проектирования БД и анализа и предоставляю- щий централизованный репозиторий объектов масштаба пред- приятия [7, 11, 16]. В зависимости от требований к проектированию и разработке, можно выбрать только необходимые модули PowerDesigner 9.0. PhysicalArchitect (PDM). Физическое проектирование и гене- рация БД, включая моделирование хранилищ данных. Этот мо- дуль, входящий в состав минимальной конфигурации, обеспечи- вает инструментальные средства, необходимые для создания фи- зических моделей БД (как OLTP, так и OLAP), генерации SQL-кода и реинжиниринга существующих БД из гетерогенных источников. DataArchitect (PDM, CDM). Двухуровневое, итерационное проектирование БД и генерация операторов описания БД (DLL). Поддерживает интегрированное физическое и концепту- альное моделирование данных (включая моделирование храни- лищ данных), позволяя проектировать и генерировать БД для более чем 30 РСУБД и настольных платформ. ObjectArchitect (PDM, CDM, OOM). Объектно-ориентирован- ный анализ и проектирование в комбинации с двухуровневым, итерационным проектированием БД и языком описания БД (DLL). С расширенной поддержкой UML (use case, activity, sequence, диаграммы классов и компонентов), интегрированной с возможностями моделирования данных от DataArchitect, этот модуль делает максимально эффективной работу проектировщи- ков БД и приложений. Developer (PDM, OOM). Объектное моделирование и физиче- ское проектирование БД. Это идеальный инструмент для разра- ботчика. Физическое моделирование данных, интегрированное с UML-моделированием (use case, activity, sequence, диаграммы классов и компонентов), включающее возможности генерации сложного объектного кода и реинжиниринг. Studio (BPM, PDM, CDM, OOM). Поставляемый в редакциях Personal и Enterprise, модуль Studio объединяет в себе технологии моделирования бизнес-процессов с возможностями расширен-
138 Глава 2. Анализ предметной области АИС... ного UML-моделирования и моделирования данных. Комбини- руя все необходимые методы моделирования в одной среде, эти модули дают возможность бизнес- и IT-менеджерам с их коман- дами разработчиков совместно строить бизнес-системы, эффек- тивно поддерживающие работу предприятия. Viewer. Обеспечивает всем IT-специалистам организации единое представление информации о моделировании. Этот мо- дуль, работающий только в режиме чтения (read-only), обеспечи- вает графическое представление информации обо всех смодели- рованных компонентах системы и включает генератор отчетов с расширенной функциональностью. Репозиторий объектов масштаба предприятия обеспечивает: • возможность одновременной работы над одной моделью многих аналитиков и проектировщиков; • хранение, управление и создание версий моделей Power- Designer и других документов; • поиск объектов в модели и их повторное использование в других моделях; • эффективное управление взаимосвязями между моделями. Основные особенности: • моделирование бизнес-процессов на основе диаграмм по- токов управления; • технологии моделирования данных (концептуальная и фи- зическая модель), основанные на индустриальном стандар- те «сущность—связь» (entity—relationship), включая техно- логии моделирования хранилищ данных (схемы «звезда», «снежинка», многомерное моделирование, привязка к кон- кретному источнику данных); • стандартные диаграммы UML: use case, activity, sequence, диаграммы классов и компонентов; • генерация на основе диаграмм классов исходных текстов для Java, C++, PowerBuilder и Visual Basic; • генерация операторов DDL (Data Definition Language) бо- лее чем для 30 РСУБД; • поддержка EJB 2.0; • отображение «сущность—связь»; • определение сложных пользовательских типов данных, включая Java-классы и хранимые Java-процедуры, содержа- щиеся в БД; • обратное проектирование схемы базы данных в концепту- альную и физическую модель;
2.6. Системы автоматизированного проектирования АИС 139 • обратное проектирование существующей бизнес-логики в диаграммы классов (Java и PowerBuilder); • прямое и обратное проектирование XML-приложений в диаграммы классов. Поддержка XML-DTD, XML-схемы и XML-данных; • интеграция с популярными средствами разработки на Java и с ведущими, сертифицированными под J2EE/EJB 2.0 серверами приложений; • современный, графический, настраиваемый пользователь- ский интерфейс, содержащий общую оболочку, обозрева- тель объектов, область редактирования диаграмм и область состояния; • улучшенное управление моделями, включая синхрониза- цию объектов, моделей и баз данных; • расширенный, независимый от модели генератор отчетов, позволяющий получить документ, включающий в себя ин- формацию по нескольким моделям. Web-службы в Sybase PowerDesigner. Описывая все элементы Web-служб совместно со всеми другими элементами организа- ции, PowerDesigner позволяет управлять сложной информацион- ной архитектурой предприятия. Встроенная в среду PowerDesigner, поддержка многочислен- ных языков программирования дает возможность легко доку- ментировать взаимозависимости программных компонентов и Web-служб в гетерогенных средах, используя языки Java с под- держкой J2EE и EJB, PowerBuilder, С, С#, VB, VB.NET и т. д. Используя генерацию объектного кода на основе шаблона, PowerDesigner 9.0 автоматизирует создание кода компонента на выбранном языке программирования, а также WSDL (языка описания Web-служб), требуемого для разработки Web-служб. 2.6.4. Функциональный анализ популярных в России CASE-средств Кроме рассмотренных выше CASE-средств, на российском рынке ПО постоянно появляются их новые версии и модифика- ции, а также еще не локализованные отечественными пользова- телями системы — CASE/4/0, PRO-IV, System Architect, VisibleAnalyst Workbench, EasyCASE [12].
140 Глава 2. Анализ предметной области АИС... Тем не менее наиболее популярными до сих пор остаются средства BpWin/ErWin (Platinum Technology), Rational Rose (Rational Software Corporation) и ARIS (Scheer AG), сравнитель- ный анализ которых представлен в табл. 2.7 [7]. Таблица 2.7. Сравнительный функциональный анализ № Функции, свойства ARIS ErWin/ BpWin Rational Rose 1 Моделирование организационных функ- ций и процессов + + + 2 Разработка технического задания + +/- +/- 3 Функционально-стоимостной анализ + + +/- 4 Оптимизация бизнес-процессов + - 5 Имитационное моделирование, собы- тийно-управляемое моделирование + +/- - 6 Генерация кода приложения - + +/- 7 Оформление проектной документации; генерация технологических инструкций для рабочих мест + +/- + 8 Хранение моделей деятельности пред- приятий + +/- +/- 9 Создание концептуальных и физических моделей структуры базы данных +/- + + 10 Генерация программного кода, SQL-сценариев для создания структуры базы данных - + +/- 11 Стандартное представление основных бизнес-процессов (более 100 типов) + __ - 12 Ведение библиотеки типовых биз- нес-моделей + +/- +/- 13 Групповая работа над проектом + + + 14 Выдача встроенных отчетов по стандар- ту IS09000 + - - Ценовые различия $31 740 (+$14 610) $23 685 (+ $4245) $40 520 (+$?) «+» — да. «+/-»— частичная реализация, требующая доработки иными инструментальными средствами. «-» — нет.
2.6. Системы автоматизированного проектирования АИС 141 Контрольные вопросы 1. Каковы этапы анализа предметной области АИС? 2. Что такое миссия компании? 3. Зачем проводится предпроектное обследование? 4. Назовите методологии моделирования деятельности организации при разработке АИС. 5. Что такое функциональный блок в методологии IDEF? 6. Какие основные понятия используются при построении диаграмм по- токов данных? 7. Перечислите основные связи между аспектами моделирования и UML-диаграммами. 8. Перечислите методы сбора материалов обследования. 9. На какие группы методология ARIS делит бизнес-модели? 10. На какие стандартные вопросы о деятельности организации дает отве- ты UML-модель? 11. Охарактеризуйте системы автоматизированного проектирования АИС. 12. Что такое CASE-технологии? 13. Какие основные задачи решают CASE-средства? 14. Какие способы классификации CASE-средств существуют? 15. Что лежит в основе работы Rational Rose? 16. Каким образом и какие документы формируются в результате раз- работки проекта с помощью CASE-средства Rational Rose? 17. Объясните, как происходит взаимодействие Vantage Team Builder и Uniface. Литература к главе 2 1. Гагарина Л. Г. Автоматизированные информационные системы: учеб, пособие. М.: МИЭТ, 2003. 114 с. 2. Тельнов Ю. Ф. Реинжиниринг бизнес-процессов: учеб, пособие. М.: МЭСИ, 2002. 99 с. 3. Гренул В. И. Проектирование информационных систем, http// www.intuit.ru. 4. Проектирование экономических информационных систем: учебник / под ред. Ю. Ф. Тельнова / Г. Н. Смирнова и др. М.: Финансы и статистика, 2005. 512 с. 5. Вернинов Г. X. Основные методологии обследования организаций. Стандарт IDEF. http://www.vernikov.ru. 6. Петров Ю. А., Шлимович Е. Л., Ирюпин И. В. Комплексная авто- матизация управления предприятием: информационные технологии — тео- рия и практика. М.: Финансы и статистика, 2001. 128 с.
142 Глава 2. Анализ предметной области АИС... 7. Каляное Г. Н. Консалтинг при автоматизации предприятий: подходы, методы, средства. http//www.interface.ru. 8. Ковалев С. М., Ковалев В. М. Современные методологии описания бизнес-процессов — просто о сложном. Ч. 6. // Консультант директора. 2004. № 12. 9. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разра- ботки программного обеспечения. Пер. с англ. СПб.: Питер, 2002. 496 с. 10. Калашян А. Н. Структурные модели бизнеса: DFD-анализ. М.: Фи- нансы и статистика, 2003. 512 с. 11. Вендров А. 44. CASE-технологии. Современные методы и средства проектирования информационных систем, http://citforum.ru. 12. Балдин К. В., Уткин В. Б. Информационные системы в экономике: учебник. 2-е изд. М.: Дашков и К°, 2006. 395 с. 13. Черемных С. В. Структурный анализ систем: IDEF-технологии. М.: Финансы и статистика, 2005. 512 с. 14. Материалы кафедры информатики и математического обеспечения Петрозаводского государственного университета, http://cs.karelia.ru/ ~sigovtse/study_pr/inf_sys/inf_s_book/lecture/15b.html. 15. Clegg, Dai, and Richard Barker. CASE-Method Fast-track. A RAD Approach. on-Wesley, 1994. 16. Вендров A. 44. Проектирование программного обеспечения эконо- мических информационных систем. 2-е изд., перераб. и доп. М.: Финансы и статистика, 2005. 180 с.
Глава 3 РАЗРАБОТКА ПРОГРАММНО-ИНФОРМАЦИОННОГО ЯДРА АИС НА ОСНОВЕ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 3.1. Основы современных систем управления базами данных Для понимания принципов построения систем управления базами данных напомним ряд известных определений. База данных — это набор структурированной информации, предназначенной для совместного употребления несколькими пользователями одновременно. Отдельные элементы данных свя- заны между собой логически. Структурированность означает, что данные имеют некоторую логическую структуру, некоторую схе- му, модель, которая связывает между собой отдельные данные. БД предполагает наличие некоторого программного обеспечения, позволяющего пользователю работать с ней (рис. 3.1) [1, 2]. Рис. 3.1. Компоненты системы баз данных
144 Глава 3. Разработка программно-информационного ядра АИС... Система управления базами данных (СУБД) позволяет созда- вать БД, модифицировать в них данные, разрабатывать пользо- вательские приложения без учета физического представления данных. Прикладные программы относятся к категории приложений. Банк данных — обычно БД или несколько БД, связанных ме- жду собой логически. Схема базы данных описывает взаимоотношения между дан- ными, структуру отдельных компонентов, правила модификации и взаимозависимость между данными. Модель данных — описание принципов, на основе которых построена БД. При разработке БД используют инструменталь- ные программные средства СУБД [3]. Известно, что к числу основных функций СУБД принято от- носить следующие [4]. Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для повышения ско- рости доступа к данным в некоторых случаях (индексирование). В некоторых реализациях СУБД активно используются возмож- ности существующих файловых систем, в других работа произ- водится вплоть до уровня устройств внешней памяти. В разви- тых СУБД пользователи в любом случае не обязаны знать, ис- пользует ли СУБД файловую систему, и если использует, то не обязаны знать, как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД [5]. Управление буферами оперативной памяти. СУБД обычно ра- ботают с БД значительного размера (много больше доступного объема оперативной памяти). Если при обращении к любому элементу данных производится обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней па- мяти. Практически единственным способом реального увеличе- ния этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собствен- ный набор буферов оперативной памяти с собственной дисцип- линой замены буферов.
3.1. Основы современных систем управления базами данных 145 Существует отдельное направление СУБД, которое ориенти- ровано на постоянное присутствие в оперативной памяти всей БД. Это направление основано на предположении, что в буду- щем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований. Управление транзакциями. Транзакция — это последователь- ность операций над БД, рассматриваемых СУБД как единое це- лое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не от- ражается ща состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД |3]. Таким образом, поддержание механизма транзакций являет- ся обязательным условием даже однопользовательских СУБД, в многопользовательских СУБД он строго обязателен. То свойство, что каждая транзакция начинается при целост- ном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование поня- тия транзакции как единицы активности пользователя по отно- шению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, иногда в многопользова- тельских СУБД заметно наличие нескольких пользователей). С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сери- ального плана выполнения смеси транзакций. Под сериализацией параллельно выполняющихся транзакций понимается такой по- рядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последо- вательного выполнения. Сериальный план выполнения смеси транзакций — это такой план, который приводит к сериализа- ции транзакций. Понятно, что если удается добиться действи- тельно сериального выполнения смеси транзакций, то для каж- дого пользователя, по инициативе которого образована транзак- ция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с одно- пользовательским режимом). Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распростране-
146 Глава 3. Разработка программно-информационного ядра АИС... ны алгоритмы, основанные на синхронизационных захватах объ- ектов БД. При использовании любого алгоритма сериализации возможны конфликты между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериали- зации необходимо выполнить откат (ликвидировать все измене- ния, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД мо- жет реально ощутить присутствие в системе транзакций других пользователей [4]. Журнализация и восстановление БД после сбоев. Одним из ос- новных требований к СУБД является надежность хранения дан- ных во внешней памяти. Под надежностью хранения понимают то, что СУБД в состоянии восстановить последнее согласован- ное состояние БД после любого аппаратного или программного сбоя. Обычно рассматривают два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, ава- рийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев являются аварийное завершение работы СУБД (по причине ошибки в программе или в результате неко- торого аппаратного сбоя) или аварийное завершение пользова- тельской программы, в результате чего некоторая транзакция ос- тается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. В любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избы- точности хранения данных, причем та часть данных, которая ис- пользуется для восстановления, должна храниться особо надеж- но. Наиболее распространенным методом поддержания такой из- быточной информации является ведение журнала изменений БД. Журнал — это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда под- держиваются две копии журнала, располагаемые на разных физи- ческих дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуют- ся на разных уровнях: иногда запись в журнале соответствует не- которой логической операции изменения БД (например, опера-
3.1. Основы современных систем управления базами данных 147 ции удаления строки из таблицы реляционной БД), иногда — ми- нимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно использу- ются оба подхода. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log — WAL). Эта стратегия заключается в том, что запись об измене- нии любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД коррект- но соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления — индивидуальный откат транзакции. Строго говоря, для этого не требуется обще- системный журнал изменений БД. Достаточно для каждой тран- закции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат тран- закции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистем- ному журналу, для этого все записи от одной транзакции связы- вают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД мо- гут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объек- ты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов опе- ративной памяти, содержимое которых при мягком сбое пропа- дает). При соблюдении протокола WAL во внешней памяти жур- нала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных тран- закций. Для того чтобы этого добиться, сначала производят от- кат незавершенных транзакций (undo), а потом повторно вос- производят (redo) те операции завершенных транзакций, резуль- таты которых не отображены во внешней памяти. Этот процесс
148 Глава 3. Разработка программно-информационного ядра АИС... содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия — это полная копия БД к моменту начала заполнения журнала (из- вестно несколько вариантов более гибкой трактовки смысла ар- хивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда вос- становление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые за- кончились к моменту сбоя. В принципе, можно даже воспроиз- вести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления по- сле жесткого сбоя является достаточно длительным. Поддержка языков БД. Для работы с БД используются специ- альные языки, в целом называемые языками баз данных. В ран- них СУБД поддерживалось несколько специализированных по своим функциям языков; чаще всего выделялись два — язык описания данных Schema Definition Language (SDL) и язык мани- пулирования данными Data Manipulation Language (DML). SDL служил главным образом для определения логической структуры БД, т. е. той структуры БД, какой она представляется пользовате- лям. DML содержал набор операторов манипулирования данны- ми, т. е. операторов, позволяющих заносить/удалять данные в/из БД, модифицировать или выбирать существующие данные. В современных СУБД обычно поддерживается единый интег- рированный язык, содержащий все необходимые средства для ра- боты с БД (начиная от ее создания) и обеспечивающий базовый пользовательский интерфейс с БД. Стандартным языком наибо- лее распространенных в настоящее время реляционных СУБД является язык Structured Query Language (SQL). Язык SQL, прежде всего, сочетает средства SDL и DML, т. е. позволяет определять структуру реляционной БД и манипулиро- вать данными. При этом именование объектов БД (для реляци- онной БД — именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых
3.1. Основы современных систем управления базами данных 149 служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) во- обще не работает с именами таблиц и их столбцов. Язык SQL содержит специальные средства определения ог- раничений целостности БД. Ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля це- лостности БД производится на языковом уровне, т. е. при ком- пиляции операторов модификации БД компилятор SQL на ос- новании имеющихся в БД ограничений целостности генерирует соответствующий программный код. Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реля- ционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представ- лений можно ограничить или, наоборот, расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Суть со- стоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользо- ватель, создавший таблицу БД, обладает полным набором пол- номочий для работы с этой таблицей, в число которых входит право на передачу всех или части полномочий другим пользова- телям, включая право на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. Организация типичной СУБД и состав ее компонентов соот- ветствует рассмотренному набору функций (управление данны- ми во внешней памяти; управление буферами оперативной па- мяти; управление транзакциями; журнализация и восстановле- ние БД после сбоев; поддержание языков БД). Логически в современной реляционной СУБД выделяют внутреннюю часть — ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему под- держки времени выполнения, набор утилит. В некоторых систе- мах эти части выделяются явно, в других — нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней па- мяти, управление буферами оперативной памяти, управление
150 Глава 3. Разработка программно-информационного ядра АИС... транзакциями и журнализацию. Соответственно, выделяют та- кие компоненты ядра (по крайней мере, логически, хотя в неко- торых системах эти компоненты выделяются явно), как менед- жер данных, менеджер буферов, менеджер транзакций и менед- жер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в програм- мах, производимых компилятором SQL (или в подсистеме под- держки выполнения таких программ), и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использова- нии архитектуры «клиент — сервер» ядро является основной со- ставляющей серверной части системы. Основная функция компилятора языка БД — компиляция операторов языка в некоторую выполняемую программу. Как правило, языки реляционных СУБД, в частности SQL, являются непроцедурными, т. е. в операторе такого языка специфицирует- ся некоторое действие над БД, но эта спецификация лишь опи- сывает в некоторой форме условия совершения желаемого дей- ствия. Поэтому компилятор должен определить, каким образом выполнять оператор языка, прежде чем произвести программу. Результат компиляции — выполняемая программа, представлен- ная в некоторых системах в машинном коде (чаще в выполняе- мом внутреннем машинно-независимом коде). В последнем слу- чае реальное выполнение оператора производится с привлечени- ем подсистемы поддержки времени выполнения, т. е., по сути дела, интерпретатора этого внутреннего языка. В отдельные утилиты БД обычно выделяют такие процеду- ры, которые слишком накладно выполнять с использованием языка БД, например загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т. д. Утилиты програм- мируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра [4]. 3.2. Архитектурные решения баз данных Архитектура БД на основе разделяемых файлов. Применяется для создания локальных сетей на основе файлового сервера. На каждом из персональных компьютеров запускается приложе-
3.2. Архитектурные решения баз данных 151 ние, использующее общие файлы, которые находятся на фай- ловом сервере. В результате можно быстро и дешево запустить однопользовательское приложение в многопользовательском режиме [4]. Среди недостатков архитектуры следует отметить: • низкую пропускную способность сети, большое время ре- акции; • зависимость целостности данных от прикладной програм- мы, а в ней возможны ошибки; • отсутствие механизма для обеспечения одновременного доступа к данным нескольких пользователей; • зависимость от администратора системы в случае аппарат- ного сбоя (отключение питания); проверку и восстановле- ние в течение нескольких часов должен делать только он; • вопрос незакрытых транзакций при аппаратном сбое. Проблемы низкой производительности при интенсивной ра- боте нескольких пользователей и обеспечения целостности — принципиальные и непреодолимые. Такую архитектуру можно использовать для небольшой БД при одновременной работе 5—10 пользователей. Архитектура «хост—терминал». Применяется на рабочем мес- те пользователя (на терминале); производит только физическое отображение и ввод информации. Вся логика приложений и все данные хранятся на центральном компьютере (хосте). Недостатки: • алфавитно-цифровой монохромный интерфейс; • сложность администрирования; • масштабируемость — увеличение числа пользователей при- водит к необходимости аппаратной и программной моди- фикации. Архитектура «клиент—сервер». Предусматривает наличие двух типов программ: программы-клиента (активная) и програм- мы-сервера (пассивная). К функциям сервера БД относят: • выполнение клиентских запросов по извлечению и моди- фикации данных; • предоставление механизма одновременного доступа к дан- ным нескольких пользователей; • обеспечение идентификации и разграничения прав доступа разных пользователей к разным данным;
152 Глава 3. Разработка программно-информационного ядра ЛИС... • обеспечение целостности и непротиворечивости данных в случае аппаратных и программных сбоев; • защиту данных от несанкционированного доступа; • предоставление средств администрирования АИС. Среди функций клиента основными являются: • взаимодействие с пользователем; • выполнение некоторых системных задач, не связанных с внутренним представлением и хранением данных. Архитектура с использованием сервера приложений. В случае, если клиентское приложение достаточно велико, то часть его це- лесообразно выполнять на сервере, особенно при использовании изменяющихся параметров (размер налога и т. п.). Суть реализа- ции сервера приложений заключается в разбиении приложения на две части — собственно клиента и сервера данного приложе- ния. Сервер приложений может быть один для нескольких прило- жений. В отличие от рассмотренных выше архитектурных реше- ний, здесь наличествуют три типа взаимодействующих компонен- тов — сервер БД, приложение (клиент) и сервер приложений [3]. 3.3. Критерии выбора СУБД при создании АИС Выбор СУБД представляет собой сложную многопараметри- ческую задачу и является одним из важных этапов при разработ- ке приложений БД. Программный продукт должен удовлетво- рять как текущим, так и будущим потребностям пользователя, при этом следует учитывать финансовые затраты на приобрете- ние необходимого оборудования, самой системы, разработку программного обеспечения на ее основе, а также обучение пер- сонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды. В данной книге по результатам анализа доступных источни- ков [1] сформулированы требования или критерии выбора СУБД, приводится их классификация. Очевидно, самый простой подход при этом — оценка того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта АИС. Более сложным и дорогостоящим вариантом яв- ляется создание пилотного проекта на основе нескольких СУБД и последующий выбор наиболее подходящей. Вообще говоря, перечень требований к СУБД, используемых при создании той
3.3. Критерии выбора СУБД при создании АИС 153 или иной АИС, может изменяться в зависимости от поставлен- ных целей. Известны следующие группы критериев: • моделирование данных; • особенности архитектуры и функциональные возможности; • контроль работы системы; • особенности разработки приложений; • производительность; • надежность; • требования к рабочей среде; • смешанные критерии. Рассмотрим каждую группу в отдельности, при этом следует заметить, что в состав группы входит несколько компонентов. Моделирование данных. Существует множество моделей дан- ных [7], поэтому вопрос о применении той или иной модели должен решаться на начальном этапе проектирования АИС. К наиболее распространенным среди используемых моделей дан- ных относятся иерархическая, сетевая, реляционная, объект- но-реляционная и объектно-ориентированная. Триггеры и хранимые процедуры. Триггер — программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку лю- бых изменений на корректность, прежде чем эти изменения бу- дут приняты. Хранимая процедура — программа, которая хра- нится на сервере и может вызываться клиентом. Поскольку хра- нимые процедуры выполняются непосредственно на сервере БД, обеспечивается более высокое быстродействие, нежели при вы- полнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты. Средства поиска. Ряд современных систем имеет встроенные дополнительные средства контекстного поиска. Предусмотренные типы данных. Здесь необходимо учесть два фактически независимых критерия: какие типы данных заложе- ны в систему — базовые или основные, и возможны ли расши- рения типов. В то время как отклонения базовых наборов типов данных у современных систем от некоего стандартного, обычно, невелики, механизмы расширения типов данных в системах того или иного производителя существенно различаются. Реализация языка запросов. Все современные системы совмес- тимы со стандартным языком доступа к данным SQL-92, однако реализуют различные расширения данного стандарта.
154 Глава 3. Разработка программно-информационного ядра ЛИС... Особенности архитектуры и функциональные возможности пе- речислены ниже. Мобильность — независимость системы от сре- ды, в которой она работает. Средой в данном случае является как аппаратура, так и программное обеспечение (операционная система). Масштабируемость. При выборе СУБД необходимо учиты- вать, сможет ли данная система обеспечивать развитие АИС, ко- торое может проявляться в увеличении числа пользователей, объ- ема хранимых данных и объема обрабатываемой информации. Распределенность. Основной причиной применения АИС на основе БД является стремление создать единое информационное пространство организации. Самый простой и надежный под- ход — централизация хранения и обработки данных на одном сервере. К сожалению, это не всегда возможно и приходится применять распределенные БД. Различные системы имеют раз- ные возможности управления распределенными БД. Сетевые возможности. Многие системы позволяют исполь- зовать широкий диапазон сетевых протоколов и служб для рабо- ты и администрирования. Контроль работы системы подразумевает наличие нижепере- численных видов контроля. Контроль использования памяти компьютера. В системе пре- дусматривается возможность управления как оперативной памя- тью, так и дисковым пространством. В последнем случае к вы- шесказанному относятся, например, функции сжатия БД или удаления избыточных файлов. Автонастройка. Многие современные системы предусматри- вают самоконфигурирование, которое, как правило, опирается на результаты работы сервисов самодиагностики производитель- ности. При этом выявляются слабые места конфигурации систе- мы, и она автоматически настраивается на максимальную про- изводительность. Особенности разработки приложений. Ряд производителей СУБД выпускает также средства разработки приложений, кото- рые, как правило, позволяют наилучшим образом реализовать все возможности сервера. Поэтому при анализе СУБД следует обратить внимание на особенности средств разработки приложе- ний [4]. Средства проектирования. Некоторые системы имеют средст- ва автоматического проектирования как БД, так и прикладных
3.3. Критерии выбора СУБД при создании АИС 155 программ. Средства проектирования различных производителей могут существенно различаться. Многоязыковая поддержка. Поддержка большого количества национальных языков расширяет область применения системы и приложений, построенных на ее основе. Возможности разработки Web-приложений. При разработке различных приложений зачастую возникает необходимость ис- пользовать возможности среды Internet. Средства разработки не- которых производителей имеют большой набор инструментов для построения приложений под Web. Поддерживаемые языки программирования. Широкий спектр используемых языков программирования может повысить дос- тупность системы для разработчиков, а также существенно по- влиять на быстродействие и функциональность создаваемых при- ложений. Производительность. Для тестирования производительности применяются различные средства и существует множество тесто- вых рейтингов. Рейтинг ТРС (Transactions per Cent) является одним из самых популярных и объективных. Фактически ТРС-анализ произво- дительности систем рассматривает композицию СУБД и аппара- туры, на которой эта СУБД работает. Показатель ТРС — это от- ношение количества запросов, обрабатываемых за некий проме- жуток времени, к стоимости всей системы. Возможности параллельной архитектуры. Для обеспечения параллельной обработки данных существуют как минимум два подхода: распараллеливание обработки последовательности за- просов на несколько процессоров; использование нескольких компьютеров-клиентов, работающих с одной БД, которые объ- единяют в так называемый параллельный сервер. Возможности оптимизирования запросов. При использовании непроцедурных языков запросов их выполнение бывает неопти- мальным. Поэтому необходимо произвести процесс оптимиза- ции, т. е. выбрать такой способ выполнения, когда по начально- му представлению запроса путем его синтаксических и семанти- ческих преобразований вырабатывается процедурный план выполнения запроса, наиболее оптимальный при существующих в БД управляющих структурах. Надежность. Понятие надежности системы трактуется неод- нозначно — это и сохранность информации при любом сбое, и безотказность работы системы в любых условиях, и обеспечение
156 Глава 3. Разработка программно-информационного ядра АИС... защиты данных от несанкционированного доступа [8|. Рассмот- рим некоторые из них. Восстановление после сбоев. При возникновении программных или аппаратных сбоев целостность, да и работоспособность всей системы могут быть нарушены. От того, насколько эффективен механизм восстановления, зависит жизнеспособность системы. Резервное копирование. В результате аппаратного сбоя зачас- тую частично повреждается или выводится из строя носитель информации и тогда восстановление данных невозможно. В этом случае и в ситуациях, когда происходит логический сбой системы (например, при ошибочном удалении таблиц), спасает резервное копирование. Существует множество механизмов ре- зервирования данных (хранение одной или более копий всей БД, хранение копии ее части, копирование логической структу- ры и т. д.). Зачастую в систему закладывается возможность ис- пользования нескольких таких механизмов. Откат изменений. При выполнении транзакции применяется простое правило — либо транзакция выполняется полностью, либо не выполняется вообще. Это означает, что в случае сбоев все результаты недоведенных до конца транзакций должны быть аннулированы. Механизм отката может иметь различное быст- родействие и эффективность. Многоуровневая система защиты. АИС организации почти всегда содержит секретную информацию, поэтому для предотвра- щения несанкционированного доступа используется служба иден- тификации пользователей. Уровень защиты может быть различ- ным. Кроме непосредственной идентификации пользователей, при входе в систему предусматривается также механизм шифрова- ния данных при передаче по линиям связи. Требования к рабочей среде. В качестве требований рассмат- ривают: • поддерживаемые аппаратные платформы; • минимальные требования к оборудованию; • максимальный размер адресуемой памяти. Поскольку почти все современные системы используют свою файловую сис- тему, немаловажным фактором является то, какой макси- мальный объем физической памяти они могут использо- вать. Смешанные критерии. При анализе данной группы очевидна принадлежность существующих критериев к различным пред- метным областям, в связи с чем они и называются смешанными.
3.4. Концептуальные модели данных 157 Качество и полнота документации. Не все системы и не все- гда имеют полную и подробную документацию. Локализованность — возможность использования националь- ных языков; не во всех системах она реализована полностью. Модель формирования стоимости. Как правило, производите- ли СУБД используют определенные модели формирования стои- мости. Так, стоимость одного и того же продукта может сущест- венно изменяться в зависимости от того, сколько пользователей будут с ним работать. Стабильность производителя. Обычно имеют в виду много- летнее (стабильное) присутствие производителя на рыке. Распространенность СУБД. Согласно существующей практи- ке решение об использовании той или иной СУБД принимает один человек — обычно, руководитель предприятия, а он зачас- тую опирается отнюдь не на технические критерии. Здесь свою роль могут сыграть такие незначительные факторы, как реклам- ная раскрутка компании-производителя СУБД, использование конкретных систем на других предприятиях, стоимость. При этом последний фактор может трактоваться и в зависимости от финансового состояния, и в зависимости от политики предпри- ятия. С одной стороны, используется принцип: «Чем дороже, тем лучше», с другой — возможность бесплатной эксплуатации продукта («взлома» лицензионной защиты). [9]. 3.4. Концептуальные модели данных Ядром любой БД является модель данных (МД), которая представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помо- щью МД могут быть представлены объекты предметной области и взаимосвязи между ними [10]. Наиболее распространенные МД уже были перечислены ранее. По способу установления связей между данными СУБД основывается на использовании трех основных видов модели: иерархической, сетевой, реляционной. Однако различия между этими моделями постепенно стираются, что обусловлено, преж- де всего, интенсивными работами в области баз знаний (БЗ) и объектно-ориентированной информационной технологией.
158 Глава 3. Разработка программно-информационного ядра АИС... Каждая из указанных моделей обладает характеристиками, делающими ее наиболее удобной для конкретных приложений. В частности, структура иерархических и сетевых СУБД часто не может быть изменена после ввода данных, тогда как структура реляционных СУБД изменяема в любое время. С другой сторо- ны, для больших БД, структура которых остается длительное время неизменной, и постоянно работающих с ними приложе- ний с интенсивными потоками запросов на БД-обслуживание, именно иерархические и сетевые СУБД являются самыми эф- фективными, так как обеспечивают более быстрый доступ к ин- формации БД, чем реляционные [1, 2]. Иерархическая модель данных. Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Объекты, связанные иерархически- ми отношениями, образуют ориентированный граф (переверну- тое дерево). К основным понятиям иерархической структуры от- носятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы пред- ставляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчи- ненную никакой другой вершине и находящуюся на самом верх- нем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в БД оп- ределяется числом корневых записей. К каждой записи БД су- ществует только один (иерархический) путь от корневой записи. Каждому узлу структуры соответствует один сегмент, представ- ляющий собой поименованный линейный кортеж полей данных. Каждому сегменту (кроме S1-корневого) соответствует один входной и несколько выходных сегментов. Каждый сегмент структуры лежит на единственном иерархическом пути, начи- нающемся от корневого сегмента (рис. 3.2). В настоящее время СУБД, поддерживающие на концептуаль- ном уровне только иерархические модели, не разрабатываются. Как правило, системы, использующие иерархический подход, допускают связывание древовидных структур между собой и/или установление связей внутри них. Это приводит к сетевым дата1- логическим моделям СУБД.
3.4. Концептуальные модели данных 159 Рис. 3.2. Иерархическая модель данных К основным недостаткам иерархических моделей следует от- нести: • неэффективность реализации отношений типа N:N; • медленный доступ к сегментам данных нижних уровней иерархии; • четкую ориентацию на определенные типы запросов и др. В связи с этими недостатками ранее созданные иерархиче- ские СУБД подвергаются существенным модификациям, позво- ляющим поддерживать более сложные типы структур, в первую очередь, сетевые и их модификации (рис. 3.3) [11]. Рис. 3.3. Фрагмент иерархической модели данных Сетевая модель данных. В сетевой структуре при тех же ос- новных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом. Сетевая модель СУБД во многом подобна иерархической: если в иерархической модели
160 Глава 3. Разработка программно-информационного ядра АИС... для каждого сегмента записи допускается только один входной сегмент при N выходных, то в сетевой модели допускается не- сколько входных сегментов наряду с возможностью наличия сег- ментов без входов с точки зрения иерархической структуры [12]. Графическое изображение структуры связей сегментов тако- го типа моделей представляет собой сеть. Сегменты данных в сетевых БД могут иметь множественные связи с сегментами старшего уровня. При этом направление и характер связи в сете- вых БД не являются столь очевидными, как в случае иерархиче- ских БД, поэтому имена и направление связей должны иденти- фицироваться при описании БД (рис. 3.4). Рис. 3.4. Фрагмент сетевой модели данных Таким образом, под сетевой СУБД понимается система, под- держивающая сетевую организацию: любая запись, называемая записью старшего уровня, может содержать данные, которые от- носятся к набору других записей, называемых записями подчи- ненного уровня. Возможно обращение ко всем записям в набо- ре, начиная с записи старшего уровня. Обращение к набору за- писей реализуется по указателям. В рамках сетевых СУБД легко реализуются и иерархические даталогические модели. Сетевые СУБД поддерживают сложные соотношения между типами данных, что делает их пригодными во многих приложениях. Однако пользователи таких СУБД огра- ничены связями, определенными для них разработчиками БД-приложений. Более того, подобно иерархическим сетевые СУБД предполагают разработку БД приложений опытными про- граммистами и системными аналитиками. Среди недостатков сетевых СУБД следует особо отметить проблему обеспечения сохранности информации в БД.
3.4. Концептуальные модели данных 161 Реляционная модель данных. Понятие реляционный (от англ. relation — отношение) связано с разработками известного амери- канского специалиста в области систем баз данных, сотрудника фирмы IBM доктора Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), кото- рый впервые употребил термин «реляционная модель данных». В течение долгого времени реляционный подход рассматри- вался как удобный формальный аппарат анализа БД, не имею- щий практических перспектив, так как его реализация требовала слишком больших машинных ресурсов. Только с появлением персональных ЭВМ реляционные и близкие к ним системы ста- ли самыми распространенными. Реляционная модель данных (РМД) представляет собой на- бор сведений, сгруппированных в одну или несколько таблиц. Таблицу можно представить как двумерный массив или набор записей одинаковой структуры. Записи называют рядами. Таб- лица состоит из рядов и столбцов. Число столбцов и записей для каждой таблицы теоретически не ограничено. Каждый стол- бец имеет определенный тип, неизменный для каждой записи внутри таблицы. Множество возможных значений конкретного столбца называется доменом. Значение каждого атрибута должно быть атомарным, неделимым. Каждый ряд таблицы описывает некий отдельный объект. Связь между таблицами существует на логическом уровне и определяется предметной областью за счет логических связей. Достоинства РМД: • нефункциональное^ языка запроса (SQL) — «что» найти, а не «как» найти. Реляционные СУБД поддерживают Structured Query Language (SQL) — язык структурированных запросов; • высокая стандартизованность; • наличие четких математических основ для работы с дан- ными. Недостаток — ограниченность набора возможных типов данных. Объектно-реляционные модели данных (ОРМД). Расширению возможностей реляционных БД способствует применение в кон- цепции БД понятия объекта, аналогичного понятию объекта в объектно-ориентированном программировании. Это расширение достигается за счет использования таких объектно-ориентиро- ванных компонентов, как пользовательские типы данных, ин-
162 Глава 3. Разработка программно-информационного ядра АИС... капсуляция, полиморфизм, наследование, переопределение ме- тодов и т. п. К сожалению, до настоящего времени разработчики не при- шли к единому мнению о том, как следует определять ОРМД [2]. Модели, поддерживаемые различными производителями СУБД, существенно отличаются по своим функциональным характери- стикам, поэтому о включении объектов в РМД можно говорить только как об общем направлении развития БД. О перспективах этого направления свидетельствует тот факт, что ведущие фир- мы-производители СУБД, в числе которых Oracle, Informix и INGRES, расширили возможности своих продуктов до объект- но-реляционной СУБД (ОРСУБД). В большинстве реализаций ОРМД объектами признаются аг- регат и таблица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, которые являются процедурны- ми объектами БД, и связаны с таблицами. На внутреннем (фи- зическом) уровне все данные ОРБД хранятся в виде отношений, и ОРСУБД поддерживают язык SQL. Объектно-ориентированные модели данных. Еще один подход к построению БД — использование объектно-ориентированных моделей данных (ООМД). Моделирование данных в ООМД ба- зируется на понятии объекта. Для ООМД, как и в случае с ОРМД, не существует общепризнанной модели данных [2]. При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно: встраивание в объект- но-ориентированный язык средств для работы с БД; создание объектно-ориентированных библиотек функций для работы с СУБД; расширение существующего языка работы с БД объект- но-ориентированными функциями; создание нового языка и но- вой объектно-ориентированной модели данных. К достоинствам ООМД относят широкие возможности моде- лирования предметной области, выразительный язык запросов и повышенную производительность. Эти модели обычно применя- ются для сложных предметных областей, для моделирования ко- торых не хватает функциональности реляционной модели (на- пример, систем автоматизации проектирования, издательских систем и т. п.). Среди недостатков ООМД следует отметить отсутствие уни- версальной модели, недостаток опыта создания и эксплуатации
3.5. Базовые понятия реляционных баз данных 163 ООБД, сложность использования и недостаточность средств за- щиты данных. В 1997 г. рабочая группа Object Database Management Group (ODMG), образованная фирмами-производителями ООСУБД, выпустила стандарт ODMG 2.0 для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки C++, Smalltalk и Java. 3.5. Базовые понятия реляционных баз данных К основным понятиям реляционных БД относятся тип дан- ных, домен, атрибут, кортеж, первичный ключ и отношение [4]. Покажем смысл этих понятий на примере отношения СО- ТРУДНИКИ, содержащего информацию о сотрудниках некото- рой организации (рис. 3.5) [4]. Типы данных Рис. 3.5. Базовые понятия реляционных БД
164 Глава 3. Разработка программно-информационного ядра АИС... Тип данных. Понятие тип данных в реляционной модели дан- ных полностью адекватно понятию типа данных в языках про- граммирования. Обычно в современных реляционных БД допус- кается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких, как «деньги»), а также специальных «темпоральных» данных (дата, время, вре- менной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги» [1, 4]. Домен. Понятие домена более специфично для БД, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется за- данием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент дан- ных является элементом домена [1, 4]. Наиболее правильной интуитивной трактовкой понятия до- мена является понимание домена как допустимого потенциаль- ного множества значений данного типа. Например, домен «Име- на» в нашем примере определен на базовом типе строк симво- лов, но в число его значений могут входить только те строки, которые отображают имя (в частности, такие строки не могут начинаться с мягкого знака). Следует отметить также семантическую нагрузку понятия до- мена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения до- менов «Номера пропусков» и «Номера отделов» относятся к типу целых чисел, но не являются сравнимыми. Схема отношения, схема базы данных. Схема отношения — это именованное множество пар [имя атрибута, имя домена (или типа, если понятие домена не поддерживается)]. Степень или «арность» схемы отношения — мощность этого множества. Сте- пень отношения СОТРУДНИКИ равна четырем, т. е. оно явля- ется 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конеч- но, о том, что это является всего лишь удобным способом име-
3.5. Базовые понятия реляционных баз данных 165 нования и не устраняет различия между понятиями домена и ат- рибута). В структурном смысле схема БД — это набор именован- ных схем отношений. Ключи. Для идентификации записей используются ключи. Ключ — набор атрибутов, который позволяет идентифицировать запись внутри таблицы, при этом никакие подмножества этих атрибутов не будут ключом. Простой ключ состоит из одного ат- рибута, составной ключ — из двух и более. Атрибут, входящий в тот или иной ключ, называется ключевым атрибутом. Атрибут, который не входит ни в один из ключей, называется неключе- вым атрибутом. Ключ должен гарантировать уникальную иден- тификацию записи для всех возможных комбинаций записей в отношении. Некоторый ключ, который выделяют разработчики или проектировщики БД, называется первичным. Первичным может считаться любой ключ. Ключи бывают естественными и искусственными. Естественный ключ состоит из реальных атри- бутов. Искусственный ключ вводится специально fl, 4]. Кортеж, отношение. Кортеж, соответствующий данной схеме отношения, — это множество пар [имя атрибута, значение], ко- торое содержит одно вхождение каждого имени атрибута, при- надлежащего схеме отношения. «Значение» является допусти- мым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или «арность» кортежа, т. е. число элементов в нем, совпадает с «ар- ностью» соответствующей схемы отношения. Попросту говоря, кортеж — это набор именованных значений заданного типа. Отношение — это множество кортежей, соответствующих од- ной схеме отношения. Иногда, чтобы не путаться, говорят «от- ношение-схема» и «отношение-экземпляр», или схему отноше- ния называют заголовком отношения, а отношение как набор кортежей — телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Удобно и логично было бы отдельно определять схему отношения, а затем одно или несколько отно- шений с данной схемой. Однако в реляционных БД это не при- нято. Имя схемы отношения в таких БД всегда совпадает с име- нем соответствующего отношения-экземпляра. В классических реляционных БД после определения схемы БД изменяются толь- ко отношения-экземпляры. В них могут появляться новые и уда- ляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы БД:
166 Глава 3. Разработка программно-информационного ядра АИС... определение новых и изменение существующих схем отноше- ния. Такой процесс называют эволюцией схемы базы данных. Обычным представлением отношения является таблица, за- головком которой является схема отношения, а строками — кор- тежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «стол- бец таблицы», имея в виду «атрибут отношения» (эта терминоло- гия используется при рассмотрении практических вопросов ор- ганизации реляционных БД и средств управления, а также в большинстве коммерческих реляционных СУБД). Реляционная база данных — это набор отношений, имена ко- торых совпадают с именами схем отношений в схеме БД. Основ- ные структурные понятия реляционной модели данных (не счи- тая понятия «домен») имеют очень простую интуитивную интер- претацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно. 3.6. Проектирование реляционных баз. данных с использованием нормализации Сначала рассмотрим классический подход, при котором про- цесс проектирования сводится (с применением терминологии реляционной модели данных методом последовательных прибли- жений) к удовлетворительному набору схем отношений. Исход- ной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проекти- рования производится некоторый набор схем отношений, обла- дающих лучшими свойствами. Процесс проектирования пред- ставляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает лучшими свойст- вами, чем предыдущая [13]. Каждой нормальной форме соответствует некоторый опреде- ленный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набо- ру ограничений. Примером набора ограничений является огра- ничение первой нормальной формы — значения всех атрибутов отношения атомарны. Поскольку требование первой нормаль- ной формы является базовым требованием классической реля- ционной модели данных, будем считать, что исходный набор от- ношений уже соответствует этому требованию.
3.6. Проектирование реляционных баз данных... 167 В теории реляционных БД обычно выделяют следующую по- следовательность нормальных форм [4]: • первая нормальная форма (1NF); • вторая нормальная форма (2NF); • третья нормальная форма (3NF); • нормальная форма Бойса — Кодда (BCNF); • четвертая нормальная форма (4NF); • пятая нормальная форма, или нормальная форма проек- ции-соединения (5NF или PJ/NF). Основные свойства нормальных форм: • каждая следующая нормальная форма в некотором смысле лучше предыдущей; • при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе проектирования РБД лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нор- мальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отноше- ний основываются на фундаментальном в теории реляционных БД понятии функциональной зависимости. Для дальнейшего из- ложения нам потребуется несколько определений. 1. Функциональная зависимость. В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть состав- ными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (г) R.Y. 2. Полная функциональная зависимость. Функциональная за- висимость R.X (г) R.Y называется полной, если атрибут Y не за- висит функционально от любого точного подмножества X. 3. Транзитивная функциональная зависимость. Функциональ- ная зависимость R.X R.Y называется транзитивной, если су- ществует такой атрибут Z, что имеются функциональные зависи- мости R.X R.Z и R.Z -> R.Y, и отсутствует функциональная зависимость R.Z -> R.X. (При отсутствии последнего требования мы имели бы «неинтересные» транзитивные зависимости в лю- бом отношении, обладающем несколькими ключами.) 4. Неключевой атрибут. Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).
168 Глава 3. Разработка программно-информационного ядра АИС... 5. Взаимно независимые атрибуты. Два атрибута или более взаимно независимы, если ни один из этих атрибутов не являет- ся функционально зависимым от других. 6. Вторая нормальная форма. Рассмотрим следующий пример схемы отношения: СОТРУДНИКИ-ОТДЕЛ Ы-ПРОЕКТЫ (СОТРНОМЕР, СОТРЗАРП, ОТД_НОМЕР, ПРО НОМЕР, СОТРЗАДАН) Первичный ключ: СОТР НОМЕР, ПРО НОМЕР Функциональные зависимости: СОТР НОМЕР -> СОТР ЗАРП СОТР НОМЕР -> ОТДНОМЕР ОТДНОМЕР -> СОТР ЗАРП СОТР НОМЕР, ПРО НОМЕР^ СОТР_ЗАДАН Понятно, что хотя первичным ключом является составной атрибут СОТР НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД НОМЕР функционально зависят от части первичного ключа, атрибута СОТР НОМЕР. В результате невозможно вста- вить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кор- теж, описывающий сотрудника, который еще не выполняет ни- какого проекта (первичный ключ не может содержать неопреде- ленное значение). При удалении кортежа не только разрушается связь данного сотрудника с данным проектом, но и утрачивает- ся информация о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел необходимо модифициро- вать все кортежи, описывающие этого сотрудника, иначе полу- чится несогласованный результат. Подобные явления называют- ся аномалиями схемы отношения. Они устраняются путем нор- мализации. Дадим теперь определение второй нормальной формы (в этом определении предполагается, что единственным ключом отношения является первичный ключ). Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый не- ключевой атрибут полностью зависит от первичного ключа.
3.6. Проектирование реляционных баз данных... 169 Произведем следующую декомпозицию отношения СО- ТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУД- НИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ: СОТРУДНИКИ-ОТДЕЛЫ (СОТР НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР) Первичный ключ: СОТРНОМЕР Функциональные зависимости: СОТР НОМЕР -> СОТРЗАРП СОТР НОМЕР ОТДНОМЕР ОТДНОМЕР СОТРЗАРП СОТРУДНИКИ-ПРОЕКТЫ (СОТР НОМЕР, ПРО НОМЕР, СОТР_ ЗАДАН) Первичный ключ: СОТР НОМЕР, ПРО_НОМЕР Функциональные зависимости: СОТР НОМЕР, ПРО НОМЕР -у СОТР__ЗАДАН Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем). Если допустить наличие нескольких ключей, то определе- ние 6 примет следующий вид. Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда оно находится в 1NF, и каждый неключевой атрибут полностью за- висит от каждого ключа R. Здесь и далее мы не будем приводить примеры для отноше- ний с несколькими ключами. Они слишком громоздки и отно- сятся к ситуациям, редко встречающимся на практике. 7. Третья нормальная форма. Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР НОМЕР -> СОТР ЗАРП является транзитивной; она является следствием функциональ- ных зависимостей СОТР НОМЕР -> ОТД НОМЕР и ОТД НО- МЕР -> СОТР ЗАРП. Другими словами, заработная плата со-
170 Глава 3. Разработка программно-информационного ядра АИС... трудника на самом деле является характеристикой не сотрудни- ка, а отдела, в котором он работает (это нс очень естественное предположение, но достаточное для примера). В результате невозможно занести в базу данных информа- цию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первич- ный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данно- го отдела, исчезает информация о заработной плате отдела. Для того чтобы согласованным образом изменить заработную плату отдела, необходимо предварительно найти все кортежи, описы- вающие сотрудников этого отдела, т. е. в отношении СОТРУД- НИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации. Дадим теперь определение третьей нормальной формы (сно- ва определение дается в предположении существования единст- венного ключа.) Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не- ключевой атрибут нетранзитивно зависит от первичного ключа. Произведем декомпозицию отношения СОТРУДНИКИ-ОТ- ДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ: СОТРУДНИКИ (СОТРНОМЕР, ОТДНОМЕР) Первичный ключ: СОТРНОМЕР Функциональные зависимости: СОТР НОМЕР -> ОТД НОМЕР ОТДЕЛЫ (ОТД НОМЕР, СОТР_ЗАРП) Первичный ключ: ОТДНОМЕР Функциональные зависимости: ОТД НОМЕР -т СОТР_ЗАРП Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий. Если отказаться от того ограничения,
3.6. Проектирование реляционных баз данных... 171 что отношение обладает единственным ключом, то определение 3NF примет следующий вид. Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 1NF, и каждый не- ключевой атрибут не является транзитивно зависимым от како- го-либо ключа R. На практике третья нормальная форма схем отношений дос- таточна в большинстве случаев, и приведением к третьей нор- мальной форме процесс проектирования реляционной базы дан- ных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации. 8. Нормальная форма Бойса — Кодда. Рассмотрим следующий пример схемы отношения СОТРУДНИКИ-ПРОЕКТЫ (СОТР НОМЕР, СОТР_ИМЯ, ПРОНОМ ЕР, СОТРЗАДАН) Возможные ключи: СОТР_НОМЕР, ПРО НОМЕР СОТР-ИМЯ, ПРО НОМЕР Функциональные зависимости: СОТР НОМЕР -> СОТР_ИМЯ СОТР НОМЕР -> ПРО НОМЕР СОТРИМЯ -> СОТР НОМЕР СОТРИМЯ -> ПРО НОМЕР СОТР НОМЕР, ПРО НОМЕР -> СОТР ЗАДАН СОТР ИМЯ, ПРО НОМЕР -> СОТР ЗАДАН В этом примере предполагается, что личность сотрудника полностью определяется как его номером, так и именем (не очень жизненно, но облегчает понимание). В соответствии с определением 7 отношение СОТРУДНИ- КИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, приводит к аномалиям (для того чтобы изменить имя сотрудника с данным номером со- гласованным образом, потребуется модифицировать все корте- жи, включающие его номер). Для дальнейших рассуждений не- обходимо дать определение детерминанта.
172 Глава 3. Разработка программно-информационного ядра АИС... Детерминант — любой атрибут, от которого полностью функ- ционально зависит некоторый другой атрибут. Отношение R находится в нормальной форме Бойса — Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом. Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Произведем его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИК И-ПРОЕКТЫ: СОТРУДНИКИ (СОТР НОМЕР, СОТР_ИМЯ) Возможные ключи: СОТРНОМЕР СОТРИМЯ Функциональные зависимости: СОТР НОМЕР -> СОТР_ИМЯ СОТР-ИМЯ -> СОТР_НОМЕР СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО НОМЕР, СОТР ЗАДАН) Возможный ключ: СОТР НОМЕР, ПРО НОМЕР Функциональные зависимости: СОТР НОМЕР, ПРО НОМЕР -> СОТР_ЗАДАН Возможна альтернативная декомпозиция, если выбрать за основу СОТР ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им нс свойственны отмеченные аномалии. 9. Четвертая нормальная форма. Рассмотрим пример следую- щей схемы отношения. ПРОЕКТЫ (ПРО НОМЕР, ПРО_СОТР, ПРО_ЗАДАН) Отношение ПРОЕКТЫ содержит номера проектов, для каж- дого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Со- трудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
3.6. Проектирование реляционных баз данных... 173 Каждый кортеж отношения связывает некоторый проекте со- трудником, участвующим в этом проекте, и заданием, которое со- трудник выполняет в рамках данного проекта (полагаем, что лю- бой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). По причине сформулирован- ных выше условий единственным возможным ключом отноше- ния является составной атрибут ПРО НОМЕР, ПРО СОТР, ПРОЗАДАН, и нет никаких других детерминантов. Следователь- но, отношение ПРОЕКТЫ находится в BCNF, но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отно- шение ПРОЕКТЫ столько кортежей, сколько заданий в нем пре- дусмотрено. В отношении R (А, В, С) существует многозначная зависи- мость R.A -> -> R.B в том и только в том случае, если множество значений В, соответствующее паре значений А и С, зависит только от А и нс зависит от С. В отношении ПРОЕКТЫ существует две многозначные за- висимости: ПРО НОМЕР -> -> ПРО_СОТР ПРОНОМЕР -> -> ПРО ЗАДАН Легко показать, что в общем случае в отношении R (А, В, С) существует многозначная зависимость R.A > -> R.B в том и только в том случае, если существует многозначная зависи- мость R.A -э- -э- R.C. Дальнейшая нормализация отношений, подобных отноше- нию ПРОЕКТЫ, основывается на теореме Фейджина. Отношение R(A, В, С) можно спроецировать без потерь в от- ношения R1(A, В) и R2(A, С) в том и только в том случае, если существует MVD А -> -> В | С. Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естест- венного соединения полученных отношений. Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования много- значной зависимости А -э- -э- В все остальные атрибуты R функ- ционально зависят от А.
174 Глава 3. Разработка программно-информационного ядра АИС... Произведем декомпозицию отношения ПРОЕКТЫ в два от- ношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ: ПРОЕКТЫ-СОТРУДНИКИ (ПРО НОМЕР, ПРО_СОТР) ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН) Оба эти отношения находятся в 4NF и свободны от отмечен- ных аномалий. 10. Пятая нормальная форма. Во всех рассмотренных норма- лизациях производилась декомпозиция одного отношения в два. Иногда это сделать не удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучши- ми свойствами. Рассмотрим, например, отношение: СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД НОМЕР, ПРО НОМЕР) Предположим, что один и тот же сотрудник работает в не- скольких отделах и в каждом отделе работает над несколькими проектами. Первичным ключом этого отношения является пол- ная совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости, поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые уст- ранимы путем декомпозиции в три отношения. Отношение R(X, Y, ..., Z) удовлетворяет зависимости соеди- нения * (X, Y, ..., Z) в том и только в том случае, если R восста- навливается без потерь путем соединения своих проекций на X, Y, ..., Z. Отношение R находится в пятой нормальной форме (нормаль- ной форме проекции-соединения — PJ/NF) в том и только в том случае, если любая зависимость соединения в R следует из суще- ствования некоторого возможного ключа в R. Введем следующие имена составных атрибутов: СО = {СОТР_НОМЕР, ОТД НОМЕР} СП = {СОТР НОМЕР, ПРО НОМЕР} ОП = {ОТД НОМЕР, ПРО_НОМЕР} Предположим, что в отношении СОТРУДНИКИ-ОТДЕ- ЛЫ-ПРОЕКТЫ существует зависимость соединения: * (СО, СП, ОП)
3.7. Концептуальные модели и схемы баз данных 175 На примерах легко показать, что при вставках и удалениях кортежей возникают проблемы. Их можно устранить путем де- композиции исходного отношения в три новых отношения: СОТРУДНИКИ-ОТДЕЛЫ (СОТР НОМЕР, ОТДНОМЕР) СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР) ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР) Пятая нормальная форма — это последняя нормальная фор- ма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Заметим, что зависимость соединения является обобщением как многозначной, так и функциональной зависимости. 3.7. Концептуальные модели и схемы баз данных Широкое распространение реляционных СУБД и их использо- вание в самых разнообразных приложениях показывает, что реля- ционная модель данных достаточна для моделирования предмет- ных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного выше ме- ханизма нормализации зачастую представляет собой очень слож- ный и неудобный для проектировщика процесс [4]. При этом про- является ограниченность РМД в следующих аспектах. Модель не предоставляет достаточных средств для передачи смысла данных. Семантика реальной предметной области долж- на в независимости от модели представляться в голове проекти- ровщика. В частности, это относится к упомянутой выше про- блеме представления ограничений целостности. Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой на- чальной стадии проектирования разработчику приходится при- лагать массу усилий, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы. Несмотря на то, что весь процесс проектирования происхо- дит с учетом зависимостей, реляционная модель не предусмат- ривает средств для их представления. Процесс проектирования начинается с выделения некоторых существенных для приложе- ния объектов предметной области («сущностей») и выявления связей между этими сущностями, тем нс менее РМД не предла- гает какого-либо аппарата для разделения сущностей и связей.
176 Глава 3. Разработка программно-информационного ядра АИС... Потребности проектировщиков БД в более удобных и мощ- ных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных (СМД). При том, что любая развитая семантическая модель данных, как и РМД, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных. Чаше всего на практике семантическое моделирование ис- пользуется на первой стадии проектирования БД. При этом в терминах СМД производится концептуальная схема БД, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме согласно методикам, где достаточно четко огово- рены все этапы преобразования. Реже реализуется автоматизированная компиляция концепту- альной схемы в реляционную. При этом известны два подхода: на основе явного представления концептуальной схемы как исходной информации для компилятора и построения интегрированных систем проектирования с автоматизированным созданием концеп- туальной схемы на основе интервью с экспертами предметной об- ласти. И в том, и в другом случае в результате производится реля- ционная схема БД в третьей нормальной форме. Наконец, третья возможность, реализуемая пока только в рамках исследовательских и экспериментальных проектов, — это работа с БД в семантической модели, т. е. СУБД, основанные на СМД. При этом снова рассматриваются два варианта: обеспече- ние пользовательского интерфейса на основе СМД с автомати- ческим отображением конструкций в РМД (задача примерно того же уровня сложности, что и автоматическая компиляция концептуальной схемы БД в реляционную схему) и прямая реа- лизация СУБД, основанная на какой-либо СМД. Второй вари- ант наиболее приемлем для современных объектно-ориентиро- ванных СУБД, модели данных которых по многим параметрам близки к семантическим моделям. 3.7.1. Диаграммное представление Рассмотрим особенности одной из наиболее популярных СМД — модели «сущность—связи» (часто ее называют кратко ER-моделью, ER-диаграммой; предложена П. Ченом (Chen) в 1976 г.).
3.7. Концептуальные модели и схемы баз данных 177 Использование разновидностей ER-модели лежит в основе большинства современных подходов к проектированию БД (глав- ным образом, реляционных). Моделирование предметной облас- ти базируется на использовании графических диаграмм, вклю- чающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем БД ER-моде- ли получили широкое распространение в CASE-системах, под- держивающих автоматизированное проектирование реляционных БД. Рассмотрим структурную часть такой модели в CASE-системе фирмы ORACLE. Основные понятия ER-модели. Сущность — это реальный или представляемый объект, информация о котором должна сохра- няться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущ- ности. При этом имя сущности — имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительно- сти и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа. На рис. 3.6 изображена сущность АЭРОПОРТ с примерными объектами Шереметьево и Хитроу [4]. АЭРОПОРТ Шереметьево, Хитроу Рис. 3.6. Сущность АЭРОПОРТ Каждый экземпляр сущности необходимо отличать от любо- го другого экземпляра той же сущности (это требование в неко- тором роде аналогично требованию отсутствия кортежей-дубли- катов в реляционных таблицах). Связь — это графически изображаемая ассоциация, устанав- ливаемая между двумя сущностями. Эта ассоциация всегда явля- ется бинарной и может существовать между двумя разными сущ- ностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из ко- торых указывается имя конца связи, степень конца связи (сколь- ко экземпляров данной сущности связывается), обязательность связи (т. е. любой ли экземпляр данной сущности должен участ- вовать в данной связи).
178 Глава 3. Разработка программно-информационного ядра АИС... Связь представляется в виде линии, связывающей две сущ- ности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используется трехточеч- ный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущно- сти, и одноточечный вход, если в связи может участвовать толь- ко один экземпляр сущности. Обязательный конец связи изо- бражается сплошной линией, а необязательный — прерывистой линией. Как и сущность, связь — это типовое понятие, все экземпля- ры обеих пар связываемых сущностей подчиняются правилам связывания. В примере на рис. 3.7 изображена связь между сущностями БИЛЕТ и ПАССАЖИР. Конец сущности с именем «для» позво- ляет связывать с одним пассажиром более одного билета (связь поэтому называется «один ко многим»), причем каждый билет должен быть связан с каким-либо пассажиром; конец сущности с именем «имеет» означает, что каждый билет может принадле- жать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет [4]. БИЛЕТ ПАССАЖИР Для Имеет Рис. 3.7. Изображение связи «один ко многим». Лаконичной устной трактовкой изображенной диаграммы является следующая: • каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА; • каждый ПАССАЖИР может иметь один или более БИЛЕ- ТОВ. В следующем примере изображена рекурсивная связь, связы- вающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с име- нем «сын» определяет тот факт, что у одного отца может быть бо- лее одного сына. Конец связи с именем «отец» означает, что не у каждого человека могут быть сыновья (рис. 3.8) [4]. Лаконичной устной трактовкой изображенной диаграммы является следующая: • каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;
3.7. Концептуальные модели и схемы баз данных 179 Рис. 3.8. Пример рекурсивной связи • каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ («ЧЕЛОВЕКОВ»), Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой ха- рактеристики или выражения состояния сущности (рис. 3.9). Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буква- ми (можно с примерами) [4]. Рис. 3.9. Изображение сущности с атрибутами Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа. Нормальные формы ER-схем. Как и в реляционных схемах БД, в ER-схемах вводится понятие нормальных форм, причем по смыслу они очень близки. Заметим, что формулировки нормаль- ных форм ER-схем делают более понятным смысл нормализации реляционных схем. Ниже приведены очень краткие и нефор- мальные определения трех первых нормальных форм. В первой нормальной форме ER-схемы устраняются повто- ряющиеся атрибуты или группы атрибутов, т. е. производится выявление неявных сущностей, «замаскированных» под атри- буты. Во второй нормальной форме устраняются атрибуты, завися- щие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
180 Глава 3. Разработка программно-информационного ядра АИС... В третьей нормальной форме устраняются атрибуты, завися- щие от атрибутов, нс входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности. Более сложные элементы ER-модели рассмотрим на примере самых основных и наиболее очевидных понятиях ER-модели данных [4]. Подтипы и супертипы сущностей. В языках программирова- ния с развитыми типовыми системами (в языках объектно-ори- ентированного программирования) вводится возможность на- следования типа сущности, исходя из одного или нескольких су- пертипов. Связи «тапу-Ю-тапу». Иногда необходимо связать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены коопе- ратива сообща владеют имуществом кооператива). Для этого вводится разновидность связи «многие-ко-многим». Уточняемые степени связи. Иногда необходимо определить возможное количество экземпляров сущности, участвующих в данной связи (например, разработчику запрещено участвовать более чем в тре,х проектах одновременно). Для выражения этого семантического ограничения на конце связи указывают ее мак- симальную или обязательную степень. Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи «один-ко-многим»), что при удалении опорного экземпляра сущ- ности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие концу связи «мно- гие». Соответствующее требование «каскадного удаления» можно сформулировать при определении сущности. Домены. Как и в случае реляционной модели данных, бывает полезно определить потенциально допустимое множество значе- ний атрибута сущности (домена). Вышеперечисленные и другие более сложные элементы ER-диаграммы «сущность—связи» делают ее существенно более мощной, но одновременно несколько усложняют ее использова- ние. Естественно, при реальном использовании ER-диаграмм для проектирования БД необходимо ознакомиться со всеми воз- можностями. Рассмотрим теперь подробнее один из упомянутых элемен- тов — подтип сущности.
3.7. Концептуальные модели и схемы баз данных 181 Сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие ат- рибуты и/или связи, явно определяемые один раз на более вы- соком уровне. В подтипах могут определяться собственные ат- рибуты и/или связи. В принципе подтипизацию продолжают и на более низких уровнях, но в большинстве случаев достаточно двух-трех уровней. Сущность, на основе которой определяются подтипы, назы- вается супертипом. Подтипы должны образовывать полное мно- жество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты приходится опреде- лять дополнительный подтип ПРОЧИЕ (рис. 3.10) [4]. Летательный аппарат Аэроплан Планер Моторный самолет Вертолет Птицелет Прочие Рис. 3.10. Пример сущности супертипа Дадим словесную интерпретацию графического изображе- ния. От супертипа: ЛЕТАТЕЛЬНЫЙ АППАРАТ, который дол- жен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМ ЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТО- ЛЕТ, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипом: АЭ- РОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППА- РАТА и должен быть ПЛАНЕРОМ или МОТОРНЫМ САМО- ЛЕТОМ. Иногда удобно иметь два или более разных разбиения сущ- ности на подтипы. Например, сущность ЧЕЛОВЕК можно раз- бить на подтипы по профессиональному признаку (ПРОГРАМ- МИСТ, ДОЯРКА и т. д.); по половому признаку (МУЖЧИНА,
182 Глава 3. Разработка программно-информационного ядра АИС... ЖЕНЩИНА); по квалификационному (ТЕХНИК, ИНЖЕНЕР, МАГИСТР и т. д.) Получение реляционной схемы из ER-диаграммы. Для реаль- ного использования вышеприведенного материала необходима, кроме прочего, методика создания таблицы из ER-диаграммы. Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность — сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы. Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столб- цы, соответствующие необязательным атрибутам, могут содер- жать неопределенные значения; столбцы, соответствующие обя- зательным атрибутам, — не могут. Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется не- сколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентифи- катора входят связи, к числу столбцов первичного ключа добав- ляется копия уникального идентификатора сущности, находя- щейся на дальнем конце связи (этот процесс может продолжать- ся рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей. Шаг 4. Связи «один-ко-многим» (и «один-к-одному») стано- вятся внешними ключами, т. е. делается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ. Необязательные связи соот- ветствуют столбцам, допускающим неопределенные значения; обязательные связи — столбцам, не допускающим неопределен- ные значения. Шаг 5. Индексы создаются для первичного ключа (уникаль- ный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы. Шаг 6. Если в концептуальной схеме присутствовали подти- пы, то возможны два способа (табл. 3.1): а) все подтипы в одной таблице; б) для каждого подтипа — отдельная таблица. При применении способа а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться пред- ставления. В таблицу добавляется, по крайней мере, один стол- бец, содержащий код ТИПА; он становится частью первичного ключа.
3.7. Концептуальные модели и схемы баз данных 183 При использовании метода о) для каждого подтипа первого уровня (для более нижних — представления) супертип воссозда- ется с помощью представления UNION (из всех таблиц подти- пов выбираются общие столбцы — столбцы супертипа). Таблица 3./. Преимущества и недостатки способов создания таблицы Все в одной таблице Таблица — на подтип Преимущества Все хранится вместе Легкий доступ к супертипу и подтипам Требуется меньше таблиц Более ясны правила подтипов Программы работают только с нужными таб- лицами Недостатки Слишком общее решение Требуется дополнительная логика работы с разными наборами столбцов и разными огра- ничениями Потенциальное узкое место (в связи с блоки- ровками) Столбцы подтипов должны быть необязатель- ными В некоторых СУБД для хранения неопределен- ных значений требуется дополнительная память Слишком много таблиц Смущающие столбцы в представлении UNION Потенциальная потеря производительности при работе через UNION Над супертипом невозможны модификации Шаг 7. Имеется два способа работы при наличии исключаю- щих связей (табл. 3.2): а) общий домен; б) явные внешние ключи. Если остающиеся внешние ключи все в одном домене, т. е. имеют общий формат (способ а), то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец иден- тификатора связи используется для различения связей, покры- ваемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентифика- тора сущности на дальнем конце соответствующей связи. Если результирующие внешние ключи не относятся к одно- му домену, то для каждой связи, покрываемой дугой исключе- ния, создаются явные столбцы внешних ключей; все эти столб- цы могут содержать неопределенные значения.
184 Глава 3. Разработка программно-информационного ядра АИС... Таблица 3.2. Преимущества и недостатки способов работы при наличии исключаю- щих связей Общий домен Явные внешние ключи Преимущества Нужно только два столбца Условия соединения — явные Недостатки Оба дополнительных атрибута должны ис- Слишком много столбцов пользоваться в соединениях Альтернативные модели сущностей [4] приведены на рис. 3.11—3.13. Вариант 2 гораздо лучше варианта 1, если подти- пы действительно существуют. В свою очередь, вариант 3 намно- го лучше варианта 3 при наличии осмысленного супертипа D. Рис. 3.11. Вариант I. Связи сущностей Рис. 3.12. Вариант 2. Связи сущностей при существовании подтипов Рис. 3.13. Вариант 3. Связь сущностей при наличии супертипа D
3.7. Концептуальные модели и схемы баз данных 185 3.7.2. Виды нотаций Кроме вышеприведенного способа представления ER-диа- грамм, существуют и другие. Рассмотрим их подробнее. Case-метод Баркера. Нотация ER-диаграммы была впервые введена П. Ченом и получила дальнейшее развитие в работах Р. Баркера'. Метод Баркера изложен на примере предметной об- ласти компании по торговле автомобилями по результатам опро- са персонала компании. Главный менеджер. Одна из основных обязанностей — содер- жание автомобильного парка, т. е. ему известно, сколько запла- чено за машины и каковы накладные расходы. Обладая этой ин- формацией, он устанавливает минимальную цену, за которую можно продать конкретный экземпляр. Кроме того, он несет от- ветственность за продавцов и обязан знать, кто что продает и сколько уже продал. Продавец. Он обязан знать, какую цену запрашивать и какова нижняя граница сделки. Кроме того, он должен владеть инфор- мацией о машинах: год выпуска, марка, модель и т. п. Администратор. Его задача сводится к составлению контрак- тов, для этого нужна информация о покупателе, автомашине и продавце, поскольку именно контракты приносят продавцам вознаграждения за продажи. Первый шаг моделирования — анализ информации в резуль- тате опроса и выделение сущностей (рис. 3.14). Определение сущности было приведено ранее. <имя сущности» Рис. 3.14. Графическое изображение сущности Каждая сущность должна обладать уникальным идентифика- тором [14]. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать не- которыми свойствами: • иметь уникальное имя, и к одному и тому же имени долж- на всегда применяться одна и та же интерпретация. Одна и 1 Barker R. CASE*Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.
186 Глава 3. Разработка программно-информационного ядра АИС... та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами; • обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь; • обладать одним или несколькими атрибутами, которые од- нозначно идентифицируют каждый экземпляр сущности; • может обладать любым количеством связей с другими сущ- ностями. Из приведенных выше сведений следует, что сущности, ко- торые могут быть идентифицированы с главным менеджером — это автомашины и продавцы. Продавцу важны автомашины и связанные с их продажей данные. Для администратора важны покупатели, автомашины, продавцы и контракты. Исходя из этого, выделяются четыре сущности (автомашина, продавец, по- купатель, контракт), которые изображаются на диаграмме сле- дующим образом (рис. 3.15). Автомашина Продавец Покупатель Контракт Рис. 3.15. Выделенные сущности Следующим шагом моделирования является идентификация связей. Уточним понятие связи, приведенное ранее. Связь — это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, на- зываемой сущностью-потомком, а каждый экземпляр сущно- сти-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущность-пото- мок может существовать только при существовании сущно- сти-родителя. Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникаль- ным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением, имени сущ- ности-родителя, имени связи, выражения степени и имени сущ- ности-потомка.
3.7. Концептуальные модели и схемы баз данных 187 Например, связь продавца с контрактом может быть выраже- на следующим образом: • продавец может получить вознаграждение за один или бо- лее контрактов; • контракт должен быть инициирован ровно одним про- давцом. Степень связи и обязательность графически изображаются следующим образом (рис. 3.16) [14]. ------Много ---------Необязательная -------- Один --------- Обязательная Рис. 3.16. Графическое изображение степени связей и обязательности Таким образом, два предложения, описывающие связь про- давца с контрактом, графически будут выражены следующим об- разом (рис. 3.17) [14]. Продавец Контракт Рис. 3.17. Изображение связи между сущностями «продавец» и «контракт» Описав также связи остальных сущностей, получим следую- щую схему (рис. 3.18) [14]. Контракт Рис. 3.18. Диаграмма связей между сущностями Последним шагом моделирования является идентификация атрибутов (определение атрибута приводилось ранее). Атрибут представляет тип характеристик или свойств, ассо- циированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т. д.). Экземпляр атрибута — это определенная характеристика отдель- ного элемента множества; определяется типом характеристики и
188 Глава 3. Разработка программно-информационного ядра АИС... ее значением, называемым значением атрибута. В ER-модели ат- рибуты ассоциируются с конкретными сущностями. Таким обра- зом, экземпляр сущности должен обладать единственным опреде- ленным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязатель- ным (рис. 3.19) [14]. Обязательность означает, что атрибут не мо- жет принимать неопределенных значений (null values). Атрибут может быть либо описательным (т. е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа). Уникальный идентификатор — это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-ро- дителя (рис. 3.20) [14]. <имя сущности> *<атрибут-1> * — обязательный атрибут; о — необязательный атрибут Рис. 3.19. Изображение атрибутов сущности Полная идентификация Идентификация посредством другой сущности Рис. 3.20. Изображение вида идентификации сущности Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом существительного, опи- сывающим представляемую атрибутом характеристику. Атрибу- ты изображаются в виде списка имен внутри блока ассоцииро- ванной сущности, причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещают- ся наверху списка и выделяются знаком «#». Каждая сущность должна обладать хотя бы одним возмож- ным ключом. Возможный ключ сущности — это один или не-
3.7. Концептуальные модели и схемы баз данных 189 сколько атрибутов, чьи значения однозначно определяют каж- дый экземпляр сущности. При существовании нескольких воз- можных ключей один из них обозначается в качестве первичного ключа, а остальные — как альтернативные ключи. С учетом имеющейся информации дополним построенную ранее диаграмму (рис. 3.21) [14]. цена । Контракт # и/Н (идентификационный номер) * Дата I ''Автомашина #Р/Н ‘ год * марка * модель * запраши- ваемая Рис. 3.21. Дополненная диаграмма связей сущностей Основы методологии IDEF1. Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между ин- формационными потоками в рамках коммерческой деятельности предприятия. Целью подобного исследования является дополне- ние и структуризация существующей информации и обеспече- ние качественного менеджмента информационными потоками. Необходимость в подобной реорганизации информационной об- ласти, как правило, возникает на начальном этапе построения корпоративной АИС, и методология 1DEF1 позволяет достаточ- но наглядно обнаружить «черные дыры» и слабые места в суще- ствующей структуре информационных потоков. Применение ме- тодологии IDEF1, как инструмента построения наглядной моде- ли информационной структуры предприятия по принципу «как должно быть», позволяет решить следующие задачи: • выяснить структуру и содержание существующих потоков информации на предприятии; • определить существующие правила и законы, по которым осуществляется движение информационных потоков, а также принципов управления ими;
190 Глава 3. Разработка программно-информационного ядра АИС... • определить, какие проблемы, выявленные в результате функционального анализа и анализа потребностей, вызваны недостатком управления соответствующей информацией; • выявить информационные потоки, требующие дополни- тельного управления для эффективной реализации модели. Характерно, что с помощью IDEF1-модели рассматривают не только автоматизированные компоненты, БД и соответствую- щую им информацию, но и реальные объекты, такие как сами сотрудники, кабинеты, телефоны и т. д. В отличие от методов разработки структур БД (IDEF1X), IDEF1 является аналитиче- ским методом. Результаты анализа информационных потоков могут быть использованы для стратегического и тактического планирования деятельности предприятия и улучшения информа- ционного менеджмента. Основные преимущества IDEFI. Методология IDEF1 позволя- ет на основе простых графических изображений моделировать информационные взаимосвязи и различия между: • реальными объектами; • физическими и абстрактными зависимостями, существую- щими среди реальных объектов; • информацией, относящейся к реальным объектам; • структурой данных, используемой для приобретения, нако- пления, применения и управления информацией. Концепции моделирования IDEF1. При построении информа- ционной модели разработчик всегда оперирует двумя основны- ми глобальными областями, каждой из которых соответствует множество характерных объектов. Первой из этих областей яв- ляется реальный мир, или же совокупность физических и интел- лектуальных объектов, таких, как люди, места, вещи, идеи и т. д., а также все свойства этих объектов и зависимости между ними. Второй же является информационная область. Она вклю- чает в себя существующие информационные отображения объ- ектов первой области и их свойств. Информационное отображе- ние, по существу, не является объектом реального мира, однако изменение его, как правило, является следствием некоторого из- менения соответствующего ему объекта реального мира. Мето- дология IDEF1 разработана как инструмент для исследования статического соответствия вышеуказанных областей и установ- ления строгих правил и механизмов изменения объектов инфор- мационной области при изменении соответствующих им объек- тов реального мира.
3.7. Концептуальные модели и схемы баз данных 191 Терминология и семантика 1DEFI. Методология IDEF1 разде- ляет элементы структуры информационной области, их свойства и взаимосвязи на классы. Центральным понятием методологии 1DEF1 является понятие сущности. Класс сущностей представ- ляет собой совокупность информации, накопленной и храня- щейся в рамках предприятия и соответствующей определенному объекту или группе объектов реального мира. Основными кон- цептуальными свойствами сущностей в IDEF1 являются: 1) устойчивость. Информация, имеющая отношение к той или иной сущности, постоянно накапливается; 2) уникальность. Любая сущность может быть однозначно идентифицирована из другой сущности. Каждая сущность имеет свое имя и атрибуты. Класс атрибу- тов представляет собой набор пар, состоящих из имени атрибута и его значения для определенной сущности. Каждая сущность может характеризоваться несколькими ключевыми атрибутами. Класс взаимосвязей в IDEF1 представляет собой совокупность взаимосвязей между сущностями. Взаимосвязь между двумя от- дельными сущностями считается существующей в том случае, когда класс атрибутов одной сущности содержит ключевые атри- буты другой сущности. Каждый из вышеописанных классов име- ет свое условное графическое отображение. На рис. 3.22 приведен пример IDEF1-диаграммы [15]. На ней представлены две сущности с именами «Отдел» и «Сотрудник» и взаимозвязь между ними с именем «работает в». Имя взаимосвязи Взаимосвязь Имя сущности Рис. 3.22. Пример 1DEF1-диаграммы
192 Глава 3. Разработка программно-информационного ядра АИС... всегда выражается в глагольной форме. Если же между двумя или несколькими объектами реального мира не существует установ- ленной зависимости, то с точки зрения IDEF1 между соответст- вующими им сущностями взаимосвязь также отсутствует [ 15]. Основы методологии IDEF1X. IDEF1X является методом раз- работки реляционных БД и использует условный синтаксис, специально созданный для удобства построения концептуальной схемы. Концептуальной схемой называют универсальное пред- ставление структуры данных в рамках коммерческого предпри- ятия, независимое от конечной реализации БД и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «as is» («как есть»), тем не менее он иногда применя- ется в этом качестве, как альтернатива методу IDEF1. Использо- вание метода IDEF1X наиболее целесообразно для построения логической структуры БД после того, как все информационные ресурсы исследованы (например, с помощью метода IDEF1) и решение о внедрении реляционной БД, как части корпоратив- ной АИС, принято. Следует заметить, что средства моделирова- ния IDEF1X специально разработаны для построения реляцион- ных информационных систем, и если необходимо разработать другую систему (например, объектно-ориентированную), то луч- ше избрать другие методы моделирования. Существует несколько очевидных причин, по которым IDEF1X не следует применять в случае построения нереляцион- ных систем. Во-первых, IDEF1X требует от проектировщика оп- ределения ключевых атрибутов, для того чтобы отличить одну сущность от другой, в то время как объектно-ориентированные системы не требуют задания ключей в целях идентифицирова- ния объектов. Во-вторых, в тех случаях, когда более чем один ат- рибут является однозначно идентифицирующим сущность, раз- работчик должен определить один из этих атрибутов первичным ключом, а все остальные — вторичными. Таким образом постро- енная и переданная для окончательной реализации программи- сту IDEFlX-модель является некорректной для применения ме- тодов объектно-ориентированной реализации; она предназначе- на для построения реляционной системы. Концепция и семантика IDEFIX. Несмотря на то, что терми- нология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических кон- цепциях этих методологий. Сущность в IDEF1X описывает сово-
3.7. Концептуальные модели и схемы баз данных 193 купность или набор экземпляров похожих по свойствам, но од- нозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира в отличие от сущности в IDEF1, ко- торая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X мо- жет быть сущность «СОТРУДНИК», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущно- сти. На рис. 3.22 каждый экземпляр сущности СОТРУДНИК со- держит следующую информацию: ID сотрудника, имя сотрудни- ка, адрес сотрудника и т. п. В IDEFlX-модели эти свойства назы- ваются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности. Связи между сущностями в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Фактиче- ски, связи — суть глаголы, которые показывают, как соотносят- ся сущности между собой, что демонстрирует ряд нижеприве- денных примеров. Отдел <состоит из> нескольких Сотрудников. Самолет <перевозит> нескольких Пассажиров. Сотрудник <пишет> разные Отчеты. Здесь взаимосвязи между сущностями соответствуют схеме «один-ко-многим», т. е. один экземпляр первой сущности связан с месколькими экземплярами второй сущности. Причем первая сущ- ность является родительской, а вторая — дочерней. В приведенных примерах глаголы заключены в угловые скобки. Связи отобража- ются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. Диаграмма связи между Сотрудником и Отделом приведена на рис. 3.22. Отношения «многие-ко-многим» обычно используются на начальной стадии разработки диаграммы, например, в диаграм- ме зависимости сущностей и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах. Поскольку отно- шения «многие-ко-многим» могут скрыть другие бизнес-правила •или ограничения, они должны быть полностью исследованы на одном из этапов моделирования. Например, иногда отношение «многие-ко-многим» на ранних стадиях моделирования иденти- фицируется неправильно, на самом деле представляя два или не-
194 Глава 3. Разработка программно-информационного ядра АИС... сколько случаев отношений «один-ко-многим» между связанны- ми сущностями. Или в случае необходимости хранения допол- нительных сведений о связи «многие-ко-многим», например, даты или комментария, такая связь должна быть заменена до- полнительной сущностью, содержащей эти сведения. При моде- лировании необходимо иметь в виду, что все отношения «мно- гие-ко-многим» следует подробно обсудить на более поздних стадиях моделирования в целях правильного моделирования от- ношений. Идентификация сущностей. Представление о ключах. Сущ- ность в диаграмме IDEF1X описывается графическим объектом в виде прямоугольника. На рис. 3.23 приведен пример IDEF1X- диаграммы [16]. Каждый прямоугольник, отображающий сущ- ность, разделяется горизонтальной линией на части. Верхняя часть называется ключевой областью (в ней расположены клю- чевые поля), а нижняя часть — областью данных (в ней располо- жены неключевые поля). Ключевая область объекта СОТРУД- НИК содержит поле «Уникальный идентификатор сотрудника», в области данных находятся поля «Имя сотрудника», «Адрес со- трудника», «Телефон сотрудника» и т. д. Ключевая область содержит первичный ключ для сущности или набор атрибутов, выбранных для идентификации уникаль- ных экземпляров сущности. Атрибуты первичного ключа распо- Рис. 3.23. Пример IDEFlX-диаграммы
3.7. Концептуальные модели и схемы баз данных 195 лагаются над линией в ключевой области. Неключевые атрибуты располагаются в области данных. При создании сущности в IDEFlX-модели одним из главных вопросов является вопрос: «Как идентифицировать уникальную запись?». Требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в IDEF1X всегда имеют клю- чевую область, поэтому в каждой сущности должны быть опре- делены ключевые атрибуты. Выбор первичного ключа для сущности очень важен и требу- ет особого внимания. В качестве первичных ключей используют несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются канди- датами в ключевые атрибуты (потенциальные атрибуты); они должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей. Например, для того чтобы корректно использовать сущность СОТРУДНИК в IDEFlX-модели данных (и далее, в базе дан- ных), необходимо уникально идентифицировать записи. Прави- ла, по которым выбирается первичный ключ из списка предпо- лагаемых ключей, очень жесткие, тем не менее их применяют ко всем типам баз данных и информации. Согласно правилам, ат- рибуты и группы атрибутов должны: • уникальным образом идентифицировать экземпляр сущ- ности; • не использовать NULL-значений; • не изменяться со временем. Экземпляр идентифицируется с помощью ключа. При изменении ключа, экземпляр соот- ветственно меняется; • быть как можно короче для индексирования и получения данных. При использовании ключа, являющегося комби- нацией ключей из других сущностей, необходимо убедить- ся в том, что каждая часть ключа соответствует правилам. Для наглядного представления о том, как следует подходить к выбору первичных ключей, найдем первичный ключ для сущ- ности СОТРУДНИК: • Атрибут «ID сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности СОТРУД- НИК.
196 Глава 3. Разработка программно-информационного ядра АИС... • Атрибут «Имя сотрудника» не очень хорош для потенци- ального ключа, так как среди служащих на предприятии может быть, к примеру, двое Иванов Петровых. • Атрибут «Номер страхового полиса сотрудника» является уникальным, но проблема в том, что СОТРУДНИК может не иметь такового. • Комбинация атрибутов «Имя сотрудника» и «Дата рожде- ния сотрудника» может оказаться удачной для наших целей и стать искомым потенциальным ключом. После проведенного анализа назовем два потенциальных ключа: первый — «Номер сотрудника», второй — комбинация, включающая поля «Имя сотрудника» и «Дата рождения сотруд- ника». Поскольку атрибут «Номер сотрудника» имеет самые ко- роткие и уникальные значения, то он больше других подходит для первичного ключа. При выборе первичного ключа для сущности разработчики модели часто используют дополнительный (суррогатный) ключ, т. е. произвольный номер, который уникальным образом опре- деляет запись в сущности. Атрибут «Номер сотрудника» является примером суррогатного ключа. Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что является корот- ким и быстрее всего идентифицирует экземпляры в объекте. К тому же, система способна генерировать суррогатные ключи так, чтобы нумерация была сплошной, т. е. без пропусков. Потенциальные ключи, которые не выбраны первичными, могут использоваться в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Если сущности в IDEFlX-диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи опре- деляются как атрибуты первичных ключей родительского объек- та, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими. Классификация сущностей в IDEF1X. Зависимые и независимые сущности. При разработке модели зачастую приходится сталки- ваться с сущностями, уникальность которых зависит от значе- ний атрибута внешнего ключа. Для этих сущностей (для уни-
3.7. Концептуальные модели и схемы баз данных 197 кального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта. Дочерняя сущность, уникальность которой зависит от атри- бута внешнего ключа, называется зависимой сущностью. Сущ- ность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ. В обозначени- ях IDEFIX зависимые сущности представлены в виде закруглен- ных прямоугольников. Зависимые сущности далее классифицируются как сущно- сти, которые не могут существовать без родительской сущности и сущности, которые не идентифицируются без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависи- мых сущностей, так как сотрудники могут существовать и без отдела. Напротив, существуют ситуации, в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАПРОС, используемый для отслеживания запросов покупате- лей, и ПОЗИЦИЯ ЗАПРОСА, которая отслеживает отдельные элементы в ЗАПРОСЕ. Связь между этими сущностями можно выразить в виде ЗАПРОС <содержит> одну или несколько ПО- ЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зави- сит от существования ЗАКАЗА. Сущности, независящие при идентификации от других объ- ектов в модели, называются независимыми сущностями. В выше- описанном примере сущность ОТДЕЛ — независимая. В IDEF1X независимые сущности представлены в виде прямоугольников. Типы связей между сущностями. Идентифицирующие и неиден- тифицирующие связи. В IDEF1X концепция зависимых и незави- симых сущностей усиливается типом взаимосвязей. Пусть необ- ходимо, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), тогда следует создать идентифицирующую связь между родительской и дочер- ней сущностью. Идентифицирующие взаимосвязи между сущно- стями обозначаются сплошной линией. Неидентифицирующие связи, являющиеся уникальными для IDEF1X, также связывают родительскую сущность с дочерней. Эти связи используются для отображения другого типа передачи атрибутов внешних ключей — передачи в область данных дочер- ней сущности (под линией).
198 Глава 3. Разработка программно-информационного ядра АИС... Неидентифицирующие связи отображаются пунктирной ли- нией между объектами. Поскольку переданные ключи в неиден- тифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности. Тем не менее взаимосвязь отражает зависимость существова- ния, если бизнес-правило для взаимосвязи определяет, что внешний ключ не может принимать значение NULL. Если су- ществует внешний ключ, то это означает, что запись в дочерней сущности может существовать только при наличии ассоцииро- ванной с ним родительской записи. Преимущества 1DEF1X. Основным преимуществом IDEF1X [16] по сравнению с другими методами разработки реляцион- ных БД является жесткая и строгая стандартизация моделирова- ния. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком ER-диаграмм. 3.8. Средства автоматизированного проектирования структур баз данных Ранее (гл. 2) был представлен обзор CASE-инструментария для анализа и проектирования АИС, рассмотрены и охарактери- зованы наиболее популярные на отечественном рынке интегри- рованные CASE-средства. Остановимся теперь на особенностях CASE-средств, применяемых для проектирования структур БД, как программно-информационного ядра АИС, перечень кото- рых с указанием фирмы-производителя и адреса сайта в глобаль- ной сети приведен в табл. 3.3. Следует отметить, что многие из этих продуктов предназначены не только для проектирования БД, но и для решения других задач, таких, как моделирование потоков данных или бизнес-процессов, функциональное моде- лирование, прототипирование приложений, их документирова- ние, управление проектами и т. д. ER/Studio фирмы Embarcadero Technologies по своему назна- чению сходен с ErWin представляет собой специализированное средство проектирования данных и не содержит в своем составе инструментов для объектно-ориентированного моделирования
3.8. Средства автоматизированного проектирования... 199 Таблица 3.3. Средства проектирования структур баз данных CASE-средство Производитель URL Designer 2000 Oracle http://www.oracle.com/ ErWin Computer Associates http://www.cai.com/ PowerDesigner Sybase http://www.sybase.com/ ER/Studio Embarcadero http://www.embarcadero.com/ System Architect Popkin Software http://www.popkin.com/ Visible Analyst Visible Systems http://www.visible.com Visio Enterprise Microsoft http://www.microsoft.com/ или моделирования бизнес-процессов [17]. Список поддерживае- мых СУБД у этого продукта достаточно широк и включает все наиболее популярные серверные и настольные СУБД. В отличие от ErWin, последняя версия ER/Studio поддерживает новые типы данных SQL Server 7. К особенностям пакета относится написание макросов на SAX Basic (клон Visual Basic for Applications) для выполнения од- нотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. Этот же язык позволяет генери- ровать стандартные триггеры и хранимые процедуры для встав- ки, удаления, изменения записей. Можно даже отлаживать код на этом языке и обращаться к свойствам сущностей для конст- руирования серверного кода. Однако, в отличие от ErWin, ER/Studio не позволяет добавлять к каждой таблице свои шабло- ны триггеров или просматривать код конкретного триггера в процессе разработки модели; чтобы получить код одного тригге- ра, нужно сгенерировать скрипт для всей модели. Модели ER/Studio сохраняют не только в виде DDL-скрип- та, но и в формате XML. Предусмотрена возможность создания репозитария для их хранения в любой серверной СУБД. ER/Studio позволяет импортировать модели ErWin, но при им- порте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ErWin корректно преобразуются в макросы SAX Basic. Программный пакет также предусматривает генерацию Java-классов для клиентских приложений.
200 Глава 3. Разработка программно-информационного ядра АИС... Кроме того, ER/Studio является COM-сервером, т. е. приго- ден для использования в других приложениях с возможностью просмотра и редактирования моделей данных, а также для созда- ния других решений на его основе [17]. System Architect 2001 фирмы Popkin Software представляет со- бой универсальное CASE-средство, позволяющее осуществить не только проектирование данных, но и структурное моделиро- вание [18]. Средство создания ER-диаграмм является одной из составных частей этого продукта. System Architect 2001 поддерживает СУБД практически всех ведущих производителей, включая Oracle (Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase, Access, dBASE, Paradox и др. В процессе логического моделирования позволяет проверять модель на соответствие правилам проектирования БД (на соответствие ее первой, второй или третьей нормальным формам). При генерации DDL-скрипта можно сгенерировать триггеры (в том числе и нестандартные). Все компоненты System Architect позволяют документиро- вать процесс работы над проектом, включая техническое зада- ние, план тестирования и др. Модели System Architect 2001 при необходимости сохраняют в репозитарии, однако в отличие от традиционных репозитариев с более или менее стандартной структурой хранимых данных, этот является настраиваемым — к сохраняемым объектам можно до- бавлять дополнительные свойства, определенные пользователем. System Architect обладает встроенным языком Visual Basic for Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моде- лей и проектной документации. System Architect 2001 при необходимости генерирует код кли- ентских приложений для Visual Basic, Delphi и PowerBuilder (на сегодняшний день это практически единственное CASE-средст- во, поддерживающее генерацию кода Delphi), классы C++, а так- же код и текстовые экранные формы COBOL [18]. Visible Analyst фирмы Visible Systems Corporation — весьма популярный продукт; широко известны также ранее производи- мые компанией CASE-средства EasyER и EasyCASE — предше- ственники Visible Analyst [19]. Продукт выпускается в трех модификациях. Первая — Visible Analyst DB Engineer, включает средства проектирования данных; Visible Analyst Standard, кроме проектирования БД, позволяет
3.8. Средства автоматизированного проектирования... 201 осуществлять структурное моделирование; третья модифика- ция — Visible Analyst Corporate, помимо указанных выше функ- ций, осуществляет также объектно-ориентированное моделиро- вание. Visible Analyst поддерживает довольно широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server (System 10 и 4.x); Informix, DB2, Ingres. Последние версии многих серверных СУБД (Oracle 8, Microsoft SQL Server 6.5/7/2000, последние версии серверов Sybase) в этом списке пока отсутствуют. Для Informix и DB2 указанный продукт позволяет генериро- вать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных сервер- ных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными (fill factor), а также создавать кластеризо- ванные индексы и генерировать триггеры для выполнения стан- дартных операций. Из этих же СУБД можно производить непо- средственно обратное проектирование. Помимо этих двух СУБД обратное проектирование производится из DDL-скриптов, сге- нерированных для других СУБД, а также на основе кода COBOL. Модели Visible Analyst можно сохранять в многопользова- тельском репозитарии, созданном в одной из серверных СУБД. Кроме того, Visible Analyst позволяет на основе созданных моде- лей генерировать код для Visual Basic, C++ и COBOL [19]. Visio Enterprise фирмы Microsoft. Продукт под названием Visio, приобретенный в январе 2000 г. корпорацией Microsoft вместе с его разработчиком — компанией Visio Corporation, пози- ционировался на рынке как одно из самых популярных средств создания схем и диаграмм. Модификация Microsoft Visio 2000 — Visio 2000 Enterprise — содержит в своем составе полноценное CASE-средство [20]. Visio Enterprise позволяет производить прямое и обратное проектирование БД, преобразовывать логическую модель в фи- зическую. Этим средством поддерживаются все ODBC- и OLE DB-источники данных. С его помощью создаются триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Отметим, что Visio при генерации скриптов позволяет указывать
202 Глава 3. Разработка программно-информационного ядра АИС... параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД. Помимо средств проектирования баз данных Visio включает средства объектно-ориентированного моделирования и генера- ции кода приложений Visual Basic 6, а также классов C++ и Java. Модели Visio можно сохранять в Microsoft Repository. В отличие от специализированных средств проектирования данных, Visio нс обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте, однако и стоимость Visio Enterprise по сравнению с ErWin или PowerDesigner DataArchitect невысока, тем более что Visio в це- лом представляет собой продукт более широкого назначения. К тому же продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки — Visual Basic for Applications, что позволяет, в част- ности, создавать на его базе разнообразные решения, в том чис- ле и автоматизировать разработку моделей данных [20]. Vantage Team Builder фирмы Westmount I-CASE. Согласно [4] характерной особенностью этого программного продукта являет- ся использование одного из вариантов нотации П. Чена. На ER-диаграммах сущность обозначается прямоугольником, содер- жащим ее имя (рис. 3.24), а связь — ромбом, связанным линией с каждой из взаимодействующих сущностей. Числа над линиями означают степень связи. Рис. 3.24. Обозначение сущностей и связей Связи являются многонаправленными и могут иметь атрибу- ты (за исключением ключевых). Кроме того, выделяют следую- щие виды связей. В необязательной связи (рис. 3.25) могут участвовать не все экземпляры сущности. В отличие от необязательной в полной (total) связи участвуют все экземпляры хотя бы одной из сущностей, т. е. экземпляры такой связи существуют только при условии существования эк- земпляров другой сущности. Полная связь может иметь один из
3.8. Средства автоматизированного проектирования... 203 Рис. 3.25. Необязательная связь четырех видов: обязательная связь, слабая связь, связь «супер- тип—подтип» и ассоциативная связь. Обязательная (mandatory) связь описывает связь между неза- висимой и зависимой сущностями. Все экземпляры зависимой (обязательной) сущности существуют только при наличии эк- земпляров независимой (необязательной) сущности, т. е. экзем- пляр обязательной сущности существует только при условии су- ществования определенного экземпляра необязательной сущно- сти. Так, на рис. 3.26 показано, что каждый автомобиль имеет, по крайней мере, одного водителя, но не каждый служащий управляет машиной. Рис. 3.26. Обязательная связь В слабой связи существование одной из сущностей (слабой), принадлежащей некоторому множеству, зависит от существования определенной сущности (сильной), принадлежащей другому мно- жеству, т. е. экземпляр слабой сущности идентифицируется толь- ко посредством экземпляра сильной сущности. Ключ сильной сущности является частью составного ключа слабой сущности. Слабая связь всегда является бинарной и подразумевает обя- зательную связь для слабой сущности. Сущность бывает слабой в одной связи и сильной в другой, но не может быть слабой бо- лее чем в одной связи. Слабая связь может не иметь атрибутов. Как показано на рис. 3.27, ключ (номер) строки в документе может не быть уникальным и должен быть дополнен ключом до- кумента. Рис. 3.27. Слабая связь Связь «супертип—подтип» изображена на рис. 3.28. Общие характеристики (атрибуты) типа определяются в сущности-су-
204 Глава 3. Разработка программно-информационного ядра АИС... Рис. 3.28. Связь «супертип—подтип» пертипе, сущность-подтип наследует все характеристики супер- типа. Экземпляр подтипа существует только при условии сущест- вования определенного экземпляра супертипа. Подтип не может иметь ключ (он импортирует ключ из супертипа). Сущность, яв- ляющаяся супертипом в одной связи, может быть подтипом в другой. Связь супертипа не может иметь атрибутов. В ассоциативной связи каждый экземпляр связи (ассоциатив- ный объект) существует только при условии существования оп- ределенных экземпляров каждой из взаимосвязанных сущно- стей. Ассоциативный объект — объект, являющийся одновре- менно сущностью и связью. Ассоциативная связь — это связь между несколькими независимыми сущностями и одной зависи- мой сущностью. Связь между независимыми сущностями имеет атрибуты, которые определяются в зависимой сущности. Таким образом, зависимая сущность определяется в терминах атрибу- тов связи между остальными сущностями. Иллюстрация указанной связи приведена на рис. 3.29: само- лет выполняет посадку на взлетную полосу в заданное время при определенной скорости и направлении ветра. Поскольку эти ха- рактеристики применимы только к конкретной посадке, они яв- ляются атрибутами посадки, а не самолета или взлетной полосы. Пилот, выполняющий посадку, связан гораздо сильнее с кон- кретной посадкой, чем с самолетом или взлетной полосой. Рис. 3.29. Ассоциативная связь Первичный ключ каждого типа сущности помечается звез- дочкой (*).
3.8. Средства автоматизированного проектирования... 205 В свою очередь ER-диаграмма строится по следующим пра- вилам [4]: • каждая сущность, каждый атрибут и каждая связь должны иметь имя (связь супертипа или ассоциативная связь может не иметь имени); • имя сущности должно быть уникально в рамках модели данных; • имя атрибута должно быть уникально в рамках сущности; • имя связи должно быть уникально, если для нее генериру- ется таблица БД; • каждый атрибут должен иметь определение типа данных; • сущность в необязательной связи должна иметь ключевой атрибут. То же самое относится к сильной сущности в сла- бой связи, супертипу в связи «супсртип—подтип» и необя- зательной сущности в обязательной (полной) связи; • подтип в связи «супертип—подтип» не может иметь ключе- вой атрибут; • в ассоциативной или слабой связи может быть только одна ассоциативная (слабая) сущность; • связь не может быть одновременно обязательной, «супер- типом—подтипом» или ассоциативной. Общие характеристики CASE-средств. В результате анализа функциональных возможностей вышеперечисленных продуктов можно сделать вывод о том, что несмотря на некоторую специ- фику и различные сферы применения, все они характеризуются рядом одних и тех же функций, к которым относятся [4]: • создание логических моделей, не зависящих от СУБД, и ге- нерации физических моделей на их основе; • поддержка нескольких типов СУБД, включая не только серверные, но и настольные; • поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных); • реализация обратного проектирования на основе либо имеющейся базы данных, либо имеющегося DDL-скрипта; • генерация отчетов и проектной документации на основе созданной модели; • сохранение модели в репозитарии, который во многих слу- чаях может быть разделяемым; • поддержка генерации кода для одного или нескольких средств разработки или языков программирования.
206 Глава 3. Разработка программно-информационного ядра АИС... 3.9. Язык структурных запросов SQL Стандарт и реализация языка SQL. Увеличение объемов ин- формации, необходимость хранения огромных массивов данных и их обработки привели к тому, что возникла потребность в соз- дании стандартного языка БД, который мог бы использоваться в многочисленных компьютерных системах различных видов (на персональном компьютере, сетевой рабочей станции, универ- сальной ЭВМ и т. д.). Таким языком, согласно известным сведе- ниям [1, 21, 22], стал язык SQL (Structured Query Language). В настоящее время он получил очень широкое распространение и фактически превратился в стандартный язык реляционных БД. В 1986 г. Американский национальный институт стандартов (ANSI) выпустил стандарт на язык SQL, а в 1987 г. Международ- ная организация стандартов (ISO) приняла его в качестве между- народного; сейчас это SQL/92. Однако использование любых стандартов наряду с очевид- ными преимуществами, порождает определенные недостатки. Прежде всего, стандарты направляют в определенное русло раз- витие соответствующей индустрии; в случае языка SQL наличие твердых основополагающих принципов приводит, в конечном счете, к совместимости его различных реализаций и способству- ет как повышению переносимости программного обеспечения и БД в целом, так и универсальности работы администраторов БД. С другой стороны, стандарты ограничивают гибкость и функ- циональные возможности конкретной реализации. Под реализа- цией языка SQL понимается программный продукт SQL соответ- ствующего производителя. Для расширения функциональных возможностей добавляют к стандартному языку SQL различные расширения. Следует отметить, что стандарты требуют от любой законченной реализации языка SQL наличия определенных ха- рактеристик и в общих чертах отражают основные тенденции, которые не только приводят к совместимости между всеми кон- курирующими реализациями, но и способствуют повышению значимости программистов SQL и пользователей реляционных БД на современном рынке программного обеспечения. Все конкретные реализации языка несколько отличаются друг от друга, и в то же время соответствуют современным стандартам ANSI в части переносимости и удобства работы пользователей. Отличия в реализациях заключаются в усовер-
3.9. Язык структурных запросов SQL 207 шенствовании или расширении языка SQL, которые представ- ляют собой дополнительные команды и опции, являющиеся добавлениями к стандартному пакету, доступные в данной кон- кретной реализации. В настоящее время язык SQL поддерживают десятки СУБД различных типов, разработанных для самых разнообразных вы- числительных платформ. Языки манипулирования данными, созданные для СУБД до появления реляционных БД, были ориентированы на операции с данными, представленными в виде логических записей фай- лов. Поэтому пользователь должен был детально знать организа- цию хранения данных и предпринимать серьезные усилия для указания типов и структур данных, их размещения и способа по- лучения. Язык SQL ориентирован на операции с данными, представ- ленными в виде логически взаимосвязанных совокупностей таб- лиц-отношений. Важнейшая особенность его структур — ориен- тация на конечный результат обработки данных, а не на проце- дуру этой обработки. Язык SQL сам определяет, где находятся данные, индексы и даже то, какие наиболее эффективные по- следовательности операций следует использовать для получения результата, а потому указывать эти детали в запросе к БД не требуется. Формы языка SQL. Структурированный язык запросов SQL реализуется в следующих формах: • интерактивной; • статической; • динамической; • встроенной. Интерактивный SQL позволяет конечному пользователю в интерактивном режиме выполнять SQL-операторы. Все СУБД предоставляют инструментальные средства для работы с БД в интерактивном режиме. Например, СУБД Oracle включает ути- литу SQL*Plus, позволяющую в строчном режиме выполнять большинство SQL-операторов. Статический SQL может реализовываться как встроенный SQL или модульный SQL. Операторы статического SQL опреде- лены уже в момент компиляции программы. Динамический SQL позволяет формировать операторы SQL во время выполнения программы.
208 Глава 3. Разработка программно-информационного ядра АИС... Встроенный SQL позволяет включать операторы SQL в код программы на другом языке программирования (например, C++). Типы данных SQL. Данные, хранящиеся в столбцах таблиц SQL-ориентированной БД, являются типизированными, т. е. представляют собой значения одного из типов данных, предо- пределенных в языке SQL или определяемых пользователями путем применения соответствующих средств языка. Для этого при определении таблицы каждому ее столбцу назначается неко- торый тип данных (или домен), и в дальнейшем СУБД должна следить, чтобы в каждом столбце каждой строки каждой табли- цы присутствовали только допустимые значения. В этом разделе мы обсудим систему типов языка SQL. Все допустимые в SQL типы данных, которые можно ис- пользовать при определении столбцов, разбиваются на следую- щие категории [22]: • точные числовые типы; • приближенные числовые типы; • типы символьных строк; • типы битовых строк; • типы даты и времени; • типы временных интервалов; • булевский тип; • типы коллекций; • анонимные строчные типы; • типы, определяемые пользователем; • ссылочные типы. В столбцах таблиц, определенных на любых типах данных, наряду со значениями этих типов, допускается сохранение неоп- ределенного значения, которое обозначается ключевым словом NULL. Подробная информация о типах данных языка содержится в специальной литературе. Понятие домена. Домен — это набор допустимых значений для одного или нескольких атрибутов. Если в таблице БД или в нескольких таблицах присутствуют столбцы, обладающие одни- ми и теми же характеристиками, можно описать тип такого столбца и его поведение через домен, а затем поставить в соот- ветствие каждому из одинаковых столбцов имя домена. Домен определяет все потенциальные значения, которые могут быть присвоены атрибуту [21].
3.9. Язык структурных запросов SQL 209 Стандарт SQL позволяет определить домен с помощью сле- дующего оператора: <определение_домена>::= CREATE DOMAIN имя_домена [AS] типданных [ DEFAULT значение] [ CHECK (допустимые значения)] Каждому создаваемому домену присваивается имя, тип дан- ных, значение по умолчанию и набор допустимых значений. Следует отметить, что приведенный формат оператора является неполным. Теперь при создании таблицы можно указать вместо типа данных имя домена. Удаление доменов из БД выполняется с помощью оператора: DROP DOMAIN имя домена | RESTRICT | CASCADE] Альтернативой доменам в среде SQL Server являются пользо- вательские типы данных. Подробная информация о доменах содержится в специаль- ной литературе. Группы операторов SQL. Язык SQL определяет: • операторы языка, называемые иногда командами языка SQL; • типы данных; • набор встроенных функций. По своему логическому назначению операторы языка SQL часто разбиваются на следующие группы [23]: • язык определения данных DDL (Data Definition Language); • язык манипулирования данными DML (Data Manipulation Language). Язык определения данных включает операторы, управляющие объектами БД. К последним относятся таблицы, индексы, пред- ставления. Для каждой конкретной БД существует свой набор объектов БД, который может значительно расширять набор объ- ектов, предусмотренный стандартом. В некоторых СУБД, таких как Oracle, все объекты БД, принадлежащие одному пользовате- лю, образуют схему БД. С другой стороны, в стандарте SQL92 тер- мином «схема» стали называть группу взаимосвязанных таблиц CREATE SCHEMA — создать схему БД; DROP SHEMA — удалить схему БД; CREATE TABLE — создать таблицу;
210 Глава 3. Разработка программно-информационного ядра АИС... ALTER TABLE — изменить таблицу; DROP TABLE — удалить таблицу; CREATE DOMAIN — создать домен; ALTER DOMAIN — изменить домен; DROP DOMAIN — удалить домен; CREATE COLLATION — создать последовательность; DROP COLLATION — удалить последовательность; CREATE VIEW — создать представление; DROP VIEW — удалить представление. Язык манипулирования данными включает операторы, управ- ляющие содержанием таблиц БД и извлекающие информацию из этих таблиц. К таким операторам относятся: SELECT — извлечение данных из одной или нескольких таблиц; INSERT — добавление строк в таблицу; DELETE — удаление строк из таблицы; UPDATE — изменение значений полей в таблице. Оператор INSERT вставляет в таблицу новую запись: INSERT INTO <имя таблицы>(<поле1>,<поле2>,...) VALUE (<значение1>,<значение2>,...). Число значений должно соответствовать числу указанных полей. Полям, не перечисленным в списке, присваивается зна- чение NULL. Полю SERIAL, если его нет в списке или указано значение 0, присваивается новое уникальное значение. Если значение указано явно, то оно и присваивается. Кроме констант для задания значений можно использовать выражения: строковые, арифметические, дату и др., и функции: USER — имя пользователя, выполняющего данный опе- ратор; TODAY — дата выполнения оператора; CURRENT — момент времени выполнения оператора. Для удаления ненужных записей в таблице используется опе- ратор DELETE: DELETE FROM <имя таблицы> [WHERE <условие>]. Фазы выполнения SQL-оператора приведены в табл. 3.4. Понятие транзакции. Транзакцией называется последователь- ность действий, которая или полностью фиксируется в БД, или полностью отменяется. Иногда под транзакцией также подразу-
3.9. Язык структурных запросов SQL 211 Таблица 3.4. Фазы выполнения SQL-оператора SELECT A,B,C, FROM X, Y WHERE A<500 AND C='ASF' parse Синтаксический разбор оператора Validate Проверка привилегий пользователя, проверка действительности имен системных каталогов, таблиц и названий полей access plan Генерация плана доступа к ресурсам. План доступа — это двоичное представление выполнимого кода по отношению к данным, сохра- няемым в БД Optimize Оптимизация плана доступа. Дпя увеличения скорости поиска дан- ных могут применяться индексы. Оптимизация использования взаи- мосвязанных таблиц Execute Выполнение оператора мевают не группу SQL-операторов, а интервал времени, выпол- няемые в течение которого SQL-операторы можно или все за- фиксировать или все отменить [24]. Так, операция перевода денег с одного счета на другой долж- на составлять единую транзакцию. Иначе может возникнуть си- туация, когда первый SQL-оператор переведет деньги на другой счет, а второй, выполняющий снятие их со счета, не доведет дело до конца из-за непредвиденного сбоя. Фиксация транзакции может производиться принудительно по SQL-оператору или неявно после завершения каждого SQL-опе- ратора. Во втором случае применяется режим автокоммита. Как правило, выполнение SQL-операторов в интерактивном режиме всегда использует автокоммит. Очень часто в интегрированных средах разработки классы, инкапсулирующие работу с базой дан- ных, по умолчанию предполагают режим автокоммита [24]. Новая транзакция начинается с начала каждого сеанса рабо- ты с базой данных. Далее все выполняемые SQL-операторы бу- дут входить в одну транзакцию до тех пор, пока не будет выпол- нен оператор COMMIT WORK или ROLLBACK WORK. Оператор COMMIT WORK завершает текущую транзакцию, выполняя фиксацию сделанных изменений в базе данных. Иногда говорят, что оператор COMMIT WORK фиксирует транзакцию. Оператор ROLLBACK WORK выполняет откат транзакции, отменяя действие всех SQL-операторов, выполненных в текущей транзакции. Логически транзакция должна объединять только выполне- ние взаимосвязанных операций. Так, если делать транзакции
212 Глава 3. Разработка программно-информационного ядра АИС... «очень большими», состоящими из последовательности не свя- занных между собой операторов, то любой сбой, автоматически выполняющий откат транзакции, повлияет на отмену действий, которые могли бы быть успешно завершены при более «корот- ких» транзакциях [24]. 3.10. Создание объектов баз данных Логическая структура БД [21] определяет структуру таблиц, взаимоотношения между ними, список пользователей, хранимые процедуры, правила, умолчания и другие объекты БД. Логически данные в SQL организованы в виде объектов; в табл. 3.5 представлены основные объекты. Рассмотрим теперь каждый объект подробнее. Таблица — основной объект для хранения информации в ре- ляционной БД. Она состоит из содержащих данные строк и столбцов, занимает в БД физическое пространство и может быть постоянной или временной [1, 21]. Поле, также называемое в реляционной БД столбцом, явля- ется частью таблицы, за которой закреплен определенный тип данных. Каждая таблица БД должна содержать хотя бы один столбец. Строка данных — это запись в таблице БД, она включа- ет поля, содержащие данные из одной записи таблицы. Прежде чем создавать таблицу, разработчик должен задаться следующи- ми вопросами: • Как будет называться таблица? • Как будут называться столбцы (поля) таблицы? • Какие типы данных будут закреплены за каждым столбцом? • Какой размер памяти необходимо выделить для хранения каждого столбца? • Какие столбцы таблицы требуют обязательного ввода? • Из каких столбцов будет состоять первичный ключ? Базовый синтаксис оператора создания таблицы (упрощен- ная версия) имеет следующий вид: <определение_таблицы> ::= CREATE TABLE имя таблицы (имя_столбца тип данных [NULL | NOT NULL ] [,...n])
3.10. Создание объектов баз данных 213 Таблица 3.5. Основные объекты базы данных SQL Термин Расшифровка термина Tables Таблицы базы данных, в которых хранятся собственно данные Views Представления (виртуальные таблицы) для отображения дан- ных из таблиц Stored Procedures Хранимые процедуры Triggers Триггеры — специальные хранимые процедуры, вызываемые при изменении данных в таблице User Defined function Создаваемые пользователем функции Indexes Индексы — дополнительные структуры, призванные повы- сить производительность работы с данными User Defined Data Types Определяемые пользователем типы данных Keys Ключи — один из видов ограничений целостности данных Constraints Ограничение целостности — объекты для обеспечения логи- ческой целостности данных Users Пользователи, обладающие доступом к базе данных Roles Роли, позволяющие объединять пользователей в группы Rules Правила базы данных, позволяющие контролировать логиче- скую целостность данных Defaults Умолчания или стандартные установки базы данных Приведенный стандарт совпадает с реализацией оператора создания таблицы в среде MS SQL Server. Главное в команде создания таблицы — определение имени таблицы и описание набора имен полей, которые указываются в соответствующем порядке. Кроме того, этой командой оговари- ваются типы данных и размеры полей таблицы. Ключевое слово NULL используется для указания того, что в данном столбце могут содержаться значения NULL. Значение NULL отличается от пробела или нуля — к нему прибегают, ко- гда необходимо указать, что данные недоступны, опущены или недопустимы. Если указано ключевое слово NOT NULL, то бу- дут отклонены любые попытки поместить значение NULL в данный столбец. Если указан параметр NULL, помещение зна-
214 Глава 3. Разработка программно-информационного ядра АИС... чений NULL в столбец разрешено. По умолчанию стандарт SQL предполагает наличие ключевого слова NULL. Представления, или просмотры (VIEW) представляют собой временные производные (иначе — виртуальные) таблицы и яв- ляются объектами БД, информация в которых не хранится по- стоянно, а формируется динамически при обращении к ним. Обычные таблицы — это базовые таблицы, т. е. такие, которые содержат данные и постоянно находятся на устройстве хранения информации. Представление не существует само по себе, а опре- деляется только в терминах одной или нескольких таблиц. При- менение представлений позволяет разработчику БД обеспечить каждому пользователю или группе пользователей наиболее под- ходящие способы работы с данными, в целях удобства и безо- пасности. Содержимое представлений выбирается из других таб- лиц с помощью запроса, причем изменение значений в таблицах данных приводит к изменению В представлении. Представле- ние — фактически тот же запрос, который выполняется всякий раз с какой-либо командой. Результат выполнения запроса в лю- бой момент времени становится содержанием представления. У пользователя создается впечатление, что он работает с настоя- щей, реально существующей таблицей. В СУБД есть две возможности реализации представлений. В простейшем случае система формирует каждую запись пред- ставления по мере необходимости, постепенно считывая исход- ные данные из базовых таблиц. В более сложных случаях СУБД сначала выполняет операцию, как материализации представле- ния, т. е. сохраняет информацию, из которой состоит представ- ление, во временной таблице, а затем приступает к выполнению пользовательской команды и формированию ее результатов. По- сле этого временная таблица удаляется. Фактически, представление — это предопределенный запрос, хранящийся в БД, который выглядит подобно обычной таблице и не требует для хранения дисковой памяти (используется толь- ко оперативная память). Создания и изменения представлений в стандарте языка и реализации в MS SQL Server совпадают и представлены следующей командой: { CREATE] ALTER} VIEW имя_просмотра [(имя_столбца [,...п])] [WITH ENCRYPTION] AS SELECT_onepaTop [WITH CHECK OPTION]
3.10. Создание объектов баз данных 215 Обращение к представлению осуществляется с помощью оператора SELECT как к обычной таблице. Представление используют так же, как и любую другую таб- лицу: представление можно запрашивать, модифицировать (если оно отвечает определенным требованиям), соединять с другими таблицами. Содержание представления не фиксировано и об- новляется каждый раз, по ссылке в команде. Представления зна- чительно расширяют возможности управления данными. В част- ности, это прекрасный способ разрешить доступ к информации в таблице, скрыв часть данных. Преимущества и недостатки представлений. Механизм пред- ставления — мощное средство СУБД, позволяющее скрыть ре- альную структуру БД от некоторых пользователей за счет опреде- ления представлений. Любая реализация представления должна точно соответствовать состоянию данных, которые определяют это представление. Обычно вычисление представления произво- дится каждый раз при его использовании. Уже в процессе созда- ния представления информация о нем записывается в каталог БД под собственным именем. Любые изменения в данных адекватно отобразятся в представлении — что отличает его от очень похо- жего на него запроса к БД. В то же время запрос представляет со- бой как бы «мгновенную фотографию» данных и при изменении последних запрос к БД необходимо повторить. Наличие пред- ставлений в БД необходимо для обеспечения логической незави- симости данных, т. е. изменение логической структуры данных не приводит к изменению пользовательских программ. Очевид- но, что с увеличением количества данных, хранимых в БД, воз- никает необходимость ее расширения за счет добавления новых атрибутов или отношений (рост БД). При реструктуризации дан- ных информация сохраняется, но изменяется ее расположение, например за счет перегруппировки атрибутов в отношениях. В случае применения СУБД на отдельном персональном компь- ютере использование представлений обычно имеет целью лишь упрощение структуры запросов к БД. В случае многопользова- тельской сетевой СУБД представления играют ключевую роль в определении структуры БД и организации защиты информации. Рассмотрим основные преимущества применения представлений в подобной среде. Независимость от данных. С помощью представлений можно создать согласованную, неизменную картину структуры БД, ко- торая будет оставаться стабильной даже в случае изменения фор-
216 Глава 3. Разработка программно-информационного ядра АИС... мата исходных таблиц (например, добавления или удаления столбцов, изменения связей, разделения таблиц, их реструктури- зации или переименования). Если в таблицу добавляются или из нее удаляются не используемые в представлении столбцы, то из- менять определение этого представления не потребуется. Если структура исходной таблицы переупорядочивается или таблица разделяется, можно создать представление, позволяющее рабо- тать с виртуальной таблицей прежнего формата. Актуальность. Изменения данных в любой из таблиц базы данных, указанных в определяющем запросе, немедленно ото- бражаются на содержимом представления. Повышение защищенности данных. Права доступа к данным могут быть предоставлены исключительно через ограниченный набор представлений, содержащих только то подмножество дан- ных, которое необходимо пользователю. Подобный подход по- зволяет существенно ужесточить контроль за доступом отдель- ных категорий пользователей к информации в базе данных. Снижение стоимости. Представления позволяют упростить структуру запросов за счет объединения данных из нескольких таблиц в единственную виртуальную таблицу. В результате мно- готабличные запросы сводятся к простым запросам к одному представлению. Дополнительные удобства. Создание представлений может обеспечивать пользователей дополнительными удобствами, на- пример возможностью работы только с действительно нужной частью данных. В результате можно добиться максимального упрощения той модели данных, которая понадобится каждому конечному пользователю. Возможность настройки. Представления являются удобным средством настройки индивидуального образа базы данных. В ре- зультате одни и те же таблицы могут быть предъявлены пользова- телям в совершенно разном виде. Обеспечение целостности данных. Если оператор CREATE VIEW дополнить фразой WITH CHECK OPTION, то СУБД ста- нет осуществлять контроль за тем, чтобы в исходных табли- цах БД не появилась ни одна строка, не удовлетворяющая пред- ложению WHERE в определяющем запросе. Этот механизм га- рантирует целостность данных в представлении, что является одним из значимых преимуществ специализированных представ- лений в среде SQL.
3.10. Создание объектов баз данных 217 Несмотря на довольно внушительный перечень преиму- ществ, представления не лишены недостатков. Отметим лишь основные. Ограниченные возможности обновления. В некоторых случаях представления не позволяют вносить изменения в содержащиеся в них данные. Структурные ограничения. Структура представления устанав- ливается в момент его создания. Если определяющий запрос представлен в форме SELECT * FROM_, то символ * ссылается на все столбцы, существующие в исходной таблице на момент создания представления. Если впоследствии в исходную таблицу базы данных добавятся новые столбцы, то они не появятся в данном представлении до тех пор, пока это представление не бу- дет удалено и вновь создано. Снижение производительности. Использование представле- ний связано с определенным снижением производительности. В одних случаях влияние этого фактора совершенно незначи- тельно, тогда как в других оно может послужить источником су- щественных проблем. Например, представление, определенное с помощью сложного многотабличного запроса, может потребо- вать значительных затрат времени на обработку, поскольку при его разрешении потребуется выполнять соединение таблиц вся- кий раз, когда понадобится доступ к данному представлению. Выполнение разрешения представлений связано с использова- нием дополнительных вычислительных ресурсов. Хранимые процедуры представляют собой группы связанных между собой операторов SQL, предусмотренных для облегчения работы программиста. Хранимые процедуры — это набор ко- манд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в БД в откомпилированном виде. Вы- полнение в БД хранимых процедур вместо отдельных операторов SQL дает пользователю следующие преимущества [21]: • необходимые операторы уже содержатся в БД; • все они прошли этап синтаксического анализа и находятся в исполняемом формате; перед выполнением хранимой процедуры SQL-сервер генерирует для нее план исполне- ния, выполняет ее оптимизацию и компиляцию; • хранимые процедуры поддерживают модульное программи- рование, так как позволяют разбивать большие задачи на самостоятельные, более мелкие и удобные в управлении части;
218 Глава 3. Разработка программно-информационного ядра АИС... • хранимые процедуры могут вызывать другие хранимые процедуры и функции; < • хранимые процедуры могут быть вызваны из прикладных программ других типов; • как правило, хранимые процедуры выполняются быстрее, чем последовательность отдельных операторов; • хранимые процедуры проще использовать: они могут со- стоять из десятков и сотен команд, но для их запуска до- статочно указать всего лишь имя нужной хранимой проце- дуры. Это позволяет уменьшить размер запроса, посылае- мого от клиента на сервер, а значит, и нагрузку на сеть. Хранение процедур в том же месте, где они исполняются, уменьшает объем передаваемых по сети данных и повышает об- щую производительность системы. Применение хранимых про- цедур упрощает сопровождение программных комплексов и вне- сение изменений в них. Обычно все ограничения целостности в виде правил и алгоритмов обработки данных реализуются на сервере БД и доступны конечному приложению в виде набора хранимых процедур, которые и представляют интерфейс обра- ботки данных. Для обеспечения целостности данных, а также в целях безопасности приложение обычно не получает прямого доступа к данным — вся работа с ними ведется путем вызова тех или иных хранимых процедур. Подобный подход значительно упрощает модификацию ал- горитмов обработки данных и обеспечивает возможность расши- рения системы без внесения изменений в само приложение: до- статочно только изменить хранимую процедуру на сервере БД. Разработчику не нужно перекомпилировать приложение, созда- вать его копии, а также инструктировать пользователей о необ- ходимости работы с новой версией. Пользователи вообще могут не подозревать о том, что в систему внесены изменения. Хранимые процедуры существуют независимо от таблиц или каких-либо других объектов БД. Они вызываются клиентской программой, другой хранимой процедурой или триггером. Раз- работчик может управлять правами доступа к хранимой проце- дуре, разрешая или запрещая ее выполнение. Изменять код хра- нимой процедуры вправе только ее владелец; при необходимо- сти можно передать права владения ею от одного пользователя к другому. При работе с SQL [21] пользователи могут создавать собст- венные процедуры, реализующие те или иные действия. Храни-
3.10. Создание объектов баз данных 219 мне процедуры являются полноценными объектами БД, а пото- му каждая из них хранится в конкретной БД. Непосредственный вызов хранимой процедуры возможен, только если он осуществ- ляется в контексте той БД, где находится процедура. В SQL предусмотрено несколько типов хранимых процедур. Системные хранимые процедуры предназначены для выполне- ния различных административных действий (практически все, что касается администрирования сервера). Проще говоря, сис- темные хранимые процедуры являются интерфейсом, обеспечи- вающим работу с системными таблицами, которая в конечном счете сводится к изменению, добавлению, удалению и выборке данных из системных таблиц как пользовательских, так и сис- темных БД. Системные хранимые процедуры имеют префикс sp_, хранятся в системной БД и могут быть вызваны в контексте любой другой БД. Пользовательские хранимые процедуры реализуют те или иные действия. Хранимые процедуры — полноценный объект БД. Вследствие этого каждая хранимая процедура располагается в конкретной БД, где и выполняется. Временные хранимые процедуры существуют лишь некоторое время, после этого автоматически уничтожаются сервером. Они делятся на локальные и глобальные. Локальные временные храни- мые процедуры могут быть вызваны только из того соединения, в котором созданы. При создании такой процедуры ей необходи- мо дать имя, начинающееся с символа #. Как и все временные объекты, хранимые процедуры этого типа автоматически удаля- ются при отключении пользователя, перезапуске или остановке сервера. Глобальные временные хранимые процедуры доступны для любых соединений сервера, на котором имеется такая же проце- дура. Для ее определения достаточно дать ей имя, начинающееся с символов ##. Удаляются эти процедуры при перезапуске или остановке сервера, а также при закрытии соединения, в контек- сте которого они были созданы. Создание хранимой процедуры предполагает решение сле- дующих задач [21]: • определение типа создаваемой хранимой процедуры — вре- менная или пользовательская. Кроме этого, можно создать свою собственную системную хранимую процедуру, назна- чив ей имя с префиксом sp_ и поместив ее в системную БД. Такая процедура будет доступна в контексте любой БД локального сервера;
220 Глава 3. Разработка программно-информационного ядра АИС... • планирование прав доступа. При создании хранимой про- цедуры следует учитывать, что она будет иметь те же права доступа к объектам БД, что и создавший се пользователь; • определение параметров хранимой процедуры. Подобно процедурам, входящим в состав большинства языков про- граммирования, хранимые процедуры могут обладать вход- ными и выходными параметрами; • разработку кода хранимой процедуры. Код процедуры мо- жет содержать последовательность любых команд SQL, включая вызов других хранимых процедур. Триггеры являются одной из разновидностей хранимых про- цедур; они исполняются при выполнении для таблицы како- го-либо оператора языка манипулирования данными (DML). Триггеры используются для проверки целостности данных, а также для отката транзакций. Другими словами, триггер — это откомпилированная SQL-процедура, исполнение которой обу- словлено наступлением определенных событий внутри реляци- онной БД. Применение триггеров весьма удобно для пользовате- лей БД, но связано зачастую с дополнительными затратами ре- сурсов на операции ввода/вывода. В том случае, когда тех же результатов (с гораздо меньшими непроизводительными затрата- ми ресурсов) можно добиться с помощью хранимых процедур или прикладных программ, применение триггеров нецелесооб- разно. Триггеры — особый инструмент SQL, используемый для поддержания целостности данных в БД. С помощью ограниче- ний целостности, правил и значений по умолчанию не всегда можно добиться нужного уровня функциональности — часто требуется реализовать сложные алгоритмы проверки данных, га- рантирующие их достоверность и реальность. Кроме того, ино- гда необходимо отслеживать изменения значений таблицы, что- бы нужным образом изменить связанные данные. Триггеры можно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с пра- вилами, стандартными значениями и т. д. Триггер представляет собой специальный тип хранимых про- цедур, запускаемых сервером автоматически при попытке изме- нения данных в таблицах, с которыми связаны триггеры. Каж- дый триггер привязывается к конкретной таблице. Все произво- димые им модификации данных рассматриваются как одна транзакция. В случае обнаружения ошибки или нарушения це-
3.10. Создание объектов баз данных 221 лостности данных происходит откат этой транзакции, тем самым внесение изменений запрещается. Отменяются также вес изме- нения, уже сделанные триггером. Создает триггер только владелец БД. Это ограничение позво- ляет избежать случайного изменения структуры таблиц, спосо- бов связи с ними других объектов и т. п. Триггер представляет собой весьма полезное и в то же время опасное средство. Так, при неправильной логике работы легко уничтожить целую БД, поэтому триггеры необходимо очень тща- тельно отлаживать. В отличие от обычной подпрограммы, триггер выполняется неявно в каждом случае возникновения триггерного события, к тому же он не имеет аргументов. Приведение его в действие иногда называют запуском триггера. С помощью триггеров вы- полняются следующие функции: • проверка корректности введенных данных и выполнение сложных ограничений целостности данных, которые труд- но, если вообще возможно, поддерживать с помощью огра- ничений целостности, установленных для таблицы; • выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом; • накопление аудиторской информации посредством фикса- ции сведений о внесенных изменениях и тех лицах, кото- рые их выполнили; • поддержка репликации. Функции пользователя. При реализации на языке SQL слож- ных алгоритмов, которые могут потребоваться более одного раза, встает вопрос о сохранении разработанного кода для даль- нейшего применения. Эта задача просто решается с помощью хранимых процедур, однако их архитектура не позволяет ис- пользовать процедуры непосредственно в выражениях, так как они требуют промежуточного присвоения возвращенного значе- ния переменной, которая затем и указывается в выражении [21]. Возможность создания пользовательских функций предо- ставлена в среде MS SQL Server 2000. В других реализациях SQL в распоряжении пользователя имеются только встроенные функ- ции, которые обеспечивают выполнение наиболее распростра- ненных алгоритмов: поиск максимального или минимального значения и др.
222 Глава 3. Разработка программно-информационного ядра АИС... Функции пользователя представляют собой самостоятельные объекты БД, такие, например, как хранимые процедуры или триггеры. Функция пользователя располагается в определен- ной БД и доступна только в ее контексте. В SQL Server имеются следующие классы функций пользо- вателя: • Scalar — функции возвращают обычное скалярное значение, каждая может включать множество команд, объединяемых в один блок с помощью конструкции BEGIN...END; • Inline — функции содержат всего одну команду SELECT и возвращают пользователю набор данных в виде значения типа данных TABLE; • Multi-statement — функции также возвращают пользователю значение типа данных TABLE, содержащее набор данных, однако в теле функции находится множество команд SQL (INSERT, UPDATE и т. д.). Именно с их помощью и фор- мируется набор данных, который должен быть возвращен после выполнения функции. Пользовательские функции сходны с хранимыми процедура- ми, но, в отличие от них, могут применяться в запросах так же, как и системные встроенные функции. Пользовательские функ- ции, возвращающие таблицы, являются альтернативой представ- лениям. Последние ограничены одним выражением SELECT, а пользовательские функции способны включать дополнительные выражения, что позволяет создавать более сложные и мощные конструкции. Встроенные функции SQL, условно разбивают на следующие группы: • математические функции; • строковые функции; • функции для работы с датой и временем; • функции конфигурирования; • функции системы безопасности; • функции управления метаданными; • статистические функции. Подробная информация об особенностях каждой группы функций с примерами и заданиями для самопроверки содержит- ся в специальной литературе. Индексы представляют собой структуру, позволяющую вы- полнять ускоренный доступ к строкам таблицы на основе значе- ний одного или более ее столбцов. Наличие индекса существен-
3.10. Создание объектов баз данных 223 но повышает скорость выполнения некоторых запросов и сокра- щает время поиска необходимых данных за счет физического или логического их упорядочивания. Индекс — это набор ссы- лок, упорядоченных по определенному столбцу таблицы, кото- рый в данном случае называется индексированным столбцом. Хотя индекс и связан с конкретным столбцом (или столбцами) таблицы, все же он является самостоятельным объектом БД. Физически индекс — всего лишь упорядоченный набор зна- чений из индексированного столбца с указателями на места фи- зического размещения исходных строк в структуре БД. Когда пользователь выполняет обращающийся к индексированному столбцу запрос, СУБД автоматически анализирует индекс для поиска требуемых значений. Однако, поскольку индексы должны обновляться системой при каждом внесении изменений в их базовую таблицу, они соз- дают дополнительную нагрузку на систему. Индексы обычно создаются с целью удовлетворения опреде- ленных критериев поиска после того, как таблица уже находи- лась некоторое время в работе и увеличилась в размерах. Созда- ние индексов не предусмотрено стандартом SQL, однако боль- шинство диалектов поддерживают как минимум следующий оператор: CREATE [ UNIQUE ] INDEX имя_индекса ON имя_таблицы(имя_столбца[А8С|ОЕ5С][,...п]) Указанные в операторе столбцы составляют ключ индекса. Индексы могут создаваться только для базовых таблиц, но не для представлений. Если в операторе указано ключевое слово UNIQUE, уникальность значений ключа индекса будет автома- тически поддерживаться системой. Требование уникальности значений обязательно для первичных ключей, а также возможно и для других столбцов таблицы (например, для альтернативных ключей). Хотя создание индекса допускается в любой момент, при его построении для уже заполненной данными таблицы мо- гут возникнуть проблемы, связанные с дублированием данных в различных строках. Следовательно, уникальные индексы (по крайней мере, для первичного ключа) имеет смысл создавать не- посредственно при формировании таблицы. В результате систе- ма сразу возьмет на себя контроль за уникальностью значений данных в соответствующих столбцах.
224 Глава 3. Разработка программно-информационного ядра АИС... Если созданный индекс впоследствии окажется ненужным, его можно удалить с помощью оператора: DROP INDEX имя индскса В среде MS SQL Server индексы расположены в самой таблице и являются удобным внутренним механизмом системы SQL-сер- вера, с помощью которого осуществляется доступ к данным наи- более оптимальным способом. В среде SQL Server реализованы эффективные алгоритмы поиска нужного значения в строго опре- деленной последовательности данных. Ускорение поиска дости- гается именно за счет того, что данные представляются упорядо- ченными (хотя физически, в зависимости от типа индекса, они могут храниться в соответствии с очередностью их добавления в таблицу). К настоящему времени разработаны эффективные ма- тематические алгоритмы поиска данных в упорядоченной после- довательности. Наиболее эффективной структурой для поиска данных в машинном представлении являются В-деревья — мно- гоуровневая иерархическая структура с переменным количеством элементов в каждом узле. Создание индекса. Если выборка данных из таблицы требует значительного времени, это означает, что для нее необходимо создать индекс. Индексы существенно повышают производи- тельность выполнения операций поиска и выборки данных. При выборе столбца для индекса следует проанализировать, какие типы запросов чаще всего выполняются пользователями и какие столбцы являются ключевыми, т. е. задающими критерии выбор- ки данных (например, порядок сортировки). В среде SQL Server реализовано несколько типов индексов: • некластерные ; • кластерные; • уникальные. Некластерные индексы. В отличие от кластерных, не пере- страивают физическую структуру таблицы, а лишь организуют ссылки на соответствующие строки. Для идентификации нужной строки в таблице некластерный индекс организует специальные указатели, включающие: • информацию об идентификационном номере файла, в ко- тором хранится строка; • идентификационный номер страницы соответствующих данных;
3.10. Создание объектов баз данных 225 • номер искомой строки на соответствующей странице; • содержимое столбца. В большинстве случаев следует ограничиваться 4—5 индек- сами. Кластерный индекс. Принципиальным отличием кластерного индекса от индексов других типов является то, что при его опре- делении в таблице физическое расположение данных перестраи- вается в соответствии со структурой индекса. Логическая струк- тура таблицы в этом случае представляет собой, скорее, словарь, чем индекс. Данные в словаре физически упорядочены (напри- мер, по алфавиту). Кластерные индексы приводят к существенному увеличению производительности поиска данных даже по сравнению с обыч- ными индексами (это особенно заметно при работе с последова- тельными данными). Если в таблице определен некластерный индекс, то сервер сначала должен обратиться к индексу, а затем найти нужную строку в таблице. При использовании кластерных индексов следующая запись данных располагается сразу после найденных ранее данных. В результате отпадают лишние опера- ции, связанные с обращением к индексу и новым поиском нуж- ной строки в таблице. Естественно, в таблице определяют только один кластерный индекс. В качестве такового следует выбирать наиболее часто используемые столбцы. При этом необходимо выполнять общие рекомендации создания индексов и не индексировать слишком длинные столбцы. Кластерный индекс может включать несколько столбцов, од- нако количество таких столбцов рекомендуется по возможности свести к минимуму. Необходимо избегать создания кластерного индекса для час- то изменяемых столбцов, поскольку серверу придется физиче- ски перемещать все данные в таблице с целью их упорядочения. Для часто изменяемых столбцов больше подходит некластерный индекс. При создании в таблице первичного ключа (PRIMARY KEY) сервер автоматически создает для него кластерный индекс, если его не существовало ранее или если при определении ключа не был явно указан другой тип индекса. В случае, когда в таблице определен и некластерный индекс, его указатель ссылается не на физическое положение строки в БД, а на соответствующий элемент кластерного индекса, описы-
226 Глава 3. Разработка программно-информационного ядра АИС... вающего эту строку, что позволяет не перестраивать структуру некластерных индексов всякий раз, когда кластерный индекс меняет физический порядок строк в таблице. Уникальный индекс гарантирует уникальность значений в ин- дексируемом столбце. При наличии уникальных индексов сервер не разрешит вставить новое или изменить существующее значе- ние так, чтобы в результате этой операции в столбце появились два одинаковых значения. Уникальный индекс является своеобразной надстройкой и реализуется как для кластерного, так и для некластерного индек- са. В одной таблице может существовать один уникальный кла- стерный и множество уникальных некластерных индексов. Уни- кальные индексы следует определять только тогда, когда это действительно необходимо. Для обеспечения целостности дан- ных в столбце можно определить ограничение целостности UNIQUE или PRIMARY KEY, а не прибегать к уникальным ин- дексам. Их использование только для обеспечения целостности данных является неоправданной тратой пространства в БД. Кро- ме того, на их поддержание тратится и процессорное время. Средства языка SQL предлагают несколько способов опреде- ления индекса: • автоматическое создание индекса при создании первичного ключа; • автоматическое создание индекса при определении ограни- чения целостности unique; • создание индекса с помощью команды CREATE INDEX. Удаление индекса выполняется командой DROP INDEX ’имя_индекса'[, -п] Пользовательские типы данных — это типы данных, которые создает пользователь на основе системных типов данных, когда в нескольких таблицах необходимо хранить однотипные значения; причем столбцы в таблице должны иметь одинаковый размер, тип данных и чувствительность к значениям NULL. Создание пользовательского типа данных осуществляется выполнением системной процедуры: sp_addtype [@typename=]type,[@phystype=] syste mdatatype [ ,|@nuiltype== I’nulltype']
3.10. Создание объектов баз данных 227 Тип данных system data type выбирается из табл. 3.6. Таблица 3.6. Типы данных Виды данных image smalldatetime decimal bit text real ’decimal[(p[,s])]’ 'binary(n)' uniqueidentifier datetime numeric 'char(n)' smallint float 'numeric[(p[,s])]' 'nvarchar(n)' int 'float(n)' 'varbinary(n)’, ntext 'varchar(n)' 'nchar(n)' Ограничения целостности — механизм обеспечения автомати- ческого контроля соответствия данных установленным условиям (или ограничениям). Ограничения целостности имеют приори- тет над триггерами, правилами и значениями по умолчанию. К ограничениям целостности относятся: ограничение на значе- ние NULL, проверочные ограничения, ограничение уникально- сти (уникальный ключ), ограничение первичного ключа и огра- ничение внешнего ключа. Последние три ограничения тесно связаны с понятием ключей. Обязательные данные. Для некоторых столбцов требуется на- личие в каждой строке таблицы конкретного и допустимого зна- чения, отличного от опущенного значения или значения NULL. Для заданий ограничений подобного типа стандарт SQL преду- сматривает использование спецификации NOT NULL. Требования конкретного предприятия. Обновления данных в таблицах могут быть ограничены существующими в организации требованиями (бизнес-правилами). Стандарт SQL позволяет реа- лизовать бизнес-правила предприятий с помощью предложения CHECK и ключевого слова UNIQUE. Ограничения для доменов полей. Каждый столбец имеет собст- венный домен — некоторый набор допустимых значений. Стан- дарт SQL предусматривает два различных механизма определе- ния доменов. Первый состоит в использовании предложения CHECK, позволяющего задать требуемые ограничения для столбца или таблицы в целом, а второй предполагает примене- ние оператора CREATE DOMAIN.
228 Глава 3. Разработка программно-информационного ядра АИС... Целостность сущностей. Первичный ключ таблицы должен иметь уникальное непустое значение в каждой строке. Стандарт SQL позволяет задавать подобные требования поддержки целостно- сти данных с помощью фразы PRIMARY KEY. В пределах таблицы сс можно указывать только один раз. Тем не менее для любых аль- тернативных ключей таблицы существует возможность гарантиро- вать уникальность значений, что с успехом обеспечивает ключевое слово UNIQUE. Кроме того, при определении альтернативных ключей рекомендуется использовать спецификаторы NOT NULL. Ссылочная целостность. Внешние ключи представляют собой столбцы (или наборы столбцов), предназначенные для связыва- ния каждой из строк дочерней таблицы, содержащей этот внеш- ний ключ, со строкой родительской таблицы, содержащей соот- ветствующее значение потенциального ключа. Стандарт SQL предусматривает механизм определения внешних ключей с по- мощью предложения FOREIGN KEY, а ссылка REFERENCES определяет имя родительской таблицы, (там находится соответ- ствующий потенциальный ключ). При использовании этого предложения система отклонит выполнение любых операторов INSERT или UPDATE, с помощью которых будет предпринята попытка создать в дочерней таблице значение внешнего ключа, нс соответствующее одному из уже существующих значений по- тенциального ключа родительской таблицы. Когда действия сис- темы выполняются при поступлении операторов UPDATE и DELETE, содержащих попытку обновить или удалить значение потенциального ключа в родительской таблице, которому соот- ветствует одна или более строк дочерней таблицы, то они зави- сят от правил поддержки ссылочной целостности, указанных во фразах ON UPDATE и ON DELETE предложения FOREIGN KEY. При попытке удалить из родительской таблицы строку, на которую ссылается одна или более строк дочерней таблицы, язык SQL предоставляет следующие возможности: • CASCADE — выполняется удаление строки из родитель- ской таблицы и автоматическое удаление всех ссылающих- ся на нее строк дочерней таблицы; • SET NULL — выполняется удаление строки из родитель- ской таблицы, а во внешние ключи всех ссылающихся на нее строк дочерней таблицы записывается значение NULL; • SET DEFAULT — выполняется удаление строки из роди- тельской таблицы, а во внешние ключи всех ссылающихся
3.10. Создание объектов баз данных 229 на нее строк дочерней таблицы заносится значение, при- нимаемое по умолчанию; • NO ACTION — операция удаления строки из родительской таблицы отменяется. Именно это значение используется по умолчанию в тех случаях, когда в описании внешнего клю- ча фраза ON DELETE опушена. Те же самые правила применяются в языке SQL и тогда, ко- гда значение потенциального ключа родительской таблицы об- новляется. Определитель MATCH позволяет уточнить способ обработки значения NULL во внешнем ключе. При определении таблицы предложение FOREIGN KEY можно применять произвольное количество раз. В операторе CREATE TABLE используется необязательная фраза DEFAULT, которая предназначена для задания принимае- мого по умолчанию значения, когда в операторе INSERT значе- ние в данном столбце будет отсутствовать. Фраза CONSTRAINT позволяет задать имя ограничению, что позволит впоследствии отменить то или иное ограничение с помощью оператора ALTER TABLE. Умолчание — самостоятельный объект БД, представляющий значение, которое будет присвоено элементу таблицы при встав- ке строки, если в команде вставки явно не указано значение для этого столбца. Умолчания создаются и удаляются в любой момент времени, до или после введения данных в таблицу. Значения по умолча- нию создаются командой create default (создать умолчание), а удаляются с командой drop default (удалить умолчание). Умолчание может быть связано с определенным столбцом таблицы, с несколькими столбцами или со всеми столбцами таб- лиц БД, имеющими заданный пользователем тип данных. Для связывания умолчания со столбцом или типом данных использу- ется системная процедура sp_bindefault (присоединить умолча- ние); в противном случае — процедура sp_unbindefault (отсоеди- нить умолчание). Создание правил. Правила создаются с помощью команды create rule (создать правило), а затем присоединяются к столбцу или пользовательскому типу данных с помощью системной про- цедуры sp_binderule (присоединить правило). Отсоединение пра- вила от столбца или пользовательских типа данных проводится с помощью системной процедуры sp unbindrule (отсоединить пра-
230 Глава 3. Разработка программно-информационного ядра АИС... вило) или путем присоединения нового правила к столбцу или пользовательскому типу [25]. Названия правил должны соответствовать правилам, уста- новленным для идентификаторов. Правила можно создавать только в текущей базе данных. Названия правил должны быть уникальными для каждого пользователя внутри одной базы данных. Например, один поль- зователь не может создать два правила с названием socsecrule. Однако два различных пользователя могут создать правила с на- званием socsecrule, поскольку имена пользователей позволяют их различить. Правила, связанные со столбцами, всегда сильнее правил, связанных с типами данных. Присоединение правила к столбцу заменяет правило, которое связано с типом данных этого столб- ца, но присоединение правила к типу данных не заменяет пра- вила, связанного со столбцом этого типа. Правило, связанное с типом данных, начинает действовать только при попытке обновить или вставить значения в столбец данных этого типа. Поскольку правила не проверяют значения переменных, то пользователь должен стараться не присваивать переменной пользовательского типа значения, которое не допус- кается правилом для этого типа данных. Контрольные вопросы 1. Изложите основы современных СУБД. 2. Перечислите виды архитектурных решений баз данных. 3. Каковы критерии выбора СУБД при создании АИС? 4. Назовите концептуальные модели данных. 5. Какие понятия реляционных баз данных относятся к базовым? 6. Что такое нормализация? 7. Что значит диаграммное представление баз данных? 8. Перечислите известные виды нотаций. 9. Какие средства относятся к средствам автоматизированного проекти- рования структур баз данных? 10. Каковы основные действия для создания таблиц? 11. Что означают представления? 12. Что означают умолчания? 13. Что представляют собой внешние ключи? 14. Что такое кластерный и некластерный индексы? 15. Перечислите основные функции для работы с датой и временем.
3.10. Создание объектов баз данных 231 Литература 1. Диго С. М. Базы данных: проектирование и использование. М.: Фи- нансы и статистика. 2005. 592 с. 2. Карпова И. П. Введение в базы данных. Ч. 1. М.: МЭСИ, 2003. 3. Головина О. С. Программирование в корпоративных СУБД. Москов- ский международный институт эконометрики, информатики, финансов и права. М., 2002. 125 с. 4. Кузнецов С. Д. Основы современных баз данных, информацион- но-аналитические материалы ЦИТ. http//www.citmgu.ru. 5. Каратыгин С. И. Базы данных: простейшие средства обработки ин- формации: системы управления базами данных. ABF, 1995. 6. Аносо А. Критерии выбора СУБД при создании информационных систем, http://www.nwsta.com. 7. Емельянов А. А., Власов Е. А. Информационное моделирование в экономических системах: учеб, пособие. М.: МЭСИ, 1996. 8. Сычев Ю. Н. Информационная безопасность: учеб, пособие / Мос- ковский государственный университет экономики, статистики и информати- ки. М., 2004. 240 с. 9. Мельников В. И. Защита информации в компьютерных системах. М.: Финансы и статистика, 1997. 10. Павловский Ю. Н. Имитационные модели и системы. М.: Фазис, 2000. 11. Малыхина М. П. Базы данных: основы, проектирование, использо- вание. СПб.: БХВ-Петербург, 2004. 512 с. 12. Кузнецов С. Д. Введение в модель данных SQL. htpp://intuit.ru. 13. Смирнова Г. Н., Тельнов Ю. Ф. Проектирование экономических информационных систем. М.: Финансы и статистика, 2004. 14. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем, http:// citforum.ru. 15. Верников Г. Основы методологии IDEF1. http://www.itrealty.ru. 16. Верников Г. Основы методологии IDEF1X. http://www.itrealty.ru. 17. http://www.embarcadero.com/products/Design/erdatasheet.htm. 18. http://www.popkin.com/products/sa2001 /data/data.htm. 19. http://www.visible.com/dataapp/daprods.html. 20. http://www.microsoft.com/office/visio/. 21. Полякова Л. H. Основы SQL. http://www.intuit.ru. 22. Кузнецов С. Д. Введение в модель данных SQL. http://www.intuit.ru. 23. Карпова И. П. Введение в базы данных. Ч. 1. М.: МЭСИ, 2003. 24. Баженова И. Ю. SQL и процедурно-ориентированные языки, http:// www.intuit.ru. 25. http://palien.narod.ru.
Глава 4 ДОСТУП К БАЗАМ ДАННЫХ 4.1. Стандартные системы доступа к базам данных Существует несколько способов доступа к данным из средств разработки и клиентских приложений [I, 2, 3]. Подавляющее большинство систем управления БД содержит в своем составе библиотеки, предоставляющие специальный прикладной про- граммный интерфейс (Application Programming Interface — API) для доступа к данным этой СУБД. Обычно такой интерфейс пред- ставляет собой набор функций, вызываемых из клиентского при- ложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов БД, а в случае серверных СУБД иниции- руют передачу запросов серверу БД и получение от сервера ре- зультатов выполнения запросов или кодов ошибок, интерпрети- руемых клиентским приложением. Библиотеки, содержащие API для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения. В последнее время Windows-версии клиентского программ- ного обеспечения наиболее популярных серверных СУБД, в ча- стности Microsoft SQL Server, Oracle, Informix, содержат также COM-серверы, предоставляющие объекты для доступа к данным и метаданным. Использование клиентского API (или клиентских СОМ-объ- ектов) является наиболее очевидным (и нередко самым эффек- тивным с точки зрения производительности) способом манипу- ляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, и замена ее на другую (например, с целью рас- ширения хранилища данных или перехода в архитектуру «кли- ент — сервер») повлечет за собой переписывание значительной
4.1. Стандартные системы доступа к базам данных 233 части кода клиентского приложения — клиентские API и объ- ектные модели не подчиняются никаким стандартам и различны для разных СУБД. Другой способ манипуляции данными в приложении базиру- ется на применении универсальных механизмов доступа к данным. Указанный механизм обычно реализован в виде библиотек и до- полнительных модулей, называемых драйверами или провайдера- ми. Библиотеки содержат некий стандартный набор функций или классов, укомплектованный согласно той или иной специ- фикации. Дополнительные модули, специфичные для различных СУБД, реализуют непосредственное обращение к функциям клиентского API конкретных СУБД. Отметим, что достоинством универсальных механизмов яв- ляется возможность применения одного и того же абстрактного API, а во многих случаях — COM-серверов, компонентов, клас- сов для доступа к разным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать при необходимости замены СУБД. При- чем модификация, как правило, затрагивает не код приложения как таковой, а настройки доступа к данным, содержащиеся в реестре или внешних файлах. Недостатками универсальности яв- ляются невозможность доступа к уникальной функциональности конкретной СУБД, снижение производительности приложений, а также усложнение процедуры поставки приложения — ведь в его состав нужно включать библиотеки, ответственные за реали- зацию универсальных механизмов, драйверы для конкретных СУБД, а также обеспечивать настройки, необходимые для их правильного функционирования. Ниже приведены наиболее популярные среди универсальных механизмов доступа к данным: • Borland Database Engine (BDE); • Open Database Connectivity (ODBC); . OLE DB; • ActiveX Data Objects (ADO). Универсальные механизмы ODBC, OLE DB и ADO фирмы Microsoft представляют собой по существу промышленные стан- дарты. BDE фирмы Borland так и не стал промышленным стан- дартом, однако до недавнего времени применялся довольно ши- роко, так как до выхода Delphi 5 был практически единственным универсальным механизмом доступа к данным, поддерживаемым средствами разработки Borland на уровне компонентов и классов.
234 Глава 4. Доступ к базам данных Графическая интерпретация механизмов доступа к данным из приложений приведена на рис. 4.1. Рис. 4.1. Возможные механизмы доступа к данным из приложений В общем случае приложение, использующее БД, может при- менять следующие механизмы доступа: • непосредственный вызов функций клиентского API (или обращение к СОМ-объектам клиентских библиотек); • вызов функций ODBC API (или применение классов, ин- капсулирующих подобные вызовы); • непосредственное обращение к интерфейсам OLE DB; • применение ADO (или применение классов, инкапсули- рующих обращение к объектам ADO); • применение ADO + OLE DB + ODBC; • применение BDE + SQL Links (или применение классов, инкапсулирующих обращение к функциям BDE); • применение BDE + ODBC Link + ODBC. Кроме вышеуказанных, существуют и другие способы досту- па к данным, использующие перечисленные универсальные ме- ханизмы или непосредственно клиентские API. 4.1.1. Технология BDE Borland Database Engine (BDE) — универсальный механизм доступа к данным, применяемый в средствах разработки фирмы Borland (а именно — Delphi и C++ Builder), а также в некоторых
4.1. Стандартные системы доступа к базам данных 235 других продуктах, например Corel Paradox, Corel Quattro Pro, Seagate Software Crystal Reports. BDE создан на основе библиотеки Paradox Engine, предна- значенной для Borland Pascal и Borland C++. Приложения, разра- ботанные с помощью последних, обеспечивали доступ к табли- цам СУБД Paradox. После создания Paradox Engine компания Borland разработала несколько библиотек-драйверов под общим названием SQL Links. Эти библиотеки расширили функциональ- ность BDE, позволив применять имевшийся в Paradox Engine на- бор функций для доступа к данным dBase, ODBC-источников, а также наиболее популярных серверных СУБД. Позже к этому на- бору были добавлены библиотеки для доступа к Access и FoxPro. Механизм BDE широко использовался при создании прило- жений с помощью Borland Pascal 7.0 и Borland C++ 4.5 и 5. За- тем средства разработки Borland были преобразованы в средства быстрой разработки приложений (Rapid Application Develop- ment — RAD), и большинство вызовов BDE API оказалось ин- капсулировано в компонентах доступа к данным библиотеки Visual Components Library (VCL). BDE был фактически единст- венным механизмом доступа к данным в Delphi и C++ Builder, поддерживаемым на уровне компонентов, классов, а также визу- альных компонентов для редактирования данных, вплоть до по- явления 5-й версии обоих продуктов. Физически BDE представляет собой набор библиотек досту- па к данным, реализующих BDE API — набор функций для ма- нипуляции данными, вызываемых из приложения. Эти функ- ции, в свою очередь, могут обращаться к функциям клиентско- го API (в случае, например, Oracle, Informix, IB Database) или ODBC API (Access 2000, Microsoft SQL Server 7.0, любые ODBC-источники), а также непосредственно манипулировать файлами некоторых СУБД (dBase, Paradox). Для доступа к БД с помощью BDE на компьютере с клиент- ским приложением следует установить библиотеки BDE общего назначения, а также BDE-драйвер для данной СУБД. В случае серверных СУБД такие драйверы носят название SQL Links. Эти драйверы содержат BDE API — стандартный набор функций, созданных на основе функций клиентских API соответствующих СУБД. Среди BDE-драйверов есть драйвер, созданный с использова- нием ODBC API, — так называемый ODBC Link, который при- меняется вместе с ODBC-драйвером для выбранной СУБД.
236 Глава 4. Доступ к базам данных В отличие от ODBC-драйверов и OLE DB-провайдеров, вы- пускаемых как производителями СУБД, так и многими сторон- ними производителями, BDE-драйверы производятся только са- мой компанией Inprise. Число СУБД, для которых имеются BDE-драйверы, ограничено пятью наиболее популярными сер- верными СУБД, несколькими форматами данных настольных СУБД (в основном ранних версий СУБД) и сервером IB Database, входящим в комплект поставки средств разработки Borland. Для доступа к данным остальных СУБД с помощью BDE можно использовать только ODBC-драйвер и ODBC Link. Рассмотрим теперь конкретные СУБД, доступные с помо- щью BDE-драйверов, причем настольных СУБД. Paradox, dBase, текстовые файлы. Для доступа к данным Paradox, dBase и текстовым файлам существуют BDE-драйверы прямого доступа, осуществляющие считывание и запись файлов этих СУБД. Более того, фирма Microsoft прямо указывает, что для записи данных в файлы этих СУБД с помощью ODBC или OLE DB (в частности, из приложений Visual Basic или VBA, при использовании этих файлов в качестве присоединенных баз дан- ных Access или Microsoft SQL Server) на компьютере, где исполь- зуется подобное приложение, следует установить BDE соответст- вующей версии, так как только эти драйверы осуществляют за- пись в такие файлы. Таким образом, применяя указанные форматы данных в приложениях, созданных с помощью таких средств разработки, не только для чтения, но и для записи, не- обходимо установить BDE на компьютеры как было сказано выше. В табл. 4.1 приведены сведения о том, какие версии BDE требуются для доступа к данным Paradox и dBase различных вер- сий с помощью ODBC или OLE DB. Из вышеизложенного следует, что не имеет особого смысла использовать ODBC-драйверы этих СУБД и ODBC Link, по крайней мере, в средствах разработки, поддерживающих BDE (Delphi, C++ Builder), и в созданных с их помощью приложени- ях. Несмотря на то, что такой доступ к данным технически впол- не осуществим, реально в приложении все равно используется BDE-драйвер прямого доступа. В этом случае между приложени- ем и драйвером оказываются две «лишние» библиотеки, не до- бавляющие никакой дополнительной функциональности, а лишь создающие неудобства при поставке приложения и настройке доступа к данным, к тому же нередко еще и снижающие произ- водительность приложения.
4.1. Стандартные системы доступа к базам данных 237 Таблица 4.1. Версии BDE Доступ к данным Paradox или поздних версий dBase непо- средственно с помощью BDE в Visual Basic, Visual C++ и иных средств разработки, не ориентированных на поддержку BDE на уровне визуальных компонентов и классов, возможен только на уровне вызовов BDE APL Microsoft Access. BDE-драйвер прямого доступа в настоящее время доступен для Access 95 и Access 97. Оба эти драйвера рабо- тают только в том случае, когда на компьютере, где эксплуатиру- ется использующее их приложение, установлена соответствую- щая версия библиотек Microsoft Jet Engine (она входит в ком- плект поставки Microsoft Access и Microsoft Visual FoxPro). Эти драйверы не способны работать с данными Access 2000. Для доступа с помощью BDE к Access 2000 используют соот- ветствующий ODBC-драйвер и ODBC Link, при этом на компью- тере, где эксплуатируется использующее их приложение, требует- ся наличие Microsoft Jet Engine 4.0. Продукт входит в состав Microsoft Access 2000, а также в состав Microsoft Data Access Components (MDAC) (доступны на Web-сайте корпорации Microsoft). Следует отметить, что не все типы данных, используе- мые этой версией Access, поддерживаются BDE, поэтому ка- кие-то из таблиц или их столбцов могут оказаться недоступными.
238 Глава 4. Доступ к базам данных Однако, использование BDE — не самый эффективный спо- соб доступа к данным Access. Применение его целесообразно для старых версий средств разработки Borland (Delphi 1.0—4.0, C++ Builder 1.0—4.0), ориентированных на применение BDE как единственного механизма доступа к данным на уровне компо- нентов и классов. В случае применения других средств разработ- ки, а также последних версий Delphi и C++ Builder гораздо эф- фективнее осуществлять доступ к данным Access с помощью ADO и OLE DB, так как эти механизмы предоставляют по срав- нению с BDE гораздо больше функциональных возможностей. Microsoft FoxPro и Visual FoxPro. Доступ к данным FoxPro осуществим в первую очередь с помощью BDE-драйвера прямо- го доступа, позволяющего производить запись в файлы этой СУБД. Возможен также доступ через ODBC Link и соответст- вующий ODBC-драйвер. Доступ к данным Visual FoxPro осуще- ствим только с помощью ODBC Link и соответствующего ODBC-драйвера, поскольку BDE-драйвер для БД Visual FoxPro (*.vfp) в настоящее время отсутствует. Microsoft SQL Server и MSDE. BDE-драйвер прямого досту- па существует сегодня для Microsoft SQL Server версий 4.x и 6.x. Он не всегда работает с Microsoft SQL Server 7.0 и MSDE, так как некоторые особенности Microsoft SQL Server 7.0, отсутство- вавшие в прежних версиях этой СУБД, например ряд типов дан- ных, не поддерживаются BDE. Следует подчеркнуть, что, как и в случае с Access, несмотря на существование теоретической возможности доступа к данным этой СУБД с помощью ODBC Link и соответствующего ODBC- драйвера, практически это осуществимо не всегда по той же са- мой причине. Доступ к данным этой СУБД необходимо осуще- ствлять с помощью ADO/OLE DB (либо с помощью объектной модели клиентской части этой СУБД). Oracle, Sybase, IBM DB2, Informix, InterBase. Для всех пере- численных СУБД существуют BDE-драйверы прямого доступа (SQL L