Назад

Купить и читать книгу за 230 руб.

Вы читаете ознакомительный отрывок. Если книга вам понравилась, вы можете купить полную версию и продолжить читать

Информационные системы

   Основное внимание в книге уделяется вопросам разработки клиентской части информационных систем с использованием приложений Delphi. В то же время в ней содержится большое количество практического материала, посвященного вопросам проектирования и создания баз данных, в частности рассматривается методология проектирования информационных систем, приводится подробное описание стандарта ANSI SQL-92, излагаются теоретические сведения о реляционной модели данных. Одна из частей книги полностью посвящена современным технологиям программирования – COM, ActiveX и Интернет-технологиям.
   Допущено Министерством образования Российской Федерациив качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки дипломированных специалистов «Информатика и вычислительная техника».


Юрий Сергеевич Избачков, Владимир Николаевич Петров Информационные системы: Учебник для вузов

Введение

   Программное обеспечение за полвека своего существования претерпело огромные изменения, пройдя путь от программ, способных выполнять только простейшие логические и арифметические операции, до сложных систем управления предприятиями. В программном обеспечении всегда можно было выделить два основных направления развития:
   • выполнение вычислений;
   • накопление и обработка информации.
   Хотя первоначально компьютеры предназначались главным образом для выполнения сложных математических расчетов (в первую очередь для расчетов, связанных с созданием ядерного оружия и ракетной техники), в настоящее время доминирующим является второе направление. Такое перераспределение основных функций, выполняемых вычислительной техникой, вполне понятно – гражданские области применения компьютеров гораздо более распространены, чем военные и научные, а снижение стоимости компьютеров сделало их доступными для совсем небольших предприятий и даже частных лиц.
   Сегодня управление предприятием без компьютера просто немыслимо. Компьютеры давно и прочно вошли в такие области управления, как бухгалтерский учет, управление складом, ассортиментом и закупками. Однако современный бизнес требует гораздо более широкого применения информационных технологий в управлении предприятием. Жизнеспособность и развитие информационных технологий объясняется тем, что современный бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первым. Для принятия любого грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности, будь то торговля, производство или предоставление каких-либо услуг. Поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьезнее должны быть подобные вложения. Они являются жизненной необходимостью – в жесткой конкурентной борьбе одержать победу сможет лишь тот, кто лучше оснащен и наиболее эффективно организован.

Информационные системы

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

База данных

   Система управления базой данных (СУБД) является неотъемлемой частью любой информационной системы. Тип используемой СУБД обычно определяется масштабом информационной системы – малые информационные системы могут использовать локальные СУБД, в корпоративных же информационных системах потребуется мощная клиент-серверная СУБД, поддерживающая многопользовательскую работу.
   В настоящее время наиболее широко распространены реляционные СУБД. Несмотря на очевидную привлекательность и растущую популярность объектно-ориентированных СУБД (ObjectStore, Objectivity, O2, Jasmin), пока все же преобладают реляционные базы данных, которые хорошо отлажены, развиты и к тому же поддерживают стандарт SQL-92 (к таким системам относятся, например, Oracle, Informix, Sybase, DB2, MS SQL Server).
   Традиционным методом организации информационных систем является двухзвенная архитектура клиент-сервер. В этом случае вся прикладная часть информационной системы размещается на рабочих станциях, а на стороне сервера осуществляется только доступ к базе данных. Чтобы разгрузить клиентскую рабочую станцию и снизить загрузку сети, применяются трехзвенные архитектуры клиент-сервер. В этой архитектуре помимо клиентской части системы и сервера базы данных вводится промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации поддерживается в сервере приложений.
   При разработке базы данных необходимо учитывать специфику той СУБД, для которой эта разработка проводится. Несмотря на существование стандарта ANSI SQL 92, практически все SQL-серверы используют свои реализации SQL, содержащие расширения стандарта. Тем не менее, на начальном этапе при разработке общей структуры базы данных (на уровне концептуальной модели) особенности используемой СУБД можно не учитывать.

CASE-средства

   Первым шагом в проектировании информационной системы является формальное описание предметной области, построение полных и непротиворечивых функциональных и информационных моделей информационной системы. Это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Следует также учитывать, что в процессе создания и функционирования информационной системы потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем. Модели информационных систем должны быть описаны средствами, понятными большинству участников проекта, как правило, с использованием универсального языка моделирования (UML).
   Указанные сложности способствовали появлению программно-технологических средств специального класса, так называемых CASE-средств, призванных повысить эффективность разработки программного обеспечения. Аббревиатура CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное ее значение, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. В настоящее время под CASE-средствами понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

Средства разработки

   Еще один класс задач, решаемых при проектировании информационных систем, относится к созданию удобного и соответствующего целям информационной системы пользовательского интерфейса. Следует понимать, что задача эргономичности интерфейса не формализуется, но в то же время она является очень существенной. Пользователи часто судят о качестве системы в целом, исходя из качества ее интерфейса. Более того, от качества интерфейса зависит эффективность системы.
   Разработка интерфейса всегда являлась трудоемкой задачей, отнимающей много времени у разработчиков. Однако в последние годы появились так называемые средства визуальной разработки приложений, в значительной мере упростившие задачу разработки графического интерфейса пользователя. Сейчас на рынке программных продуктов предлагается довольно много разнообразных средств визуальной разработки приложений, ориентированных на создание информационных систем. Все их можно условно разделить на два класса.
   • Специализированные средства ориентированы исключительно на создание приложений для вполне определенной СУБД и не предназначены для разработки обычных приложений, не использующих базы данных. Примером средств такого рода может служить система Power Builder фирмы Sybase.
   • Универсальные средства могут использоваться как для разработки информационных приложений, взаимодействующих с базами данных, так и для разработки любых других приложений, не использующих базы данных. Из таких средств наибольшей известностью пользуются системы Delphi фирмы Borland и Visual Basic фирмы Microsoft.
   Каждый из указанных классов имеет свои достоинства и недостатки, поэтому в общем случае трудно отдать предпочтение одному из них.
   В предлагаемой книге в качестве средства разработки выбран продукт Borland Delphi, пользующийся большой популярность в нашей стране. Delphi базируется на объектно-ориентированном языке Object Pascal, который наилучшим образом подходит для учебных целей вследствие своей строгости и простоты. Кроме того, в Object Pascal в полной мере реализованы все основные концепции объектно-ориентированного программирования.
   Объектно-ориентированное программирование позволяет сделать любую систему более гибкой и динамичной, исключив необходимость постоянной переделки структуры базы данных и приложений.
   Главное достоинство объектно-ориентированного проектирования заключается в возможности многократно использовать ранее написанный код. Кроме того, объектные системы несут в себе возможность модификации и развития. Применительно к базам данных это позволяет начать проектирование будущей системы, не имея исчерпывающего представления о предметной области. Получение детальной информации о предметной области – процесс весьма трудоемкий, а объектно-ориентированный подход позволяет сократить сроки и уменьшить стоимость разработки системы.
   С выходом платформы Microsoft.NET достоинства и недостатки языков программирования стали сглаживаться, появилась возможность межъязыковой интеграции. Создавать программное обеспечение для .NET можно с помощью восьмой версии Delphi.

Для кого предназначена эта книга

   Книга в первую очередь предназначена для начинающих программистов, не имеющих большого опыта разработки информационных систем. Основное внимание в книге уделяется вопросам разработки клиентской части информационных систем с использованием системы визуальной разработки приложений Borland Delphi. При этом обращается внимание на смещение акцентов в разработке информационных систем в сторону концептуального проектирования.
   В книге содержится большое количество материала, посвященного вопросам разработки баз данных, в частности, рассматриваются основные методологии проектирования информационных систем, приводится подробное описание стандарта SQL-92 ANSI, излагаются теоретические сведения о реляционной модели данных. Таким образом, данную книгу можно рассматривать в качестве учебного пособия по информационным системам начального уровня.

Как составлена книга

   Данная книга содержит двадцать глав, которые сгруппированы в шесть частей.

Часть I. Анализ и проектирование информационных систем

   В этой части книги (главы 1–6) излагаются базовые сведения об информационных системах предприятий и их проектировании. В первых трех главах приводятся основная терминология и базовые понятия, знание которых необходимо для эффективного восприятия материала последующих глав и других литературных источников. Далее рассматриваются вопросы проектирования и разработки одной из важнейших частей информационной системы – реляционной базы данных. В реляционных базах данных информация хранится в виде взаимосвязанных двухмерных таблиц. Разработка структуры базы данных, обеспечивающей эффективный доступ к информации и ее обработку, в значительной степени определяет качество информационной системы в целом. Для упрощения процесса проектирования структуры базы данных и сокращения времени разработки используются специальные программные средства проектирования баз данных, называемые CASE-средствами.
   Каждая из представленных в этой части книги глав касается важных концептуальных понятий.
   • Глава 1. «Информационные системы». В данной главе рассматриваются общие понятия и типы информационных систем, определяются их базовые свойства, а также формулируются задачи, решаемые при разработке таких систем, и проблемы, возникающие при их решении. Кроме того, рассматриваются наиболее типичные области применения информационных систем.
   • Глава 2. «Жизненный цикл информационных систем». Как ясно из названия, здесь рассматриваются понятие жизненного цикла информационной системы и основные процессы, его сопровождающие. Также рассматриваются основные модели жизненного цикла информационных систем.
   • Глава 3. «Методология и технология разработки информационных систем».
   В этой главе приводятся сведения о методологии быстрой разработки приложений (Rapid Application Development, RAD), рассматриваются фазы жизненного цикла информационной системы в рамках методологии RAD. Приводятся сведения об основных международных и российских стандартах и методиках разработки информационных систем, в частности универсальном языке моделирования – стандарте описания информационных систем.
   • Глава 4. «Реляционные базы данных». В этой главе приводятся основные сведения о реляционных базах данных. Рассматриваются важнейшие функции, выполняемые системами управления базами данных, дается краткая история развития этих систем. Обсуждаются основы реляционной модели данных, нормальные формы данных и вопросы нормализации данных.
   • Глава 5. «Управление реляционными базами данных». Здесь приводятся сведения о методах и средствах управления как информацией, хранящейся в базе данных, так и структурой самой базы данных. Рассматриваются средства языка управления базами данных SQL, предусмотренные стандартом SQL 92 института ANSI.
   • Глава 6. «Проектирование структуры базы данных». В данной главе рассматриваются понятия концептуальной и физической моделей данных, а также средства анализа и проектирования баз данных (CASE-средства). Приводится пример разработки базы данных с использованием одного из наиболее популярных CASE-средств Power Designer.

Часть II. Delphi – система быстрой разработки приложений

   Эта часть книги (главы 7-10) содержит базовые сведения об объектно-ориентированном и визуальном программировании – современном подходе к разработке приложений. Несмотря на то, что основные концепции объектно-ориентированного программирования и первые объектно-ориентированные языки появились около 30 лет назад, объектно-ориентированное программирование оказалось востребованным сравнительно недавно – в 90-х годах. Несколько позже стали выходить средства визуальной разработки приложений, позволяющие быстро разрабатывать графический интерфейс пользователя.
   При разработке клиентских приложений информационных систем очень важным аспектом является создание удобного, интуитивно понятного интерфейса пользователя. А поскольку одной из основных функций клиентских приложений является ввод и редактирование данных, то следует обратить особое внимание на различные способы организации доступа к данным для их ввода и модификации. Особенностью здесь является тот факт, что редактируемые данные сохраняются в таблицах баз данных.
   • Глава 7. «Object Pascal и Объектно-ориентированное программирование».
   В этой главе излагаются основные концепции объектно-ориентированного программирования. Рассмотрение проводится на базе языка программирования Object Pascal, являющегося базовым языком системы визуальной разработки приложений Delphi фирмы Borland. В языке Object Pascal в полной мере реализованы все принципы объектно-ориентированного программирования. Строгость и ясность этого языка делают его идеальным для изучения концепций объектно-ориентированного программирования. В то же время этот язык обладает достаточной мощью для разработки сложных приложений, в полной мере использующих все возможности операционной системы Windows.
   • Глава 8. «Средства быстрой разработки приложений». Данная глава содержит начальные сведения о платформе Microsoft.NET и системе проектирования Delphi, а также подробное описание интегрированной среды системы визуальной разработки приложений Delphi фирмы Borland. Данный программный продукт пользуется заслуженной популярностью в России, сочетая в себе простоту и мощь.
   • Глава 9. «Компоненты для ввода и редактирования данных». В этой главе рассматриваются компоненты для ввода и редактирования данных, входящие в стандартную библиотеку Borland Delphi.
   • Глава 10. «Создание форм для ввода и редактирования данных». Данная глава является органическим продолжением предыдущей. Однако если в главе 9 рассматривались отдельные компоненты для ввода и редактирования данных, то здесь обсуждаются различные варианты компоновки компонентов для ввода и редактирования данных на формах, обеспечивающие наиболее эффективный и наглядный доступ к информации, хранящейся в базе данных.

Часть III. Выборка данных и отображение ее результатов

   Помимо редактирования данных, хранящихся в базе данных, важной функцией клиентских приложений является их выборка по какому-либо критерию. Причем только выборкой проблема не исчерпывается – данные, полученные в результате выборки, необходимо представить в удобном для пользователя виде. Рассмотрению этих задач – выборки данных и представления полученных результатов – и посвящена эта часть книги.
   • Глава 11. «Выборка данных». В данной главе рассматриваются средства языка SQL, предназначенные для разного рода выборок данных из таблиц базы данных. Также здесь рассматриваются компоненты библиотеки Borland Delphi, предназначенные для организации взаимодействия с базой данных с помощью операторов языка SQL.
   • Глава 12. «Создание отчетов». В этой главе рассматриваются вопросы создания отчетов – форматированного представления данных, выводимого на экран, принтер или в файл. В поставку Borland Delphi входят специальные компоненты, предназначенные для создания отчетов. Подробному их рассмотрению и посвящена данная глава.

Часть IV. Компоновка приложения и управление проектом

   В предыдущих частях книги, посвященных разработке приложений, затрагивались лишь вопросы создания отдельных фрагментов программ, выполняющих различные функции. В данной части книги рассматривается ряд вопросов, позволяющих придать приложению законченный вид. Кроме того, здесь обсуждаются вопросы организации коллективной разработки приложений, что может быть актуальным при выполнении сложных проектов.
   • Глава 13. «Система меню и панель инструментов приложения». В этой главе рассматриваются вопросы создания основных элементов интерфейса пользователя приложения – меню и панели инструментов.
   • Глава 14. «Управление проектом и создание приложения». Здесь рассматривается структура проекта в Borland Delphi, основные свойства проекта, способы компиляции и управления приложением.
   • Глава 15. «Коллективная разработка приложений». Эта глава посвящена вопросам коллективной разработки приложений. Рассматриваются основные проблемы и принципы организации коллективной разработки приложений, а также средство контроля версий TeamSource, входящее в поставку Borland Delphi.
   • Глава 16. «Справочная система приложения». В данной главе излагаются вопросы создания справочной системы приложения и ее взаимодействия с приложением, а также вопросы создания контекстной справочной системы. Здесь вы познакомитесь с методами создания файлов справки как в формате WinHelp, так и в формате HTML Help.

Часть V. Технология COM

   Технология COM и основанная на ней технология ActiveX, являвшаяся основной технологией взаимодействия приложений до появления платформы .NET, широко применяются и будут применяться в приложениях, функционирующих под управлением операционной системы Windows. Данные технологии позволяют легко обеспечить взаимодействие между различными приложениями, дает возможность многократного использования кода при разработке собственных приложений, упрощает модификацию приложений. Разработчики платформы .NET отказались от многих решений, применяемых в технологии COM, однако ввиду широкого распространения последней мы приводим ее основы.
   • Глава 17. «Доступ к данным из приложений Microsoft Office». Из этой главы вы узнаете, как организовать взаимодействие программы, разработанной с помощью Borland Delphi, с различными приложениями, входящими в состав Microsoft Office.
   • Глава 18. «Создание СОМ-объектов и элементов ActiveX». В этой главе рассматриваются вопросы создания собственных COM-объектов и элементов и ActiveX.

Часть VI. Программирование для Интернета

   Глобальная сеть Интернет уже настолько прочно вошла в нашу жизнь, что публикация информации в WWW стала нормой, а не исключением. Поэтому организация взаимодействия информационной системы с веб-сервером является сейчас актуальной.
   • Глава 19. «Особенности Интернет-приложений». В этой главе рассматриваются базовые технические особенности организации Интернета, а также основные понятия и термины веб-программирования. Излагаются основы протокола HTTP и языка разметки гипертекста (HTML).
   • Глава 20. «Разработка Интернет-приложений». Здесь излагаются вопросы разработки веб-приложений в среде Borland Delphi. Особое внимание уделяется возможностям организации взаимодействия веб-сервера с системами управления базами данных.

От издательства

   Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
   Мы будем рады узнать ваше мнение!
   Подробную информацию о наших книгах вы найдете на веб-сайте издательства: http://www.piter.com.

Часть I
Анализ и проектирование информационных систем

Глава 1
Информационные системы

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

Основные понятия

   Под информационной системой обычно понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации. Подавляющее большинство информационных систем работает в режиме диалога с пользователем.
   В наиболее общем случае типовые программные компоненты, входящие в состав информационной системы, реализуют:
   • диалоговый ввод-вывод;
   • логику диалога;
   • прикладную логику обработки данных;
   • логику управления данными;
   • операции манипулирования файлами и (или) базами данных.
   Корпоративной информационной системой (КИС) мы будем называть совокупность специализированного программного обеспечения и вычислительной аппаратной платформы, на которой установлено и настроено программное обеспечение.

Факторы, влияющие на развитие корпоративных информационных систем

   В последнее время все больше руководителей начинают отчетливо осознавать важность построения на предприятии корпоративной информационной системы как необходимого инструментария для успешного управления бизнесом в современных условиях.
   Можно выделить три наиболее важных фактора, существенно влияющих на развитие корпоративных информационных систем:
   • развитие методик управления предприятием;
   • развитие общих возможностей и производительности компьютерных систем;
   • развитие подходов к технической и программной реализации элементов информационной системы.
   Рассмотрим эти факторы более подробно.
Развитие методик управления предприятием
   Теория управления предприятием представляет собой довольно обширный предмет для изучения и совершенствования. Это обусловлено постоянным изменением и разнообразием ситуаций на мировом рынке. Все время растущий уровень конкуренции вынуждает руководителей компаний искать новые методы сохранения своего присутствия на рынке и поддержания рентабельности своей деятельности. Такими методами могут быть диверсификация, децентрализация, управление качеством и многое другое. Современная информационная система должна отвечать всем нововведениям в теории и практике менеджмента. Несомненно, это самый главный фактор, так как построение совершенной в техническом отношении системы, которая не отвечает требованиям по функциональности, не имеет смысла.
Развитие общих возможностей и производительности компьютерных систем
   Прогресс в области наращивания мощности и производительности компьютерных систем, развитие сетевых технологий и систем передачи данных, широкие возможности интеграции компьютерной техники с самым разнообразным оборудованием позволяют постоянно наращивать производительность информационных систем и их функциональность.
Развитие подходов к технической и программной реализации элементов информационных систем
   Параллельно с развитием аппаратной части информационных систем на протяжении последних лет происходит постоянный поиск новых, более удобных и универсальных, методов программно-технологической реализации информационных систем. Можно выделить три наиболее существенных новшества, оказавших колоссальное влияние на развитие информационных систем в последние годы.
   • Новый подход к программированию. С начала 90-х годов объектно-ориентированное программирование фактически вытеснило модульное; до настоящего времени непрерывно совершенствуются методы построения объектных моделей. Благодаря внедрению объектно-ориентированных технологий программирования существенно сокращаются сроки разработки сложных информационных систем, упрощаются их поддержка и развитие.
   • Благодаря развитию сетевых технологий локальные информационные системы повсеместно вытесняются клиент-серверными и многоуровневыми реализациями.
   • Развитие Интернета расширило возможности работы с удаленными подразделениями, открыло широкие перспективы электронной коммерции, обслуживания покупателей через Интернет и многое другое. Более того, определенные преимущества дает использование Интернет-технологий во внутренних сетях предприятий (так называемые интранет-технологии).
   Примечание.
   Следует иметь в виду, что использование определенных технологий при построении информационных систем не является самоцелью разработчика. Выбор технологий должен производиться в зависимости от реальных потребностей.

Основные составляющие корпоративных информационных систем

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

Соотношение между составляющими информационной системы

   Взаимосвязи между двумя указанными составляющими информационной системы достаточно сложны. С одной стороны, эти две составляющие в определенном смысле независимы. Например, организация сети и протоколы, используемые для обмена данными между компьютерами, абсолютно не зависят от того, какие методы и программы планируется применять на предприятии для организации бухгалтерского учета.
   С другой стороны, указанные составляющие в определенном смысле все же зависят друг от друга. Функциональные подсистемы в принципе не могут существовать без компьютерной инфраструктуры. В то же время компьютерная инфраструктура сама по себе достаточно ограничена, поскольку не обладает необходимой функциональностью. Невозможно эксплуатировать распределенную информационную систему при отсутствии сетевой инфраструктуры. Хотя, имея развитую инфраструктуру, можно предоставить сотрудникам организации ряд полезных общесистемных служб (например, электронную почту и доступ в Интернет), упрощающих работу и делающих ее более эффективной (в частности, за счет использования более развитых средств связи).
   Таким образом, разработку информационной системы целесообразно начинать с построения компьютерной инфраструктуры (корпоративной сети) как наиболее важной составляющей, опирающейся на апробированные промышленные технологии и гарантированно реализуемой в разумные сроки в силу высокой степени определенности как в постановке задачи, так и в предлагаемых решениях.
   Примечание.
   Бессмысленно строить корпоративную сеть как некую самодостаточную систему, не принимая во внимание прикладную функциональность. Если в процессе создания системно-технической инфраструктуры не проводить анализ и автоматизацию управленческих задач, то средства, инвестированные в разработку корпоративной сети, не дадут впоследствии реальной отдачи.
   Корпоративная сеть создается на многие годы вперед, капитальные затраты на ее разработку и внедрение настолько велики, что практически исключают возможность полной или частичной переделки существующей сети.
   Функциональные подсистемы, в отличие от корпоративной сети, изменчивы по своей природе, так как в предметной области деятельности организации постоянно происходят более или менее существенные изменения. Функциональность информационных систем сильно зависит от организационно-управленческой структуры организации, ее функциональности, распределения функций, принятых в организации финансовых технологий и схем, существующей технологии документооборота и множества других факторов.
   Разрабатывать и внедрять функциональные подсистемы можно постепенно. Например, сначала на наиболее важных и ответственных участках выполнять разработки, обеспечивающие прикладную функциональность системы (внедрять системы финансового учета, управления кадрами и т. п.), а затем распространять прикладные программные системы и на другие, первоначально менее значимые области управления предприятием.

Классификация информационных систем

   Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.
Классификация по масштабу
   По масштабу информационные системы подразделяются на следующие группы (рис. 1.1):
   • одиночные;
   • групповые;
   • корпоративные.
   Рис. 1.1. Деление информационных систем по масштабу.

   Одиночные информационные системы.
   Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных, или локальных, систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.
   Групповые информационные системы.
   Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.
   Корпоративные информационные системы.
   Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server. Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз данных.
Классификация по сфере применения
   По сфере применения информационные системы обычно подразделяются на четыре группы (рис. 1.2):
   • системы обработки транзакций;
   • системы поддержки принятия решений;
   • информационно-справочные системы;
   • офисные информационные системы.
   Рис. 1.2. Деление информационных систем по сфере применения.

   Системы обработки транзакций, в свою очередь, по оперативности обработки данных разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций (OnLine Transaction Processing, OLTP), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями для них являются:
   • высокая производительность обработки транзакций;
   • гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.
   Системы поддержки принятия решений (Decision Support System, DSS) представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических, по другим показателям.
   Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в Интернете.
   Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом.
   Примечание.
   Следует отметить, что приводимая классификация по сфере применения в достаточной степени условна. Крупные информационные системы очень часто обладают признаками всех перечисленных выше классов. Кроме того, корпоративные информационные системы масштаба предприятия обычно состоят из ряда подсистем, относящихся к различным сферам применения.
Классификация по способу организации
   По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы (рис. 1.3):
   • системы на основе архитектуры файл-сервер;
   • системы на основе архитектуры клиент-сервер;
   • системы на основе многоуровневой архитектуры;
   • системы на основе Интернет/интранет-технологий.
   Рис. 1.3. Деление информационных систем по способу организации.

   В любой информационной системе можно выделить необходимые функциональные компоненты (табл. 1.1), которые помогают понять ограничения различных архитектур информационных систем. Рассмотрим более подробно особенности вариантов построения информационных приложений.
Таблица 1.1. Типовые функциональные компоненты информационной системы


   Архитектура файл-сервер.
   В архитектуре файл-сервер сетевое разделение компонентов диалога PS и PL отсутствует, а компьютер используется для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения лишь незначительно увеличивают нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к сети.
   Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.
   Однако такая архитектура имеет существенный недостаток: при выполнении некоторых запросов к базе данных клиенту могут передаваться большие объемы данных, загружая сеть и приводя к непредсказуемости времени реакции. Значительный сетевой трафик особенно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи. Одним из вариантов устранения данного недостатка является удаленное управление файл-серверным приложением в сети. При этом в локальной сети размещается сервер приложений, совмещенный с телекоммуникационным сервером (обычно называемым сервером доступа), в среде которого выполняются обычные файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод поступает от удаленных клиентов через телекоммуникации. Приложения не должны быть слишком сложными, иначе велика вероятность перегрузки сервера, или же нужна очень мощная платформа для сервера приложений.
   Примечание.
   Одним из традиционных средств, на основе которых создаются файл-серверные системы, являются локальные СУБД. Однако такие системы, как правило, не отвечают требованиям обеспечения целостности данных (в частности, они не поддерживают транзакции). Поэтому при их использовании задача обеспечения целостности данных возлагается на программы клиентов, что приводит к усложнению клиентских приложений. Тем не менее, эти инструменты привлекают своей простотой, удобством применения и доступностью. Поэтому файл-серверные информационные системы до сих пор представляют интерес для малых рабочих групп и, более того, нередко используются в качестве информационных систем масштаба предприятия.
   Архитектура клиент-сервер.
   Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является наличие выделенных серверов баз данных, понимающих запросы на языке структурированных запросов (Structured Query Language, SQL) и выполняющих поиск, сортировку и агрегирование информации.
   Отличительная черта серверов БД – наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.
   Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет реализовать графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL) и логика (BL, DL) – на клиенте. В двухуровневом определении архитектуры клиент-сервер используется именно этот вариант: приложение работает на клиенте, СУБД – на сервере (рис. 1.4).
   Рис. 1.4. Классический вариант клиент-серверной системы.

   Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, активно взаимодействующие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там реализована логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.
   Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД.
   Хранимая процедура – процедура с SQL-операторами для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.
   Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективных операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность (нет прямого доступа к данным).
   Примечание.
   Следует помнить, что перегрузка хранимых процедур прикладной логикой может перегрузить сервер, что приведет к потере производительности. Эта проблема особенно актуальна при разработке крупных информационных систем, в которых к серверу может одновременно обращаться большое количество клиентов. Поэтому в большинстве случаев следует принимать компромиссные решения: часть логики приложения размещать на стороне сервера, часть – на стороне клиента. Такие клиент-серверные системы называются системами с разделенной логикой. Данная схема при удачном разделении логики позволяет получить более сбалансированную загрузку клиентов и сервера, но при этом затрудняется сопровождение приложений.
   Создание архитектуры клиент-сервер возможно и на основе многотерминальной системы. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для Unix.
   В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.
   Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать применение многоуровневой архитектуры.
   Многоуровневая архитектура.
   Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:
   • нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;
   • средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL выполняет операции с базой данных DS;
   • верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без использования хранимых процедур).
   Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.
   Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер.
   Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может реализовываться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.
   С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехуровневой архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду Unix, однако прикладные серверы можно строить на базе Microsoft Windows NT с вызовом удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех уровней. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.
   Таким образом, многоуровневая архитектура распределенных приложений позволяет повысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура клиент-сервер.
   Интернет/интранет-технологии.
   В развитии Интернет/интранет-технологий основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологий с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер – сервер приложений – сервер баз данных – сервер динамических страниц – веб-сервер.
   Благодаря интеграции Интернет/интранет-технологий и архитектуры клиент-сервер, процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.

Области применения и примеры реализации информационных систем

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

Бухгалтерский учет

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

Управление финансовыми потоками

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

Управление складом, ассортиментом, закупками

   Далее, можно автоматизировать процесс анализа движения товара, тем самым отследив и зафиксировав те двадцать процентов ассортимента, которые приносят восемьдесят процентов прибыли. Это же позволит ответить на главный вопрос – как получать максимальную прибыль при постоянной нехватке средств?
   «Заморозить» оборотные средства в чрезмерном складском запасе – самый простой способ сделать любое предприятие, производственное или торговое, потенциальным инвалидом. Можно просмотреть перспективный товар, вовремя не вложив в него деньги.

Управление производственным процессом

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

Управление маркетингом

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

Документооборот

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

Оперативное управление предприятием

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

Предоставление информации о фирме

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

Требования, предъявляемые к информационным системам

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

Гибкость

   Гибкость, способность к адаптации и дальнейшему развитию подразумевает возможность приспособления информационной системы к новым условиям, новым потребностям предприятия. Выполнение этих условий возможно, если на этапе разработки информационной системы использовались общепринятые средства и методы документирования, так что по прошествии определенного времени сохранится возможность разобраться в структуре системы и внести в нее соответствующие изменения, даже если все разработчики или их часть по каким-либо причинам не смогут продолжить работу.
   Примечание.
   Следует иметь в виду, что психологически легче разобраться в собственных разработках, пусть даже созданных давно, чем в чужих решениях, не всегда на первый взгляд логичных. Поэтому рекомендуется фазу сопровождения системы доверять лицам, которые ее проектировали.
   Любая информационная система рано или поздно морально устареет, и станет вопрос о ее модернизации или полной замене. Разработчики информационных систем, как правило, не являются специалистами в прикладной области, для которой разрабатывается система. Участие в модернизации или создании новой системы той же группы проектировщиков существенно сократит сроки модернизации.
   Вместе с тем возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна – внимательнее относиться к подбору разработчиков информационных систем.

Надежность

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

Эффективность

   Система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на нее задачи в минимальные сроки.
   В любом случае оценка эффективности будет производиться заказчиком, исходя из вложенных в разработку средств и соответствия представленной информационной системы его ожиданиям.
   Негативной оценки эффективности информационной системы со стороны заказчика можно избежать, если представители заказчика будут привлекаться к проектированию системы на всех его стадиях. Такой подход позволяет многим конечным пользователям уже на этапе проектирования адаптироваться к изменениям условий работы, которые иначе были бы приняты враждебно.
   Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с меньшими затратами и в более короткие сроки система будет создана.
   Кроме того, заказчик, не являясь специалистом в области разработки информационных систем, может не знать о новых информационных технологиях. Контакты с заказчиком во время разработки для него информационной системы могут подтолкнуть заказчика к модернизации его аппаратных средств, применению новых методов ведения бизнеса, что отвечает как потребностям заказчика, так и проектировщика. Заказчик получает рост эффективности своего предприятия, проектировщик – расширение возможностей, применяемых при проектировании информационной системы.
   Эффективность системы обеспечивается оптимизацией данных и методов их обработки, применением оригинальных разработок, идей, методов проектирования (в частности, спиральной модели проектирования информационной системы, о которой речь пойдет в следующих главах).
   Не следует забывать и о том, что работать с системой придется обычным людям, являющимся специалистами в своей предметной области, но зачастую обладающими весьма средними навыками в работе с компьютерами. Интерфейс информационных систем должен быть им интуитивно понятен. В свою очередь разработчик-программист должен понимать характер выполняемых конечным пользователем операций. Рекомендациями в этом случае могут служить повышение эффективности управления разработкой информационных систем, улучшение информированности разработчиков о предметной области.
   Совет.
   Имеет смысл еще до сдачи информационной системы в эксплуатацию предоставить разработчикам возможность попробовать себя в роли конечных пользователей. Встречались случаи, когда такой подход приводил к отказу от использования на рабочем месте оператора манипулятора типа «мышь», что в свою очередь приводило к многократному повышению производительности оператора.

Безопасность

   Под безопасностью, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют доступа к информационным ресурсам организации, кроме тех, которые для них предназначены. Защита информации от постороннего доступа обеспечивается управлением доступом к ресурсам системы, использованием современных программных средств защиты информации. В крупных организациях целесообразно создавать подразделения, основным направлением деятельности которых было бы обеспечение информационной безопасности, в менее крупных организациях назначать сотрудника, ответственного за данный участок работы.
   Система, не отвечающая требованиям безопасности, может причинить ущерб интересам заказчика, прежде всего имущественным.
   Внимание.
   В этой связи следует отметить, что согласно действующему в России законодательству ответственность за вред, причиненный ненадлежащим качеством работ или услуг, несет исполнитель, то есть в нашем случае разработчик информационной системы. Поэтому ненадлежащее обеспечение безопасности информационной системы заказчика в худшем случае обернется для исполнителя судебным преследованием, в лучшем – потерей клиента и утрате деловой репутации.
   Помимо злого умысла при обеспечении безопасности информационных систем приходится сталкиваться еще с несколькими факторами. В частности, современные информационные системы являются достаточно сложными программными продуктами. При их проектировании с высокой вероятностью возможны ошибки, вызванные большим объемом программного кода, несовершенством компиляторов, человеческим фактором, несовместимостью с используемыми программами сторонних разработчиков в случае модификации этих программ, и т. п. Поэтому за фазой разработки информационной системы неизбежно следует фаза ее сопровождения в процессе эксплуатации, в которой происходит выявление скрытых ошибок и их исправление.
   Примечание.
   При проектировании информационной системы курс доллара США в одной из процедур разработчики обозначили константой. На момент ввода в эксплуатацию этой системы курс доллара был стабилен, поэтому ошибка никак себя не проявляла, а была выявлена только через некоторое время в период роста курса.
   Требование безопасности обеспечивается современными средствами разработки информационных систем, современной аппаратурой, методами защиты информации, применением паролей и протоколированием, постоянным мониторингом состояния безопасности операционных систем и средств их защиты.
   И, наконец, самый важный фактор, влияющий на процесс разработки, – знания и опыт коллектива разработчиков информационных систем.

Глава 2
Жизненный цикл информационных систем

   Разработка корпоративной информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, оказывают влияние на структуру информационной системы, но в то же время структуры разных предприятий в целом похожи между собой. Каждая организация, независимо от рода ее деятельности, состоит из ряда подразделений, непосредственно осуществляющих тот или иной вид деятельности компании. И эта ситуация справедлива практически для всех организаций, каким бы видом деятельности они ни занимались.
   Любую организацию можно рассматривать как совокупность взаимодействующих элементов (подразделений), каждый из которых может иметь свою, достаточно сложную, структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В общем случае можно выделить три вида связей между подразделениями предприятия:
   • функциональные связи – каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;
   • информационные связи – подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);
   • внешние связи – некоторые подразделения взаимодействуют с внешними системами, причем их взаимодействие также может быть как информационным, так и функциональным.
   Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем.
   В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:
   • по содержанию действий разработчиков (групп разработчиков) – в данном случае рассматривается статический аспект процесса разработки, описываемый в терминах основных потоков работ (исполнители, действия, последовательность действий и т. п.);
   • по времени, или по стадиям жизненного цикла разрабатываемой системы – в данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов.

Общие сведения об управлении проектами

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

Понятие проекта

   Проект – это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенными целями, достижение которых означает завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов, организационной структуре.
   Примечание.
   Обычно для сложного понятия (каким, в частности, является понятие проекта) трудно дать однозначную формулировку, которая полностью охватывает все признаки вводимого понятия. Поэтому приведенное определение не претендует на единственность и полноту.
   Можно выделить следующие основные отличительные признаки проекта как объекта управления:
   • изменчивость – целенаправленный перевод системы из существующего в некоторое желаемое состояние, описываемое в терминах целей проекта;
   • ограниченность конечной цели;
   • ограниченность продолжительности;
   • ограниченность бюджета;
   • ограниченность требуемых ресурсов;
   • новизна для предприятия, для которого реализуется проект;
   • комплексность – наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;
   • правовое и организационное обеспечение – создание специфической организационной структуры на время реализации проекта.
   Рассматривая планирование проектов и управление ими, необходимо четко осознавать, что речь идет об управлении неким динамическим объектом. Поэтому система управления проектом должна быть достаточно гибкой, чтобы допускать возможность модификации без глобальных изменений в рабочей программе.
   В системном плане проект может быть представлен «черным ящиком», на входе которого располагаются технические требования и условия финансирования, а на выходе – требуемый результат (рис. 2.1). Выполнение работ обеспечивается наличием необходимых ресурсов:
   • материалов;
   • оборудования;
   • человеческих ресурсов.
   Эффективность работ достигается за счет управления процессом выполнения проекта, что обеспечивает распределение ресурсов, координацию выполняемой последовательности работ и компенсацию внутренних и внешних возмущающих воздействий.
   Рис. 2.1. Представление проекта в виде «черного ящика».

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

Классификация проектов

   Проекты могут значительно отличаться по сфере приложения, составу, предметной области, масштабам, длительности, составу участников, степени сложности, значимости результатов и т. п. Проекты могут быть классифицированы по самым различным признакам. Отметим основные из них.
   • Класс проекта определяется по составу и структуре проекта. Обычно различают:
   – монопроект (отдельный проект, который может быть любого типа, вида и масштаба);
   – мультипроект (комплексный проект, состоящий из ряда монопроектов и требующий мультипроектного управления).
   • Тип проекта определяется по основным сферам деятельности, в которых осуществляется проект. Можно выделить пять основных типов проекта:
   – технический;
   – организационный;
   – экономический;
   – социальный;
   – смешанный.
   Примечание.
   Разработка информационных систем относится, скорее всего, к техническим проектам. У таких проектов две особенности. Во-первых, главная цель проекта четко определена, но отдельные цели должны уточняться по мере достижения частных результатов. Во-вторых, срок завершения и продолжительность проекта определены заранее, желательно их точное соблюдение, однако они также могут корректироваться в зависимости от полученных промежуточных результатов и общего прогресса проекта.
   • Масштаб проекта определяется размером бюджета и количеством участников:
   – мелкие проекты;
   – малые проекты;
   – средние проекты;
   – крупные проекты.
   Можно также рассматривать масштабы проектов в более конкретной форме – отраслевые, корпоративные, ведомственные проекты, проекты одного предприятия.

Основные фазы проектирования информационной системы

   Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).
   В определении количества фаз и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки информационной системы почти во всех случаях являются общими.
   Можно выделить следующие фазы развития информационной системы:
   • формирование концепции;
   • подготовка технического задания;
   • проектирование;
   • разработка;
   • ввод системы в эксплуатацию.
   Рассмотрим каждую из них более подробно.
   Примечание.
   Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) – фазами реализации.
Концептуальная фаза
   Главным содержанием работ на концептуальной фазе является определение проекта, разработка его концепции, включающая:
   • формирование идеи, постановку целей;
   • формирование ключевой команды проекта;
   • изучение мотивации и требований заказчика и других участников;
   • сбор исходных данных и анализ существующего состояния;
   • определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;
   • сравнительную оценку альтернатив;
   • представление предложений, их экспертизу и утверждение.
Подготовка технического предложения
   Главным содержанием фазы подготовки технического предложения является уточнение технического предложения в ходе переговоров с заказчиком о заключении контракта. Общее содержание работ этой фазы:
   • разработка основного содержания, базовой структуры проекта;
   • разработка и утверждение технического задания;
   • планирование, декомпозиция базовой структурной модели проекта;
   • составление сметы и бюджета проекта, определение потребности в ресурсах;
   • разработка календарных планов и укрупненных графиков работ;
   • подписание контракта с заказчиком;
   • ввод в действие средств коммуникации участников проекта и средств контроля за ходом работ.
Проектирование
   На фазе проектирования определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:
   • выполнение базовых проектных работ;
   • разработка частных технических заданий;
   • выполнение концептуального проектирования;
   • составление технических спецификаций и инструкций;
   • представление проектной разработки, экспертиза и утверждение.
Разработка
   На фазе разработки производятся координация и оперативный контроль работ по проекту, осуществляется изготовление подсистем, их объединение и тестирование. Основное содержание:
   • выполнение работ по разработке программного обеспечения;
   • подготовка к внедрению системы;
   • контроль и регулирование основных показателей проекта.
Ввод системы в эксплуатацию
   На фазе ввода системы в эксплуатацию проводятся испытания, идет опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ:
   • комплексные испытания;
   • подготовка кадров для эксплуатации создаваемой системы;
   • подготовка рабочей документации, сдача системы заказчику и ввод ее в эксплуатацию;
   • сопровождение, поддержка, сервисное обслуживание;
   • оценка результатов проекта и подготовка итоговых документов;
   • разрешение конфликтных ситуаций и закрытие работ по проекту;
   • накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития.
   Примечание.
   Начальные фазы проекта имеют решающее влияние на достигаемый результат, так как в них принимаются основные решения, определяющие качество информационной системы. При этом обычно 30 % вклада в конечный результат проекта вносят фазы концепции и предложения, 20 % – фаза проектирования, 20 % – фаза разработки, 30 % – фаза сдачи объекта и завершения проекта.
   Следует иметь в виду, что на обнаружение ошибок, допущенных на стадии системного проектирования, расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных стадиях проекта разработку следует выполнять особенно тщательно. Наиболее часто на начальных фазах допускаются следующие ошибки:
   • ошибки в определении интересов заказчика;
   • концентрация на маловажных, сторонних интересах;
   • неправильная интерпретация исходной задачи;
   • неправильное или недостаточное понимание деталей;
   • неполнота функциональных спецификаций (системных требований);
   • ошибки в определении требуемых ресурсов и сроков;
   • редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

Процессы, протекающие на протяжении жизненного цикла информационной системы

   Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации.
   Существует международный стандарт, регламентирующий жизненный цикл информационных систем – ISO/IEC 12207.
   Примечание.
   ISO расшифровывается как International Organization of Standardization (международная организация по стандартизации), IEC– как International Electrotechnical Commission (международная комиссия по электротехнике).
   Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, включая процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:
   • основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);
   • вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем);
   • организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
   Рассмотрим каждую из указанных групп более подробно.

Основные процессы жизненного цикла

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

Вспомогательные процессы жизненного цикла

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

Организационные процессы

   Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает:
   • выбор методов и инструментальных средств для реализации проекта;
   • определение методов описания промежуточных состояний разработки;
   • разработку методов и средств испытаний созданного программного обеспечения;
   • обучение персонала.
   Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов информационной системы.
   Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.
   Проверка – это процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик информационной системы исходным требованиям.

Структура жизненного цикла информационной системы

   Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно в свою очередь разбить на ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software – одной из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью заслуженно пользуется универсальное CASE-средство Rational Rose).
   Примечание.
   Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. Теперь под термином «CASE-средства» понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Подробному рассмотрению CASE-технологий в данной книге посвящена глава 6.
   Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии:
   • начало;
   • уточнение;
   • конструирование;
   • передача в эксплуатацию.
   Границы каждой стадии определены некоторыми моментами времени, в которые необходимо принимать определенные критические решения и, следовательно, достигать определенных ключевых целей.

Начальная стадия

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

Стадия уточнения

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

Стадия конструирования

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

Стадия передачи в эксплуатацию

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

Модели жизненного цикла информационной системы

   Моделью жизненного цикла информационной системы будем называть некоторую структуру, определяющую последовательность осуществления процессов, действий и задач, выполняемых на протяжении жизненного цикла информационной системы, а также взаимосвязи между этими процессами, действиями и задачами.
   В стандарте ISO/IEC 12207 не конкретизируются в деталях методы выполнения действий и решения задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области.
   К настоящему времени наибольшее распространение получили две основные модели жизненного цикла:
   • каскадная модель, иногда также называемая моделью водопада (waterfall);
   • спиральная модель.

Каскадная модель жизненного цикла информационной системы

   Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные методы проектирования хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографиях, стандартах, учебниках. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими.
   Каскадная модель предусматривает последовательную организацию работ. При этом основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Основные этапы разработки по каскадной модели
   За десятилетия существования каскадной модели разбиение работ на стадии и названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее, все же можно выделить ряд устойчивых этапов разработки, практически не зависящих от предметной области (рис. 2.2):
   • анализ требований заказчика;
   • проектирование;
   • разработка;
   • тестирование и опытная эксплуатация;
   • сдача готового продукта.
   Рис. 2.2. Каскадная модель разработки.

   На первом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.
   На втором этапе разрабатываются проектные решения, удовлетворяющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реализации проекта.
   Третий этап – реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.
   На четвертом этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы информационной системы.
   Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования выполнены в полной мере.
   Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и длиннее. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.
Основные достоинства каскадной модели
   Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим ее основные достоинства.
   • На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы (организационное, методическое, информационное, программное, аппаратное).
   • Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
   Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя при разработке определенных информационных систем. Имеются в виду системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы реального времени.
   Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно последовательным процессом разработки.
Недостатки каскадной модели
   Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:
   • существенная задержка в получении результатов;
   • ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад;
   • сложность параллельного ведения работ по проекту;
   • чрезмерная информационная перенасыщенность каждого из этапов;
   • сложность управления проектом;
   • высокий уровень риска и ненадежность инвестиций.
   Задержка в получении результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей, причем такие несоответствия могут возникать на любом этапе разработки – искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязательно хорошо разбираются в тех предметных областях, для которых производится разработка информационной системы.
   Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.
   Возврат на более ранние стадии. Данный недостаток каскадной модели в общем-то является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы.
   Самым же неприятным является то, что недоработки предыдущего этапа могут обнаруживаться не сразу на последующем этапе, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области). Это означает, что часть проекта должна быть возвращена на начальный этап работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап, поэтому в реальности каскадная схема разработки выглядит так, как показано на рис. 2.3.
   Рис. 2.3. Реальный процесс разработки по каскадной схеме.

   Одной из причин данной ситуации является то, что в качестве экспертов, участвующих в описании предметной области, часто выступают будущие пользователи системы, которые иногда не могут четко сформулировать то, что они хотели бы получить. Кроме того, заказчики и исполнители часто неправильно понимают друг друга вследствие того, что исполнители обычно не являются специалистами в предметной области решаемой задачи, а заказчики далеки от программирования.
   Сложность параллельного ведения работ. Отмеченные проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последовательных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависят друг от друга группы разработчиков. Поэтому преимущества параллельного ведения работ просто теряются.
   Отсутствие параллелизма негативно сказывается и на организации работы всего коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не загружены. Кроме того, при последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передачи проекта на следующую стадию. Так, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Это связано с тем, что более раннее решение уже, возможно, реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка проекта после его передачи на следующий этап.
   Информационная перенасыщенность. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли бы использовать эту часть в своей работе. Когда система состоит из большого количества взаимосвязанных подсистем, то синхронизация внутренней документации становится важной самостоятельной задачей. При этом синхронизация документации на каждую часть системы – не более чем процесс оповещения групп разработчиков. Самим же разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже полученных результатах. Все это может требовать проведения повторного тестирования и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации и разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней.
   Следует также отметить, что, помимо изучения нового материала, не отпадает необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.
   Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта.
   Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для согласования сроков работы и состава передаваемой документации.
   В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени.
   Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, сокращая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабо связанных подсистем.
   Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки – этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования – требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. Причем возврат проекта на доработку вследствие этих причин не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится», и система никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.
   Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.
   Примечание.
   Помимо рассмотренных существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки можно далеко не всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т. п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным их исполнением. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

Спиральная модель жизненного цикла

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

   Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы на следующем витке спирали. На каждой итерации углубляются и последовательно конкретизируются детали проекта, в результате чего выбирается обоснованный вариант, который доводится до окончательной реализации.
   Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего – недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации – как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом существенно упрощается процесс внесения уточнений и дополнений в проект.
Преимущества спиральной модели
   Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели и, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким.
   Рассмотрим преимущества итерационного подхода более подробно.
   • Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
   • При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта).
   • Уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый уровень рисков снижается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели снижение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации, и на начальных итерациях выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т. п. На рис. 2.5 приведены в сравнении графики зависимости уровня рисков от времени разработки для каскадного и итерационного подходов.
   Рис. 2.5. Зависимость рисков от времени разработки.

   • Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет снижения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным в условиях конкурентной борьбы, когда необходимо противостоять продвижению изделия, предлагаемого конкурентами.
   • Итерационный подход упрощает повторное использование компонентов (реализует компонентный подход к программированию – более подробно об этом мы будем говорить в следующей главе). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
   • Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
   • Итерационный подход дает возможность совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.
Недостатки спиральной модели
   Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее – враг хорошего». Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена.
   Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Глава 3
Методология и технология разработки информационных систем

   Методология создания информационных систем заключается в организации процесса построения информационной системы и в управлении этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки.
   Основными задачами, решение которых должна обеспечивать методология создания корпоративных информационных систем (с помощью соответствующего набора инструментальных средств), являются:
   • соответствие создаваемой информационной системы целям и задачам предприятия, а также предъявляемым к ней требованиям по автоматизации бизнес-процессов;
   • гарантирование создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;
   • простота сопровождения, модификации и расширения системы с целью обеспечения ее соответствия изменяющимся условиям работы предприятия;
   • соответствие создаваемой корпоративной информационной системы требованиям открытости, переносимости и масштабируемости;
   • возможность использования в создаваемой системе разработанных ранее и применяемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций).
   Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
   Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
   Технология проектирования может быть представлена как совокупность трех составляющих:
   • заданной последовательности выполнения технологических операций проектирования;
   • критериев и правил, используемых для оценки результатов выполнения технологических операций;
   • графических и текстовых средств (нотаций), используемых для описания проектируемой системы.
   Каждая технологическая операция должна обеспечиваться следующими материальными и информационными ресурсами:
   • данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;
   • методическими материалами, инструкциями, нормативами и стандартами;
   • программными и техническими средствами;
   • исполнителями.
   Результаты выполнения операции должны представляться в некотором стандартном виде, обеспечивающем их адекватное восприятие при выполнении следующей технологической операции (на которой они будут использоваться в качестве исходных данных).
   Можно сформулировать ряд общих требований, которым должна удовлетворять технология проектирования, разработки и сопровождения информационных систем:
   • поддерживать полный жизненный цикл информационной системы;
   • обеспечивать гарантированное достижение целей разработки системы с заданным качеством и в установленное время;
   • обеспечивать возможность разделения (декомпозиции) крупных проектов на ряд подсистем – составных частей, разрабатываемых группами исполнителей ограниченной численности, с последующей интеграцией этих частей;
   Примечание.
   Декомпозиция проекта позволяет повысить эффективность работ. Подсистемы, на которые разбивается проект, должны быть слабо связаны по данным и функциям. Каждая подсистема разрабатывается отдельной группой разработчиков. При этом необходимо обеспечить координацию работ и исключить дублирование результатов, получаемых каждой проектной группой.
   • обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3–7 человек), что обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
   • обеспечивать минимальное время получения работоспособной системы;
   Примечание.
   Здесь имеется в виду не реализация информационной системы в целом, а разработка ее отдельных подсистем. Как правило, даже при наличии полностью завершенного проекта внедрение разработанной системы проводится последовательно отдельными подсистемами. Реализация же всей системы в сжатые сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться менее значимым, чем при реализации отдельных подсистем в более короткие сроки меньшим числом разработчиков.
   • предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
   • обеспечивать независимость выполняемых проектных решений от средств реализации системы – системы управления базами данных, операционной системы, языка и системы программирования.

Методология RAD

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

Основные особенности методологии RAD

   Методология создания информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений (Rapid Application Development, RAD). Данная методология охватывает все этапы жизненного цикла современных информационных систем.
   Методология RAD – это комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
   Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
   • небольшой команде программистов (обычно от 2 до 10 человек);
   • тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки (от 2 до 6 мес);
   • итерационной модели разработки, основанной на тесном взаимодействии с заказчиком – по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
   При использовании методологии RAD большое значение имеют опыт и профессионализм разработчиков. Группа разработчиков должна состоять из профессионалов, имеющих опыт в анализе, проектировании, программировании и тестировании программного обеспечения.
   Основные принципы методологии RAD можно свести к следующим:
   • используется итерационная (спиральная) модель разработки;
   • полное завершение работ на каждом из этапов жизненного цикла не обязательно;
   • в процессе разработки информационной системы обеспечивается тесное взаимодействие с заказчиком и будущими пользователями;
   • применяются CASE-средства и средства быстрой разработки приложений;
   • применяются средства управления конфигурацией, облегчающие внесение изменений в проект и сопровождение готовой системы;
   • используются прототипы, позволяющие полнее выяснить и реализовать потребности конечного пользователя;
   • тестирование и развитие проекта осуществляются одновременно с разработкой;
   • разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
   • обеспечиваются грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

Объектно-ориентированный подход

   Средства RAD позволили реализовать совершенно иную по сравнению с традиционной технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласуется с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектируемой системы.
   Возможность использования подобного подхода в значительной степени является результатом применения принципов объектно-ориентированного проектирования. Эти принципы позволяют преодолеть одну из главных трудностей, возникающих при разработке сложных систем, – колоссальный разрыв между реальным миром (предметной областью) и имитирующей средой.
   Использование объектно-ориентированных принципов позволяет создать описание (модель) предметной области в виде совокупности объектов – сущностей, объединяющих данные и методы обработки этих данных (процедуры). Каждый объект обладает собственным поведением и моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемым и демонстрирует определенное поведение.
   В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования. Объекты обладают целостностью, которая не может быть нарушена. Таким образом, свойства, характеризующие объект и его поведение, остаются неизменными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам.
   Широкое распространение объектно-ориентированное программирование получило с появлением средств визуального программирования, которые обеспечивают слияние (инкапсуляцию) данных с процедурами, описывающими поведение реальных объектов, в объекты программ, которые могут быть отображены определенным образом в графической пользовательской среде. Это позволило приступить к созданию программных систем, максимально похожих на реальные, и добиваться наивысшего уровня абстракции. В свою очередь, объектно-ориентированное программирование позволяет создавать более надежные коды, так как у объектов программ существует точно определенный и жестко контролируемый интерфейс.
   При разработке приложений с помощью инструментов RAD используются множество готовых объектов, сохраняемых в общедоступном хранилище. Однако обеспечивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля».
   Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.
   Таким образом, инструменты RAD позволяют разработчикам сконцентрировать усилия на сущности реальных бизнес-процессов предприятия, для которого создается информационная система. В итоге это приводит к повышению качества разрабатываемой системы.
   Примечание.
   В данном разделе мы лишь поверхностно рассмотрели особенности и преимущества объектно-ориентированных методов проектирования. Более подробно этот вопрос будет обсуждаться далее.

Визуальное программирование

   Применение принципов объектно-ориентированного программирования позволило создать принципиально новые средства проектирования приложений, называемые средствами визуального программирования. Визуальные инструменты RAD позволяют создавать сложные графические интерфейсы пользователя вообще без написания кода программы. При этом разработчик может на любом этапе наблюдать то, что закладывается в основу принимаемых решений.
   Визуальные средства разработки оперируют в первую очередь со стандартными интерфейсными объектами – окнами, списками, текстами, которые легко можно связать с данными из базы данных и отобразить на экране монитора. Другая группа объектов представляет собой стандартные элементы управления – кнопки, переключатели, флажки, меню и т. п., с помощью которых осуществляется управление отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для многократного использования в будущем.
   В настоящее время существует довольно много различных визуальных средств разработки приложений, но все они могут быть разделены на две группы – универсальные и специализированные.
   Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы исключительно на разработку приложений баз данных – с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных.
   Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определенным системам управления базами данных. В качестве примера таких систем можно привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.
   Поскольку задачи создания прототипов и разработки пользовательского интерфейса по существу слились, программист получил непрерывную обратную связь с конечными пользователями, которые могут не только наблюдать за созданием приложения, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психологическим аспектом, который привлекает к RAD все большее число разработчиков.
   Визуальные инструменты RAD позволяют максимально сблизить этапы создания информационных систем: анализ исходных условий, проектирование системы, разработка прототипов и окончательное формирование приложений становятся сходными, так как на каждом этапе разработчики оперируют визуальными объектами.

Событийное программирование

   Логика приложения, построенного средствами RAD, является событийно-ориентированной. Это означает, что каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть открытие и закрытие окон, щелчок на кнопке, нажатие клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п.
   Разработчик реализует логику приложения путем определения обработчика каждого события – процедуры, выполняемой объектом при наступлении соответствующего события. Например, обработчик события «щелчок на кнопке» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помощью событий.
   Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при выполнении операций удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

Фазы жизненного цикла в рамках методологии RAD

   При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:
   • анализа и планирования требований;
   • проектирования;
   • построения;
   • внедрения.
   Рассмотрим каждую из них более подробно.
Фаза анализа и планирования требований
   На фазе анализа и планирования требований определяются:
   • функции, которые должна выполнять разрабатываемая информационная система;
   • наиболее приоритетные функции, требующие разработки в первую очередь;
   • информационные потребности;
   Примечание.
   Определение указанных выше требований выполняется совместно будущими пользователями системы и разработчиками.
   • масштаб проекта;
   • временные рамки для каждой из последующих фаз;
   • сама возможность реализации данного проекта в установленных рамках финансирования на имеющихся аппаратных и программных средствах.
   Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информационной системы с указанием их приоритетов, а также предварительные функциональные и информационные модели системы.
Фаза проектирования
   На фазе проектирования необходимым инструментом являются CASE-средства, используемые для быстрого получения работающих прототипов приложений.
   Прототипы, созданные с помощью CASE-средств, анализируются пользователями, которые уточняют и дополняют те требования к системе, которые не были выявлены на предыдущей фазе. Таким образом, на данной фазе также необходимо участие будущих пользователей в техническом проектировании системы.
   Далее на этой фазе проводится анализ и, если требуется, корректировка функциональной модели системы. Детально рассматривается каждый процесс системы. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалоговое окно или отчет (это позволяет устранить неясности или неоднозначности). Затем определяются требования разграничения доступа к данным.
   Примечание.
   Для построения всех моделей и прототипов должны быть использованы именно те CASE-средства, которые будут затем применяться при построении системы. Данное требование связано с тем, что при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения проектной информации позволяет избежать этой опасности.
   После детального рассмотрения процессов определяется количество функциональных элементов разрабатываемой системы. Это позволяет разделить информационную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора месяцев). С использованием CASE-средств проект распределяется между различными командами – делится функциональная модель.
   На этой же фазе происходит определение набора необходимой документации.
   Результатами данной фазы являются:
   • общая информационная модель системы;
   • функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
   • точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
   • построенные прототипы экранов, диалоговых окно и отчетов.
   Примечание.
   Одной из особенностей применения методологии RAD на данной фазе является то, что каждый созданный прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. В противоположность этому при традиционном подходе использовались средства прототипирования, не предназначенные для построения реальных приложений, поэтому разработанные прототипы не годились для последующих фаз и просто «выбрасывались» после того, как решали задачу устранения неясностей в проекте.
Фаза построения
   На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных ранее моделей, а также требований нефункционального характера. Разработка приложения ведется средствами визуального программирования. Формирование программного кода частично выполняется с помощью автоматических генераторов кода, входящих в состав CASE-средств. Код генерируется на основе разработанных моделей.
   На фазе построения также требуется участие пользователей системы, которые оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
   После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом.
   Завершается физическое проектирование системы, а именно:
   • определяется необходимость распределения данных;
   • производится анализ использования данных;
   • производится физическое проектирование базы данных;
   • определяются требования к аппаратным ресурсам;
   • определяются способы повышения производительности;
   • завершается разработка документации проекта.
   Результатом данной фазы является готовая информационная система, удовлетворяющая всем требованиям пользователей.
Фаза внедрения
   Фаза внедрения в основном сводится к обучению пользователей разработанной информационной системы.
   Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.
   Примечание.
   Приведенная схема разработки информационной системы не является универсальной. Вполне возможны различные отклонения от нее. Это связано с зависимостью схемы выполнения проекта от начальных условий, при которых начинается разработка (например, разрабатывается совершенно новая система или на предприятии уже существует некоторая информационная система). Во втором случае существующая система может либо использоваться в качестве прототипа новой системы, либо интегрироваться в новую разработку в качестве одной из подсистем.

Ограничения методологии RAD

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

Профили открытых информационных систем

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

Понятие профиля информационной системы

   При создании и развитии сложных, распределенных, тиражируемых информационных систем требуется гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций системы. Для унификации и регламентирования такие совокупности базовых стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, функций, процессов и компонентов системы. В связи с этим выделилось и сформировалось понятие профиля информационной системы как основного инструмента функциональной стандартизации.
   Профиль – это совокупность нескольких (или подмножество одного) базовых стандартов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций.
   Профиль формируется исходя из функциональных характеристик объекта стандартизации. В профиле выделяются и устанавливаются допустимые возможности и значения параметров каждого базового стандарта и/или нормативного документа, входящего в профиль.
   Профиль не должен противоречить входящим в него базовым стандартам и нормативным документам. Применяемые в соответствии с профилем необязательные возможности и значения параметров, выбранные из альтернативных вариантов, должны оставаться в допустимых пределах.
   На базе одной совокупности базовых стандартов могут формироваться и утверждаться различные профили для разных проектов информационных систем. Ограничения базовых документов профиля и их согласованность, контролируемая разработчиками профиля, должны обеспечивать качество, совместимость и корректное взаимодействие отдельных компонентов системы, соответствующих профилю, в заданной области его применения.
   Базовые стандарты и профили в зависимости от проблемно-ориентированной области применения информационных систем могут использоваться как непосредственные директивные, руководящие или рекомендательные документы, а также как нормативная база, необходимая при выборе или разработке средств автоматизации технологических этапов или процессов создания, сопровождения и развития информационных систем.
   Обычно рассматривают две группы профилей, регламентирующих:
   • архитектуру и структуру информационной системы;
   • процессы проектирования, разработки, применения, сопровождения и развития системы.
   В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:
   • профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта;
   • профили информационной системы, предназначенные для решения некоторого класса прикладных задач.
   Профили информационных систем унифицируют и регламентируют только часть требований, характеристик, показателей качества объектов и процессов, выделенных и формализованных на базе стандартов и нормативных документов. Другая часть функциональных и технических характеристик системы определяется заказчиками и разработчиками творчески, без учета положений нормативных документов.

Принципы формирования профиля информационной системы

   Профили информационных систем призваны решить следующие задачи:
   • снижение трудоемкости проектов;
   • повышение качества компонентов информационных систем;
   • обеспечение расширяемости и масштабируемости разрабатываемых систем;
   • обеспечение возможности функциональной интеграции в информационную систему задач, которые раньше решались раздельно;
   • обеспечение переносимости прикладного программного обеспечения.
   В зависимости от того, какие из указанных задач являются наиболее приоритетными, производится выбор стандартов и документов для формирования профиля.
   Актуальность использования профилей информационных систем обусловлена современным состоянием стандартизации информационных технологий, которое характеризуется следующими особенностями:
   • существует множество международных и национальных стандартов, которые не полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и применения сложных информационных систем;
   • длительные сроки разработки, согласования и утверждения международных и национальных стандартов приводят к их консерватизму и хроническому отставанию от современных информационных технологий;
   • функциональными стандартами поддержаны и регламентированы только самые простые объекты и рутинные, массовые процессы (телекоммуникации, программирование, документирование программ и данных), а наиболее сложные и творческие процессы создания и развития крупных распределенных информационных систем (системный анализ и проектирование, интеграция компонентов и систем, испытания и сертификация) почти не поддержаны требованиями и рекомендациями стандартов из-за трудности их формализации и унификации;
   • совершенствование и согласование нормативных и методических документов в ряде случаев позволяют создать на их основе национальные и международные стандарты.
   Подходы к формированию профилей информационных систем могут быть различными. В международной функциональной стандартизации информационных технологий принято довольно жесткое понятие профиля. Считается, что его основой могут быть только утвержденные международные и национальные стандарты. Использование стандартов де-факто и нормативных фирменных документов не допускается. При таком подходе затруднены унификация, регламентирование и параметризация множества конкретных функций и характеристик сложных объектов архитектуры и структуры современных информационных систем.
   Другой подход к разработке и применению профилей информационных систем состоит в использовании совокупности адаптированных и параметризованных базовых международных и национальных стандартов и открытых спецификаций, отвечающих стандартам де-факто и рекомендациям международных консорциумов.
   Эталонная модель среды открытых систем определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют.
   Между приложениями и средой определяются стандартизованные прикладные программные интерфейсы (Application Programming Interface, API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды системы. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде профилей компонентов системы. Таким образом, профили информационной системы с иерархической структурой могут включать в себя:
   • стандартизованные описания функций, выполняемых данной системой;
   • функции взаимодействия системы с внешней для нее средой;
   • стандартизованные интерфейсы между приложениями и средой информационной системы;
   • профили отдельных функциональных компонентов, входящих в систему.
   Для эффективного использования конкретного профиля необходимо:
   • выделить объединенные логической связью проблемно-ориентированные области функционирования, где могут применяться стандарты, общие для одной организации или группы организаций;
   • идентифицировать стандарты и нормативные документы, варианты их использования и параметры, которые необходимо включить в профиль;
   • документально зафиксировать части конкретного профиля, в которых требуется создание новых стандартов или нормативных документов, и идентифицировать характеристики, которые могут оказаться важными для разработки недостающих стандартов и нормативных документов этого профиля;
   • формализовать профиль в соответствии с его категорией, включая стандарты, различные варианты нормативных документов и дополнительные параметры, которые непосредственно связаны с профилем;
   • опубликовать профиль и/или продвигать его по формальным инстанциям для дальнейшего распространения.
   При использовании профилей важно обеспечить корректность их применения путем тестирования, испытаний и сертификации. Для этого требуется создание технологии контроля и тестирования в процессе применения профиля. Данная технология должна поддерживаться совокупностью методик, инструментальных средств, составом и содержанием оформляемых документов на каждом этапе выполнения проекта.
   Использование профилей способствует унификации при разработке тестов, проверяющих качество и взаимодействие компонентов проектируемой информационной системы. Профили должны определяться таким образом, чтобы тестирование их реализации можно было проводить по возможности наиболее полно по стандартизованной методике. При этом возможно применение ранее разработанных методик, так как международные стандарты и профили являются основой для создания общепризнанных аттестационных тестов.

Структура профилей информационных систем

   Разработка и применение профилей являются органической частью процессов проектирования, разработки и сопровождения информационных систем. Профили характеризуют каждую конкретную информационную систему на всех стадиях ее жизненного цикла, задавая согласованный набор базовых стандартов, которым должна соответствовать система и ее компоненты.
   Стандарты, важные с точки зрения заказчика, должны задаваться в техническом задании на проектирование системы и составлять ее первичный профиль. То, что не задано в техническом задании, первоначально остается на усмотрение разработчика системы, который, руководствуясь требованиями технического задания, может дополнять и развивать профили системы и впоследствии согласовывать их с заказчиком. Таким образом, профиль конкретной системы не является статичным, он развивается и конкретизируется в процессе проектирования информационной системы и оформляется в составе документации проекта системы.
   В профиль конкретной системы включаются спецификации компонентов, разработанных в составе данного проекта, и спецификации использованных готовых программных и аппаратных средств, если эти средства не специфицированы соответствующими стандартами. После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и развитии.
   Формирование и применение профилей конкретных информационных систем выполняется на основе международных и национальных стандартов, ведомственных нормативных документов, а также стандартов де-факто при условии доступности соответствующих им спецификаций. Для обеспечения корректного применения профилей их описания должны содержать:
   • определение целей использования профиля;
   • точное перечисление функций объекта или процесса стандартизации, определяемого профилем;
   • формализованные сценарии применения базовых стандартов и спецификаций, включенных в профиль;
   • сводку требований к информационной системе или к ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;
   • нормативные ссылки на конкретный набор стандартов и других нормативных документов, составляющих профиль, с точным указанием применяемых редакций и ограничений, способных повлиять на достижение корректного взаимодействия объектов стандартизации при использовании профиля;
   • информационные ссылки на все исходные документы.
   На стадиях жизненного цикла информационной системы выбираются и затем применяются следующие основные функциональные профили:
   • прикладного программного обеспечения;
   • среды информационной системы;
   • защиты информации в информационной системе;
   • инструментальных средств, встроенных в информационную систему.
Профиль прикладного программного обеспечения
   Прикладное программное обеспечение всегда является проблемно-ориентированным и определяет основные функции информационной системы. Функциональные профили системы должны включать в себя согласованные базовые стандарты. При использовании функциональных профилей информационных систем следует еще иметь в виду согласование этих профилей между собой. Необходимость такого согласования возникает, в частности, при использовании стандартизованных интерфейсов API, в том числе интерфейсов приложений со средой их функционирования и со средствами защиты информации. При согласовании функциональных профилей возможны также уточнения профиля среды системы и профиля встраиваемых инструментальных средств создания, сопровождения и развития прикладного программного обеспечения.
Профиль среды информационной системы
   Профиль среды информационной системы должен определять ее архитектуру в соответствии с выбранной моделью обработки данных.
   Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по следующим функциональным областям эталонной модели OSE/RM:
   • графического пользовательского интерфейса;
   • реляционных или объектно-ориентированных СУБД (например, стандарта языка SQL-92 и спецификации доступа к разным базам данных);
   • операционных систем с учетом сетевых функций, выполняемых на уровне операционной системы;
   • телекоммуникационной среды в части услуг и служб прикладного уровня (электронной почты, доступа к удаленным базам данных, передачи файлов, доступа к файлам и управления файлами).
   Профиль среды распределенной системы должен включать стандарты протоколов транспортного уровня, стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u), а также стандарты средств сопряжения проектируемой информационной системы с сетями передачи данных общего назначения.
   Выбор аппаратных платформ информационной системы связан с определением их параметров: вычислительной мощности серверов и рабочих станций в соответствии с проектными решениями по разделению функций между клиентами и серверами; степени масштабируемости аппаратных платформ; надежности. Профиль среды должен содержать стандарты, определяющие параметры технических средств и способы их измерения (например, стандартные тесты измерения производительности).
Профиль защиты информации
   Профиль защиты информации должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в техническом задании на систему. Построение профиля защиты информации в распределенных системах клиент-сервер методически связано с точным определением компонентов системы, ответственных за те или иные функции, службы и услуги, и средств защиты информации, встроенных в эти компоненты. Функциональная область защиты информации включает в себя следующие функции, реализуемые разными компонентами системы:
   • функции, реализуемые операционной системой;
   • функции защиты от несанкционированного доступа, реализуемые на уровне программного обеспечения промежуточного слоя;
   • функции управления данными, реализуемые СУБД;
   • функции защиты программных средств, включая средства защиты от вирусов;
   • функции защиты информации при обмене данными в распределенных системах, включая криптографические функции;
   • функции администрирования средств безопасности.
   Профиль защиты информации должен включать указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей. Профиль должен также включать указания на методы и средства резервного копирования информации и восстановления информации при отказах и сбоях аппаратуры системы.
Профиль инструментальных средств
   Профиль инструментальных средств, встроенных в информационную систему, должен отражать решения по выбору методологии и технологии создания, сопровождения и развития информационной системы. В этом профиле должны содержаться ссылки на описание выбранных методологии и технологии, выполненное на стадии эскизного проектирования системы.
   Состав инструментальных средств определяется на основании решений и нормативных документов об организации сопровождения и развития информационной системы. При этом должны быть учтены правила и порядок, регламентирующие внесение изменений в действующие системы. Функциональная область профиля инструментальных средств, встроенных в систему, охватывает функции централизованного управления и администрирования, связанные с:
   • контролем производительности и корректности функционирования системы в целом;
   • конфигурированием прикладного программного обеспечения, тиражированием версий;
   • управлением доступом пользователей к ресурсам системы и конфигурированием ресурсов;
   • перенастройкой приложений в связи с изменениями прикладных функций информационной системы;
   • настройкой пользовательских интерфейсов (экранных форм и отчетов);
   • ведением баз данных системы;
   • восстановлением работоспособности системы после сбоев и аварий.
   Дополнительные ресурсы, необходимые для функционирования встроенных инструментальных средств, такие как минимальный и рекомендуемый объемы оперативной памяти, размеры требуемого дискового пространства и т. п., должны быть учтены в разделе проекта, относящемся к среде информационной системы.
   Выбор инструментальных средств, встроенных в систему, должен производиться в соответствии с требованиями профиля среды. Ссылки на соответствующие стандарты, входящие в профиль среды, должны содержаться и в профиле инструментальных средств.
   В этом профиле должны также содержаться ссылки на требования к средствам тестирования, которые необходимы для сопровождения и развития системы и должны быть в нее встроены. В число встроенных в информационную систему средств тестирования должны входить средства функционального тестирования приложений, тестирования интерфейсов, системного тестирования и тестирования серверов/клиентов при максимальной нагрузке.

Стандарты и методики

   Одним из важных условий эффективного использования информационных технологий является внедрение корпоративных стандартов. Корпоративные стандарты представляют собой соглашение о единых правилах организации технологии или управления. При этом за основу корпоративных стандартов могут приниматься отраслевые, национальные и даже международные стандарты.
   Однако динамика развития информационных технологий приводит к быстрому устареванию существующих стандартов и методик разработки информационных систем. Так, в связи со значительным прогрессом в области программного обеспечения и средств вычислительной техники наблюдается рост размеров и сложности информационных систем. При этом существенно меняются требования как к основным функциям и сервисным возможностям систем, так и к динамике изменения этих функций. В этих условиях применение классических способов разработки и обеспечения качества информационных систем становится малоэффективным и не приводит к уровню качества, адекватному реальным требованиям.
   Полезны в этом отношении стандарты открытых систем (в первую очередь стандарты на интерфейсы различных видов, включая лингвистические, и на протоколы взаимодействия). Однако разработка систем в новых условиях требует также новых методов проектирования и новой организации проектных работ. Проектирование и методическая поддержка разработки информационных систем, включая программное обеспечение (ПО) и базы данных (БД), традиционно поддерживаются многими стандартами и фирменными методиками. Вместе с тем известно, что требуется адаптивное планирование разработки, в том числе в динамике процесса ее выполнения. Одним из способов адаптивного проектирования является разработка и применение профилей жизненного цикла информационных систем и программного обеспечения. Корпоративные стандарты образуют целостную систему, которая включает три вида стандартов:
   • на продукты и услуги;
   • на процессы и технологии;
   • на формы коллективной деятельности, или управленческие стандарты.

Виды стандартов

   Существующие на сегодняшний день стандарты можно условно разделить на несколько групп.
   • По предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования информационных систем и программного обеспечения.
   • По утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или ведомственные национальные стандарты (например, ГОСТ, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (например, OMG), стандарты де-факто – официально никем не утвержденные, но фактически действующие (например, стандартом де-факто долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования C), фирменные стандарты (например, Microsoft ODBC).
   • По методическому источнику. К этой группе относятся различного рода методические материалы ведущих фирм-разработчиков программного обеспечения, фирм-консультантов, научных центров, консорциумов по стандартизации.
   Примечание.
   Необходимо иметь в виду, что, хотя это и не очевидно, в каждую из указанных выше групп и подгрупп входят стандарты, существенно различающиеся по степени обязательности для различных организаций; конкретности и детализации содержащихся требований; открытости и гибкости, а также адаптируемости к конкретным условиям.
   Далее мы рассмотрим методику CDM (Custom Development Method) фирмы Oracle по разработке прикладных информационных систем под заказ, Международный стандарт ISO/IEC 12207:1995-08-01 01 на организацию жизненного цикла продуктов программного обеспечения и язык UML (Unified Modeling Language – универсальный язык моделирования), принятый консорциумом OMG (Object Management Group) в качестве стандарта описания программного обеспечения.
   Поскольку указанные стандарты представляют собой весьма объемные документы, изложенные на десятках и даже сотнях страниц, то мы рассмотрим их лишь на уровне общей структуры и основных особенностей.

Методика CDM фирмы Oracle

   Одним из уже сложившихся направлений деятельности фирмы Oracle стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика CDM является развитием давно разработанной методики CASE-Method фирмы Oracle, применяемой в CASE-средстве Oracle CASE (в новых версиях – Designer/2000).
   Ниже перечислены основные составляющие CASE-технологии и инструментальной среды фирмы Oracle.
   • Методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов.
   • Поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта.
   • Ориентация на реализацию приложений в архитектуре клиент-сервер с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя.
   • Наличие централизованной базы данных – репозитария. Репозитарий предназначен для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Он представляет собой базу данных специальной структуры, работающую под управлением СУБД Oracle.
   • Возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД Oracle. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуаций, в которых каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других.
   • Автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты, с помощью которых можно по спецификациям концептуального уровня (модели предметной области) автоматически получать первоначальный вариант спецификации уровня проектирования (описание структуры базы данных и состава программных модулей), чтобы на его основе после всех необходимых уточнений и дополнений автоматически генерировать готовые к выполнению программы.
   • Автоматизация различных стандартных действий по проектированию и разработке приложения. Предусматривается генерация многочисленных отчетов по содержимому репозитария, обеспечивающих полное документирование текущей версии системы на всех этапах ее разработки; с помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и непротиворечивость.
Общая структура
   Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов.
   Методика CDM определяет следующие фазы жизненного цикла информационной системы:
   • стратегия;
   • анализ (формулирование детальных требований к прикладной системе);
   • проектирование (преобразование требований в детальные спецификации системы);
   • реализация (написание и тестирование приложений);
   • внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);
   • эксплуатация (поддержка и сопровождение приложения, планирование будущих функциональных расширений).
   Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников совершенствования. Этот этап не является обязательным в случае, когда существующие технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации.
   Примечание.
   Более точным названием первого этапа, вероятно, было бы «определение требований».
   На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации, особенности функционирования и т. п. Результатом являются модели двух типов:
   • информационные, отражающие структуру и общие закономерности предметной области;
   • функциональные, описывающие особенности решаемых задач.
   На третьей стадии (этапе проектирования) на основании концептуальных моделей вырабатываются технические спецификации будущей прикладной системы – определяются структура и состав базы данных, специфицируется набор программных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных концептуальных моделей.
   На этапе реализации создаются программы, отвечающие всем требованиям проектных спецификаций.
   Примечание.
   Генераторы приложений, входящие в состав CASE-средства DESIGNER/2000, позволяют полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность.
   Методика CDM выделяет следующие процессы, протекающие на протяжении жизненного цикла информационной системы:
   • определение производственных требований;
   • исследование существующих систем;
   • определение технической архитектуры;
   • проектирование и построение базы данных;
   • проектирование и реализация модулей;
   • конвертирование данных;
   • документирование;
   • тестирование;
   • обучение;
   • переход к новой системе;
   • поддержка и сопровождение.
   Процессы состоят из последовательностей задач, задачи разных процессов связаны с помощью явно обозначенных ссылок.
Особенности методики CDM
   Отметим основные особенности методики CDM, определяющие область ее применения и присущие ей ограничения.
   • Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:
   – классическая модель предусматривает все этапы;
   – быстрая разработка ориентирована на использование инструментов моделирования и программирования Oracle;
   – облегченный подход рекомендуется в случае малых проектов и возможности быстро прототипировать приложения.
   • Методика не предусматривает включение дополнительных задач, которые не оговорены в CDM, и их привязку к остальным. Также исключено удаление задачи (и порождаемых ею документов), не предусмотренное ни одной из трех моделей жизненного цикла, и изменение последовательности выполнения задач по сравнению с предложенной.
   • Все модели жизненного цикла являются по сути каскадными. Даже «облегченный подход», несмотря на итерационность действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
   • Методика не является обязательной, но может считаться фирменным стандартом. При формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптации.
   • Прикладная система рассматривается в основном как программно-техническая система, например, возможность выполнения организационно-структурных преобразований, практически всегда происходящих при переходе к новой информационной системе, в этой методике отсутствует.
   • CDM теснейшим образом опирается на инструментарий Oracle, несмотря на утверждения о простоте адаптации CDM к проектам, в которых используется другой комплект инструментальных средств.
   • Методика CDM представляет собой вполне конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инструментальные средства и СУБД фирмы Oracle.

Международный стандарт ISO/IEC 12207: 1995-08-01

   Первая редакция ISO 12207 была подготовлена в 1995 г. подкомитетом SC7 (Проектирование программного обеспечения) объединенного технического комитета JTC1 (Информационные технологии) ISO/IEC.
   По определению, ISO 12207 – базовый стандарт процессов жизненного цикла ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, в которых ПО является одной из составных частей. Стандарт определяет стратегию и общий порядок создания и эксплуатации ПО, он охватывает жизненный цикл от концептуализации идей до завершения проекта.
   Целесообразность совместного использования стандартов на информационные системы и на ПО обуславливается одним из положений ISO 12207, согласно которому процессы, протекающие во время жизненного цикла ПО, должны быть совместимы с процессами, протекающими во время жизненного цикла автоматизированной системы.
   Согласно ISO 12207, система – это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для удовлетворения определенных потребностей или целей.
   Примечание.
   В отличие от CDM фирмы Oracle, стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны относятся к одной организации.
Общая структура
   В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов (приобретение, поставка, разработка и т. п.). Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами CDM вместе взятыми.
   Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие – на ряд задач.
   Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
Основные и вспомогательные процессы жизненного цикла
   В стандарте ISO 12207 описаны пять основных процессов жизненного цикла программного обеспечения.
   • Процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу.
   • Процесс поставки определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или службой.
   • Процесс разработки определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.
   • Процесс функционирования определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в целом (а не только программного обеспечения) в процессе ее функционирования в интересах пользователей. В отличие от действий, перечисленных разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности.
   • Процесс сопровождения определяет действия персонала, обеспечивающего сопровождение программного продукта, то есть управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности; сюда же относятся установка программного изделия на вычислительной системе и его удаление.
   Помимо основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла программного изделия и обеспечивают должное качество проекта программного обеспечения. К вспомогательным процессам относятся:
   • процесс решения проблем;
   • процесс документирования;
   • процесс управления конфигурацией;
   • процесс обеспечения качества;
   • процесс верификации;
   • процесс аттестации;
   • процесс совместной оценки;
   • процесс аудита.
   В стандарте ISO 12207 также определяются четыре организационных процесса:
   • процесс управления;
   • процесс создания инфраструктуры;
   • процесс усовершенствования;
   • процесс обучения.
   Примечание.
   Под процессом усовершенствования в стандарте ISO 12207 понимается не усовершенствование информационной системы или программного обеспечения, а улучшение самих процессов приобретения, разработки, обеспечения качества и т. д., реально осуществляемых в организации.
   И наконец, в стандарте ISO 12207 определен один особый процесс, называемый процессом адаптации, который определяет основные действия, необходимые для адаптации этого стандарта к условиям конкретного проекта.
Особенности стандарта ISO 12207
   Все сказанное выше позволяет сформулировать некоторые особенности стандарта ISO 12207.
   • Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и решения задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.
   Примечание.
   Согласно стандарту ISO 12207, модель жизненного цикла– это структура, содержащая процессы, действия и задачи, которые выполняются (решаются) в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
   • Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.
   Примечание.
   Согласно ISO 12207, добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Причем «контракт» понимается в самом широком смысле – от юридически оформленного документа до неформального соглашения. Это соглашение может быть определено даже единственной стороной – как задача, поставленная самому себе.
   • Стандарт принципиально не содержит описания конкретных методов действий, а тем более заготовок решений или документации. Он лишь описывает архитектуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как предоставлять услуги или решать задачи, включенные в процессы. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.
   • Качество обеспечивается с помощью различных процессов, выполняемых с разной степенью независимости контролирующей деятельности, вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM, контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие пожеланиям потребителя.
   • Степень обязательности рассматриваемого стандарта следующая: после решения организации о соответствии торговых отношений стандарту ISO 12207 в качестве условия оговаривается ее ответственность за минимальный набор процессов и задач, которые обеспечивают согласованность с этим стандартом.
   • Стандарт содержит предельно мало описаний, направленных на проектирование базы данных. Это можно считать оправданным, так как разные системы и разные прикладные комплексы программного обеспечения могут не только использовать весьма специфические типы баз данных, но и вообще их не применять.
   Ценность стандарта ISO 12207 в том, что в нем представлены наборы задач, характеристики качества, критерии оценки и т. п., обеспечивающие всесторонний охват проектных ситуаций. Например, при анализе требований к системе предусматривается, что:
   • рассматривается область применения системы для определения требований, предъявляемых к системе;
   • спецификация требований системы должна описывать функции и возможности системы, области применения системы, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования.
   Далее, при анализе требований к программному обеспечению предусмотрено 11 характеристик качества, позволяющих обеспечить заданный уровень качества.
   При этом разработчик должен установить и документировать в виде требований к программному обеспечению следующие спецификации и характеристики:
   • функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
   • внешние связи (интерфейсы) с единицей программного обеспечения;
   • квалификационные требования;
   • спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
   • спецификации защищенности, включая спецификации, связанные с компрометацией точности информации;
   • человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
   • определение данных и требований к базе данных;
   • установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
   • документацию пользователя;
   • требования к интерфейсу пользователя.
   Примечание.
   Согласно стандарту ISO 12207, квалификационные требования – это набор критериев, или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.
   Хотя стандарт не предписывает конкретной модели жизненного цикла или метода разработки, он определяет, что стороны-участники при использовании стандарта ответственны за:
   • выбор модели жизненного цикла для разрабатываемого проекта;
   • адаптацию процессов и задач стандарта к этой модели;
   • выбор и применение методов разработки программного обеспечения;
   • выполнение действий и решение задач, подходящих для проекта программного обеспечения.

Универсальный язык моделирования

   Универсальный язык моделирования (UML), разработка которого началась с середины 90-х годов прошлого века на базе нескольких объектно-ориентированных методов и нотаций описания информационных систем, в настоящее время является общепринятым стандартом документирования процесса создания информационных систем и программного обеспечения. В качестве стандарта UML принят консорциумом OMG, в который входят все ведущие производители программного обеспечения.
   Наиболее весомый вклад в разработку языка внесли известные специалисты Грэди Буч (Grady Booch), Джим Румбах (Jim Rumbaugh) и Ивар Якобсон (Ivar Jacobson); за счет объединения методик каждого из них собственно и возник язык UML.
   Язык UML постоянно совершенствуется. В настоящее время текущей спецификацией языка является версия 2.0. Кроме того, сам язык предоставляет пользователю возможности расширения ядра языка для нужд конкретного производителя, хотя это и не рекомендуется делать по причине достаточности возможностей языка.
   Первоначально язык UML создавался, чтобы упростить описание информационных систем на базе объектно-ориентированной технологии. Сейчас средствами языка можно описывать также программное обеспечение, оперирующее в основном потоками данных и методами их обработки (процедурное, алгоритмическое проектирование).
Предшественники UML
   Причиной, побудившей к созданию универсального языка описания программного обеспечения, явилась постоянно возрастающая сложность проектируемых информационных систем, которая в свою очередь диктуется усложнением решаемых задач.
   Когда количество объектов информационной системы не превышает 6–8 (то есть психологического критерия, до которого человек еще способен оперировать информацией без записи и дополнительной тренировки), сложности, возникающие при проектировании системы, преодолимы и без специальных средств. Такую информационную систему (для одного рабочего места, для небольшой компании) способен создать один человек. Когда же число объектов достигает тысяч и десятков тысяч, а число состояний и переходов между ними – миллионов, ни один специалист, каким бы образованным и опытным он ни был, не способен охватить систему в целом. К примеру, система навигации должна размещаться на тысячах автомобилей, морских и речных судах, железнодорожных составах, десятках искусственных спутников Земли, использовать тысячи компьютеров и всевозможных сетей связи.
   Такие информационные системы под силу создавать только группам разработчиков, как правило, с разделением обязанностей на аналитиков, проектировщиков, программистов, тестеров и, конечно, руководителей. А там, где трудится коллектив, просто необходим понятный всем инструмент общения. Для инженеров-механиков таким инструментом, понятным как его коллегам, так и простым рабочим, являются машиностроительные чертежи, для строителей – всевозможные эскизы, планы и т. д., для инженеров-электронщиков – электрические схемы, топологические чертежи. Для программистов языком такого общения долгое время являлись алгоритмы и естественный человеческий язык. Каждый, кто хоть немного разбирается в программировании, понимает, что за исключением очень простых примеров без пояснений практически невозможно разобраться в коде программ, написанных не им самим, а часто и им самим, но давно.
   Диаграммы на языке UML можно назвать «иллюстрациями к программному коду».
   Создание диаграмм аналогично созданию проекта в строительстве – можно обойтись и без него, например, при строительстве сарая на дачном участке, однако чем больше здание, тем труднее это делать и тем неопределеннее конечный результат. Информационная система, описанная UML-диаграммами, показывает разработчику результат, который необходимо достичь в процессе проектирования.
   Проблема коммуникации внутри коллектива разработчиков, требующая документирования результатов проектирования, чтобы иметь возможность в дальнейшем вносить в систему усовершенствования, является не единственной побудительной причиной создания UML.
   Абсолютное большинство информационных систем, используемых в наши дни, в той или иной степени опираются на объектно-ориентированную технологию. Ключевой в эффективности таких информационных систем является удачно построенная иерархия объектов, позволяющая использовать преимущества объектно-ориентированной технологии, включая инкапсуляцию, наследование и полиморфизм (подробнее об объектно-ориентированной разработке информационных систем см. далее в этой книге).
   Выявление объектов-сущностей, их свойств, построение их иерархии является в большинстве случаев нетривиальной задачей, которая решается методами объектно-ориентированного анализа.
   Иерархия объектов должна отражать закономерности функционирования предметной области, то есть области деятельности человека, для которой создается информационная система. Прямолинейное проектирование, как правило, не является оптимальным. Из практики известно, что самыми удачными решениями являются системы, авторам которых удалось найти «изящную» комбинацию, неординарный ход, «изюминку» в построении иерархии объектов информационной системы.
   Построение иерархии объектов требует опыта и усердной работы аналитиков и системных проектировщиков, для облегчения интеллектуального труда которых весьма кстати пришлись возможности нотации (лат. notatio – обозначение, система записи), позволяющей легко и понятно фиксировать возникающие идеи. Этой цели служат всевозможные кружочки, квадратики, стрелки и линии, с помощью которых человек пытается зафиксировать свои мысли на листе бумаги или в электронном документе. С появлением соответствующих методик, а впоследствии и UML, такая запись становится стандартизированной и понятной другим людям.
   Примечание.
   Проблемой, ставящей под угрозу осуществление крупного проекта, является уход из команды разработчиков одного или нескольких ведущих специалистов. Использование стандарта документирования процесса разработки минимизирует риски срыва работы над проектом в таких случаях.
   Универсальный язык моделирования возник не на пустом месте. С середины восьмидесятых годов ведутся разработки методик, позволяющих автоматизировать процесс построения иерархий объектов. Некоторые из методик, например, CRC-карточки, не потеряли своей актуальности.
   Словарь предметной области.
   В словарь предметной области включаются термины, используемые специалистами, для которых разрабатывается система. Словарь создается с целью наиболее полного понимания поставленных задач проектировщиками, которые, как правило, специалистами в этой области не являются.
   Словарь представляет собой список терминов с их краткой расшифровкой. По мере работы над системой словарь предметной области может дополняться. Составлением словаря занимаются те из проектировщиков и аналитиков, кто имеет непосредственный контакт с конечными пользователями.
   Использование в работе такого словаря весьма полезно и эффективно при решении практически любых задач.
   Диаграммы сущность-связь.
   Построение диаграмм сущность-связь основано на выявлении форм взаимосвязи и взаимодействия сущностей. Подробнее эти диаграммы описаны в главе 6 на примере проектирования структуры базы данных.
   Метод Аббота.
   Метод Аббота заключается в описании задачи на простом человеческом языке и анализе полученного текста. Существительные в этом случае принимаются как вероятные кандидаты на роль объектов-сущностей, а глаголы – на методы этих сущностей.
   Метод Аббота поддается автоматизации, в частности, соответствующие системы были построены Токийским технологическим институтом и фирмой Фуджи.
   CRC-карточки.
   Аббревиатура CRC означает Class-Responsibilities-Collaborators (класс-ответственность-участники). CRC-карточки впервые предложили Кент Бек (Kent Beck) и Уорд Каннингхэм (Ward Cunningham) для обучения объектно-ориентированному программированию.
   CRC-карточки представляют собой обычные картонные карточки размером 10 на 15 сантиметров, на которых карандашом сверху пишется название класса, слева – за что он отвечает, справа – с какими классами он взаимодействует (сотрудничает, обменивается сообщениями).
   В ходе анализа появляются новые карточки, в старые вносятся изменения. Может возникнуть ситуация, когда один из классов (объектов) окажется слишком большим, и на стадии реализации системы это приведет к необходимости его постоянного использования. В этом случае целесообразно разбить его на несколько классов или передать часть его функций другому классу.
   Примечание.
   Возможна ситуация, когда одни и те же сообщения будут передаваться между разными классами. Можно выделить такие сообщения в отдельный класс для удобства отладки и внесения изменений. Так поступают, например, при обращениях к базе данных с помощью SQL-запросов, выделяя транзакции в отдельный класс.
   Карточки раскладываются в разном порядке, что помогает определить возможные варианты наследования свойств и методов, движения потоков данных.
   Метод Буча.
   Метод Буча стал основой UML. Предложенная Бучем графическая нотация достаточно распространена и наряду с UML используется в системах автоматизации процесса разработки программного обеспечения, в частности, в системе Rational Rose.
   Применяемые в методе Буча обозначения несколько отличаются от обозначений, принятых в UML. Так, класс в нотации UML представляет собой прямоугольник, в нотации Буча – облако, каким его рисуют дети, что по замыслу автора символизирует абстрактность этого понятия. Кроме того, язык UML более формализован за счет метамодели языка.
   Примечание.
   Мы привели далеко не полный перечень методов, использовавшихся для описания и моделирования информационных систем. Именно их большое количество послужило побудительной причиной создания унифицированного метода.
Структура UML
   В структуре универсального языка моделирования выделяют две основные составляющие:
   • метамодель;
   • правила построения диаграмм.
   Метамодель представляет собой описание общей структуры языка, основных понятий объектно-ориентированного проектирования (класс, объект, событие, ассоциация, автомат, наследование и пр.), а также методов расширения ядра UML. Описания используемых терминов в общем совпадают с определениями, приводимыми в этой книге, поэтому мы не будем подробно на них останавливаться.
   Примечание.
   Описание метамодели приводится на естественном человеческом языке с применением конструкций самого языка UML, что однако не создает трудностей при ее изучении.
   Наличие метамодели придает языку UML строгость и выгодно отличает его от других методик.
   Основной интерес для проектировщика представляют правила построения UML-диаграмм, основными разновидностями которых являются диаграммы:
   Qпрецедентов, или вариантов использования (use case diagram);
   Qклассов (class diagram);
   Qсостояний (statechart diagram);
   Qактивности, или деятельности (activity diagram);
   • взаимодействия (interaction diagrams), к которым относятся диаграммы последовательности (sequence diagram) и кооперации, или сотрудничества (collaboration diagram);
   • компонентов (component diagram);
   • развертывания (deployment diagram).
   Именно диаграммы в нотации UML служат удобным средством передачи информации об особенностях построения информационной системы между участниками проекта. Часто задание на проектирование рядовому программисту представляется именно в виде набора UML-диаграмм.
   Примечание.
   Юридически к категории программы для ЭВМ относится не только код на каком-либо языке программирования и исполняемый машинный код, но и все материалы, полученные в ходе разработки программ, в первую очередь это касается документированных решений, применяемых при проектировании системы и написанных как на естественном человеческом языке, так и на языке UML. Это еще один аргумент в пользу активного использования UML при разработках информационных систем, так как в случае возникновения спора UML-диаграммы могут стать удобными доказательствами необходимого по закону признака оригинальности программы для ЭВМ.
   При проектировании информационной системы, как правило, составляется множество диаграмм одного и того же вида: множество диаграмм прецедентов, несколько диаграмм классов, множество диаграмм активности.
   Не обязательно всегда составлять все диаграммы. Язык UML создан для облегчения процесса разработки, а не для утомительного документирования всех шагов разработки. Некоторые из диаграмм могут отсутствовать.
   Последовательность построения диаграмм также свободна.
   Среди всех диаграмм следует выделить диаграмму классов, так как на ее основе возможна автоматическая генерация части программного кода будущей информационной системы с описаниями классов и объектов (предварительное объявление в разделе типов и переменных), а также заголовки методов объектов, реализацию которых необходимо писать вручную. То же можно сказать в отношении диаграмм последовательности и кооперации, которые являются взаимно обратимыми, то есть их можно автоматически преобразовать друг в друга. Такие возможности предоставляют системы автоматизированного проектирования, наиболее удачной и известной из которых является системы Rational Rose фирмы Rational Software.
   Примечание.
   При построении UML-диаграмм общепринято использование языка объектных ограничений (Object Constraint Language, ОСL), разработанного фирмой IBM. Язык OCL похож на SQL, но создан специально для навигации и получения данных от объектов. Ввиду ограниченности объема книги мы его рассматривать не будем.
   Диаграмма прецедентов.
   Диаграмма прецедентов служит для выявления и формального представления требований заказчика к проектируемой системе, то есть она описывает, какие возможности будет представлять система конечному пользователю, какая информация необходима для обработки запроса пользователя. При этом механизм функционирования системы от пользователя скрыт и на диаграмме прецедентов не показывается.
   Конечный пользователь, в роли которого может выступать человек (например, покупатель или оператор) или техническое устройство (например, мобильный телефон), изображается в виде стилизованной фигурки человека (рис. 3.1).
   Рис. 3.1. Графическое изображение конечного пользователя.

   Если же в качестве пользователя выступает сама система, что возможно, например, при предоставлении каких-либо функций определенному классу, вместо пользователя рекомендуется применять соответствующее обозначение класса.
   Пользователь задействует систему определенным образом. Соответствующий прецедент (вариант использования) обозначается на диаграмме овалом, внутри которого пишется наименование варианта использования (рис. 3.2).
   Рис. 3.2. Графическое изображение прецедента.

   Для пояснения содержания диаграмм используют примечания, обозначаемые на диаграммах в виде листа бумаги с загнутым углом (рис. 3.3).
   Рис. 3.3. Графическое изображение примечания.

   Текст примечания записывается внутри этого листа. Примечание соединяется пунктирной линией с тем элементом диаграммы, к которому оно относится.
   Примечание.
   Используемые на диаграммах обозначения являются общими для всех видов диаграмм.
   Еще одним наиболее часто используемым на диаграммах прецедентов элементом является интерфейс.
   Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Интерфейс описывает поведение класса или компонента, видимое извне. Интерфейс определяет только описание (спецификации) операций класса или компонента, но он никогда не определяет физические реализации операций.
   Интерфейс представляет собой сущность, которая дает пользователю возможность совершить определенное действие, получить информацию. Пользователю интерфейс может быть доступен в качестве датчика, обращения к базе данных, кнопки, бланка заявления – то есть устройства или операции. Графически интерфейс обозначается небольшим кружком, рядом с которым указывается его наименование (рис. 3.4).
   Рис. 3.4. Графическое изображение интерфейса.

   В нотации UML английские имена интерфейсов принято начинать с буквы I.
   Примечание.
   Относительно имен компонентов диаграмм разработчиками программного обеспечения выработана рекомендация: изначально, при построении основ системы использовать имена компонентов на русском языке, что делает разработку более понятной. В дальнейшем постепенно, а к завершению разработки полностью, заменить названия английскими, которые могут быть восприняты компиляторами.
   Между компонентами диаграммы прецедентов могут существовать различные отношения. Отношения могут быть между пользователями и прецедентами, между несколькими пользователями. Пользователь может взаимодействовать с несколькими прецедентами.
   Ниже перечислены определенные в нотации UML виды отношений между компонентами на диаграммах прецедентов.
   • Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом (рис. 3.5, а).
   • Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать. Графически обозначается пунктирной стрелкой с пометкой «extend» от дополняющего прецедента к расширяемому. Случай, изображенный на рис. 3.5, б, говорит, что при определенных условиях прецедент B может быть дополнен прецедентом A. На практике это может означать, например, дополнительные (помимо обычных) меры к идентификации личности человека.
   • Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически обозначается непрерывной стрелкой от общего к частному (рис. 3.5, в).
   • Отношение включения (include relationship) указывает на включение прецедента в другой прецедент в качестве его составной части. Один и тот же прецедент может быть включен в несколько более крупных прецедентов. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому с пометкой «include» (рис. 3.5, г).
   Рис. 3.5. Графическое изображение отношений на диаграммах прецедентов.

   Цифры над стрелкой (см. рис. 3.5, а) обозначают кратность (multiplicity) отношения и показывают количество возможных компонентов данного отношения. Случай на рисунке означает, что один и тот же пользователь может задействовать систему данным образом любое количество (обозначается «звездочкой») раз.
   Проиллюстрируем изложенное на примере действий дежурного врача при поступлении пациента в больницу через приемный покой. Дежурный врач организует прием пациента, что подразумевает оформление истории болезни, проведение анализов, первичный осмотр, оповещает родственников пострадавшего. В случае тяжелого состояния пациента он направляется в реанимацию. Если состояние пациента безнадежно, от родственников испрашивается согласие на трансплантацию органов. Разрабатываемая информационная система должна автоматизировать выдачу направлений на анализы, предоставляя пакет документов для оформления согласия родственников. Истории болезни в организации ведутся в бумажной форме (результаты анализов в историю болезни вклеиваются). На рис. 3.6 представлен возможный вариант диаграммы прецедентов для данного случая.
   Рис. 3.6. Прием пациента в больницу.

   Диаграмма прецедентов в таком виде наглядно представляет первичные требования заказчика – в данном случае медицинского учреждения. Совокупность таких диаграмм в идеале должна полностью описывать требования к функциональности системы. На практике требования могут изменяться. Графическое представление требований к системе значительно сокращает сроки их согласования между заказчиком и разработчиками.
   Примечание.
   На диаграммах прецедентов не указывается, в какой последовательности выполняются операции. Данная информация может содержаться на диаграммах активности, взаимодействия и состояний.
   Пакеты.
   Для сложных систем возникает необходимость разбиения их на несколько составляющих, причем таким образом, чтобы это разбиение отражалось в обозначении компонентов. Для этих целей в языке UML служат пакеты (рис. 3.7).
   Рис. 3.7. Графическое изображение пакета.

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

   Диаграмма классов.
   Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.
   Графически в самом общем виде класс представляется в виде прямоугольника с четырьмя секциями (на рис. 3.8, а показан формат, на рис. 3.8, б – пример). Любая из секций, кроме секции имени класса, может отсутствовать. В этом случае она не изображается либо оставляется пустой. Как правило, на начальном этапе проектирования разработчик располагает только общими представлениями о будущей структуре системы. В дальнейшем, по мере разработки, уточняются роли, свойства каждого класса, что находит отражение на соответствующих диаграммах классов.
   Абстрактным классом называется класс, который не имеет экземпляров. Абстрактные классы весьма удобно использовать при конструировании иерархии в качестве промежуточных классов. Все, что касается абстрактных классов, в языке UML выделяется курсивом (в нотации Буча абстрактный класс помечается буквой A в треугольнике, обращенном вершиной вниз).
   Рис. 3.8. Графическое изображение класса.

   Имя класса в языке UML принято писать полужирным шрифтом в самой верхней секции графического изображения класса (имя абстрактного класса – полужирным шрифтом и курсивом). Здесь же указывается информация об отношениях этого класса к абстрактным классам, от которых он образован, а также служебная информация о процессе проектирования класса (лицо, ответственное за проектирование класса, язык реализации, номер версии и т. д.).
   Свойства класса определяют состояние экземпляров класса (объектов). В общем виде формат записи свойства можно представить в виде строки:
   видимость имя_свойства [кратность]: тип_свойства = значение_по_умолчанию
   Ниже перечислены аргументы этой строки.
   • видимость – видимость свойства для других классов. Допустимые значения:
   – public (или знак +) – свойство класса доступно любому другому классу;
   – protected (или знак #) – свойство класса доступно только экземплярам этого класса и потомкам данного класса;
   – private (или знак —) – свойство класса доступно только экземплярам этого класса.
   Отсутствие указания на категорию доступа означает, что видимость не указывается.
   Примечание.
   Как уже отмечалось, диаграмма классов может использоваться для автоматической генерации программного кода на выбранном языке программирования. Следует иметь в виду, что в разных языках значения видимости свойства (атрибута), задаваемые по умолчанию, разные.
   • тип_свойства – тип свойства. Этот тип выбирается, исходя из языка реализации проекта (С++, Delphi, Java и других).
   • кратность – диапазон принимаемых свойством значений с учетом типа. Так, если в качестве кратности свойства имя_клиента указан диапазон 1..5 и тип String, то это свойство может принимать, например, следующие значения: Иван Петров, Уильям Джефферсон Клинтон, Мехти Асадулла оглы Мамедов, то есть значения, содержащие не более 5 слов. Если же в качестве кратности свойства доход указан диапазон 0..* и тип Currency, значение этого свойства может принимать любое положительное значение в денежном формате.
   • значение_по_умолчанию – начальное значение свойства, которое в последующем можно изменить программно. Если в строке определения свойства вместо одного знака равенства (=) указать два (==), то значение по умолчанию программно изменить будет нельзя.
   Например, следующая запись для свойства класса Менеджер означает, что по умолчанию всем сотрудникам, замещающим эту должность, первоначально устанавливается заработная плата 700 долларов.
   Заработная плата [0..*]: Currency = 700 $
   Примечание.
   Язык UML помимо проектирования информационных систем нашел применение в сфере аналитики бизнеса. Отображенная на диаграммах структура фирмы и ее деятельности позволяет выявить, например, перегруженность определенных отделов, участки, тормозящие принятие управленческих решений. На основе полученных данных вырабатываются рекомендации по совершенствованию деятельности организаций. UML-диаграммы в этом случае служат инструментом анализа и иллюстрациями сделанных выводов.
   Методы класса служат для обработки свойств класса и характеризуют поведение экземпляров класса.
   Формат записи метода выглядит так:
   видимость имя_метода (список параметров): тип_значения {строка-свойство}
   Ниже перечислены аргументы этой строки.
   • видимость – этот аргумент определяется аналогично видимости свойств.
   • имя_метода – идентификатор метода.
   • список параметров – перечень разделенных запятой формальных параметров.
   Наличие круглых скобок обязательно. Каждый из формальных параметров может быть представлен в следующем виде:
   вид_параметра имя_параметра: тип_параметра = значение_по_умолчанию
   Здесь:
   – вид_параметра – входной (передаваемый методу), выходной (возвращаемый методом) или универсальный (значение параметра может изменяться методом) параметр (обозначается соответственно in, out или inout);
   – тип_параметра – тип параметра, определяемый языком реализации класса.
   • тип_значения – тип значения. Определяется языком реализации класса.
   • строка-свойство – значения свойств, которые могут относиться к данному параметру. Метод, не изменяющий состояние объекта, обозначается строкой-свойством {query}. Строка-свойство {concurrency = sequential} указывает на необходимость обращения к методу во время вызова другого метода, строка-свойство {concurrency = concurrent} – на возможность параллельного вызова методов. Строка-свойство {concurrency = guarded} обращает внимание на необходимость принятия дополнительных мер по контролю исключительных ситуаций.
   • Имя и тип метода с областью действия на весь класс подчеркивается. Например, изменение фона одного окна программы автоматически изменяет цвет фона всех окон системы, как это имеет место при щелчке правой кнопкой мыши на свободном участке рабочего стола и изменении вида окон Windows на вкладке Оформление окна Свойства: Экран. По умолчанию областью действия метода определяется экземпляр класса (объект). В данном случае изменение цвета фона окна (формы) затронет только это окно.
   • Абстрактные методы, то есть методы, не задействованные в данном классе, выделяются курсивом или помечаются строкой-свойством {abstract}.
   Примером обозначения метода «открыть» класса File служить запись:
   + open ()
   Этот метод не возвращает никакого результата своего выполнения.
   Следующая запись может означать, что результатом вызова метода является автоматическая генерация приказа по организации, в котором сотруднику предоставляется ежегодный оплачиваемый отпуск.
   издать приказ (сотрудник): приказ по форме 1-А {"отпуск"}
   В нотации UML между компонентами диаграммы классов могут существовать различные отношения.
   • Отношение зависимости (dependency relationship) указывает на общую взаимосвязь компонентов диаграммы. Графически эта связь изображается пунктирной стрелкой от зависимого класса к независимому (рис. 3.9).
   Рис. 3.9. Графическое изображение отношения зависимости.

   Ключевое слово (стереотип) над стрелкой означает, что свойства класса Кредит, в частности сумма кредита, выдаваемая банком заемщику, может быть определена, исходя из характеристик заемщика (свойств класса Клиент): ежемесячного дохода, возраста и других. Ключевое слово является необязательным элементом. Помимо значения «derive», оно может принимать следующие значения:
   – «access» – указывает на доступность свойств и методов независимого класса для зависимого;
   – «import» – открытые свойства и методы независимого класса (источника) становятся частью зависимого класса, как если бы они были объявлены непосредственно в нем;
   – «bind» – класс может использовать другой класс в качестве шаблона;
   – «refine» – зависимый класс уточняет класс-источник в силу исторических причин.
   • Отношение ассоциации (association relationship) устанавливает некоторую связь между классами системы. Графически это отношение обозначается сплошной линией между классами (рис. 3.10).
   Рис. 3.10. Графическое изображение отношения ассоциации.

   Пример на рисунке означает, что клиент делает покупки. При этом любой покупатель может купить любой товар или не купить никакой, и любой товар может быть продан любому покупателю или не быть купленным никем.
   Отношение ассоциации может связывать большее количество классов (N-арная ассоциация). На диаграмме классов такая ассоциация изображается ромбом (рис. 3.11).
   Рис. 3.11. N-арная ассоциация.

   Приведенная ассоциация указывает, что покупатель может приобрести товар у любого из десяти поставщиков, входящих в данную систему продаж.
   Частными случаями отношений ассоциации являются исключающая ассоциация, агрегация и композиция:
   – исключающая ассоциация (xor-association) указывает на возможность связи определенного класса только с одним из нескольких классов (рис. 3.12);
   – отношение агрегации означает включение нескольких классов в другой класс (графически отношение агрегации показано на рис. 3.13 и означает, что в состав класса Сервиз в качестве самостоятельных единиц могут входить тарелки и другие столовые приборы);
   Примечание.
   Не все языки программирования поддерживают такие конструкции.
   Рис. 3.12. Графическое изображение исключающей ассоциации.

   Рис. 3.13. Графическое изображение отношения агрегации.

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

   • Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически это отношение обозначается непрерывной стрелкой от частного к общему (рис. 3.15). Отношениями обобщения иллюстрируется наследование классов.
   Рис. 3.15. Графическое изображение отношения обобщения.

   В приведенном примере класс Рыбные консервы наследует свойства и методы более общего класса Товар. Язык UML является средством документирования и иллюстрирования удачных идей и решений в области проектирования информационных систем. Так, диаграмма, представленная на рис. 3.16, выражает идею множественного наследования, реализованную в некоторых языках программирования.
   Рис. 3.16. Множественное наследование.

   Классы Рыбные консервы и Тушенка наследуют свойства и методы более общих классов Товар и Консервы, в то же время они наследуют соответственно свойства и методы классов Рыба и Мясо (последние принято называть «примесными классами»). Такое решение может значительно упростить процесс разработки информационной системы, сделать ее более устойчивой к вносимым изменениям за счет сокращения избыточности и локализации общих структур.
   Примечание.
   Множественное наследование классов реализовано далеко не во всех языках программирования. В языке С++ наследование поддерживается, в языке Object Pascal – нет. Отказ от поддержания множественного наследования обусловлен возможностью возникновения ситуации, когда два или несколько классов, имея единого предка, по-разному реализуют одноименный метод, поэтому при множественном наследовании возникнет проблема выбора той или иной реализации метода (рис. 3.17), которую придется разрешать «вручную» (как это делается в С++).
   Рис. 3.17. Проблема множественного наследования классов.

   • Отношение обобщения может содержать поясняющий его идентификатор:
   – {complete} – на диаграмме показаны все классы-потомки;
   – {incomplete} – на диаграмме указаны не все классы-потомки;
   – {disjoint} – множественное наследование не допускается;
   – {overlapping} – множественное наследование допускается.
   Помимо классов на диаграммах классов могут присутствовать интерфейсы, объекты (экземпляры классов) и параметризированные классы (метаклассы, шаблоны).
   Интерфейс на диаграмме классов показывается прямоугольником с двумя секциями (рис. 3.18, а). В первой записывается имя интерфейса, ключевое слово «interface» и служебная информация. Вторая секция предназначена для записи методов интерфейса.
   Рис. 3.18. Графическое изображение интерфейса и объекта на диаграмме классов.

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

   В примере на рис. 3.19, б метакласс может служить основой для создания классов Счет в рублях, Счет в долларах США, Счет в евро или Мультивалютный счет.

   Диаграмма состояний.
   В процессе функционирования информационной системы свойства объектов системы будут принимать различные значения, а объекты системы – различные состояния. Состояния объектов, переходы объектов из одного состояния в другое, сообщения, которыми обмениваются объекты, составляют динамическую составляющую информационной системы.
   Для моделирования динамики информационной системы служат диаграммы состояний, деятельности, последовательности и кооперации, каждая из которых показывает будущую систему в своем ракурсе.
   Диаграмма состояний описывает процесс изменения одного класса, а точнее – одного экземпляра класса. На диаграмме отражаются состояния и переходы между состояниями объекта под воздействием внешних факторов.
   Состояния (states) на диаграмме состояний показываются прямоугольниками с закругленными вершинами. В каждом таком прямоугольнике может быть одна (обязательная) секция, в которой записывается имя состояния (для имени рекомендуется использовать глаголы, причастия и деепричастия), и несколько других секций, обозначающих действия объекта в этом состоянии.
   Начальное состояние изображается черным кружком, конечное – черным кружком в белом кольце. На диаграмме, показанной на рис. 3.20, объект из начального состояния переходит в некоторое другое состояние, в котором выполняется действие 1, а затем – в конечное состояние.
   Рис. 3.20. Простейшая диаграмма состояний.

   Начальное и конечное состояния могут отсутствовать. Примером отсутствия конечного состояния может служить система, которая запускается один раз, а дальше функционирует в непрерывном режиме. Примером отсутствия начального состояния может служить функционирующая система, неизвестно когда возникшая. Примером отсутствия как конечного, так и начального состояний могут служить циклические изменения какого-либо объекта.
   Внутренние действия состояния описываются в следующем формате:
   метка / действие
   Здесь аргумент метка представляет собой одно из следующих ключевых слов:
   • entry – действие выполняется в момент перехода объекта в данное состояние;
   • exit – действие выполняется в момент выхода объекта из данного состояния;
   • do – действие выполняется во время нахождения объекта в данном состоянии;
   • include – обращение к подсостоянию (substate) данного состояния объекта.
   Составное состояние (composite state), или суперсостояние, – это такое состояние объекта, которое включает в себя несколько подсостояний. Использование подсостояний удобно, например, когда на диаграмме требуется показать состояния объекта в зависимости от одного из его свойств. При этом другие свойства объекта также могут изменяться, и если такие состояния и переходы между ними показывать в качестве самостоятельных состояний, то диаграмма будет перегружена обозначениями, затрудняющими восприятие смысла диаграммы – демонстрации переходов между состояниями в зависимости от конкретного свойства. Два варианта графического изображения составного состояния показаны на рис. 3.21.
   Рис. 3.21. Графическое изображение составного состояния.

   Частными случаями составного состояния являются последовательные состояния (на рис. 3.22 это состояния А, Б, В) и параллельные состояния (на рис. 3.22 это состояние Г по отношению к последовательности состояний А, Б, В).
   Рис. 3.22. Графическое изображение составного состояния.

   Историческое состояние (history state) – это такое составное состояние, последующие переходы в которое означают переход к последнему подсостоянию объекта. В качестве примера можно привести систему ведения журнал сбоев (рис. 3.23). При втором и последующем обращении к этому состоянию нет необходимости еще раз создавать журнал сбоев, поэтому переход приведет сразу к подсостоянию Запись в журнал. Историческое состояние обозначается символом H в кружке.
   Рис. 3.23. Графическое изображение исторического состояния.

   Переходы между состояниями в языке UML полагаются мгновенными, то есть на переход из одного состояния объекта в другое время не затрачивается.
   Переходы между состояниями изображаются на диаграммах состояний стрелками, над которыми могут указываться событие (event), вызвавшее этот переход, условие допустимости этого перехода (сторожевое условие) и действия, сопровождающие этот переход, в формате:
   событие(список параметров) [сторожевое условие] выполняемые действия
   События на диаграммах состояний исполняют роль триггеров – переход не произойдет, пока не случится соответствующее событие. Если рядом со стрелкой, обозначающей переход, не указано событие, его специфицирующее, то такой переход называется нетриггерным. Нетриггерный переход происходит сразу после выполнения действий в этом состоянии.
   Сторожевое условие (guard condition) – некоторое логическое выражение, являющееся дополнительным условием перехода. Переход не произойдет, если сторожевое условие принимает значение false, даже в случае наступления соответствующего события. Сторожевые условия удобно использовать, когда из одного состояния при наступлении одного и того же события возможен переход в несколько других состояний. Например, пусть клиент в виртуальном магазине выбрал товары (состояние – выбор) и по окончании послал команду оплатить покупку (событие). Тогда товары доставляются клиенту только в том случае, если на его счету есть достаточная сумма (сработает переход в состояние, в котором выполняется действие доставки), если же необходимая сумма отсутствует, возможны переходы в другие состояния.
   Переходы могут быть простыми и сложными. Простой переход – это переход в другое или в то же состояние объекта. Переход в то же состояние на диаграммах изображается стрелкой, начинающейся и заканчивающейся у этого состояния (рис. 3.24). При каждом переходе такого рода выполняются соответствующие входные и выходные действия.
   Рис. 3.24. Графическое изображение перехода в то же состояние.

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

   Пример перехода между подсостояниями разных состояний показан на рис. 3.26 (переход из A2 в B1).
   Рис. 3.26. Пример перехода между подсостояниями разных состояний.

   В общем случае, переходы на диаграммах состояний принимаются асинхронными, то есть не зависящими от других переходов. Однако при проектировании может возникнуть необходимость показать синхронность переходов между состояниями объекта. Это достигается введением синхронизирующих состояний, обозначаемых символом * внутри окружности. В примере на рис. 3.27 объект не перейдет в подсостояние B, пока не произойдет переход от С к D, который «синхронизирует» переход от A к B.
   Рис. 3.27. Пример использования синхронизирующего состояния.
   Совет.
   Нотация UML представляет широкие возможности для иллюстрирования процесса разработки информационных систем, что видно на примере диаграмм состояний, на которых существует возможность показать составные состояния, сложные переходы и т. д. В то же время злоупотребление сложными конструкциями в конечном итоге приводит только к трудностям в понимании диаграмм – цели, прямо противоположной заявленной нами. Такой же эффект дает перегрузка диаграмм объектами и связями между ними. Отсюда следует общая рекомендация к построению диаграмм: без необходимости не усложняйте диаграммы, не пытайтесь на одной диаграмме показать сразу все аспекты функционирования системы.
   Диаграмма активности.
   Диаграммы активности позволяют показать движения потоков данных в проектируемой системе.
   Диаграммы активности напоминают хорошо знакомые многим алгоритмы, только несколько модифицированные. Пример диаграммы активности показан на рис. 3.28. Диаграмма демонстрирует процесс рассмотрения заявки на получение кредита в некоторой организации.
   Рис. 3.28. Пример диаграммы активности.

   Поясним применяемые обозначения. Начальное и конечное состояния изображаются так же, как на диаграмме состояний. Прямоугольником с округлыми боковыми сторонами изображается действие над данными (состояние действия). Внутри такого прямоугольника указывается производимое действие (это может быть текст, математическое выражение и т. д.).
   Действие может содержать несколько поддействий. Если на диаграмме их показывать нецелесообразно, используют обозначение вложенности действий. Так, в приведенном примере действие Удовлетворение заявки включает в себя несколько поддействий, среди которых могут быть оценка достоверности данных о клиенте, оценка правильности расчетов, непосредственно принятие решения.
   Движение данных (переходы) изображается сплошными стрелками. Возле стрелок может быть указано сторожевое условие. Если движение данных предусматривает ветвление, то указание условия обязательно (в примере на рис. 3.28 оно не показано). Символ ветвления графически изображается ромбом, из которого выходят две или более стрелки. Разделение потока данных и слияние параллельных потоков данных изображается сплошной жирной чертой, связывающей стрелки движения потоков данных.
   Диаграммы активности позволяют показать разделение ответственности различных субъектов за выполнение операций путем введения дорожек (swimlanes). В приведенном примере таких дорожек четыре: Регистратор, Специалист по финансовым рискам, Управляющий, Служба безопасности.
   Передаваемые данные могут быть указаны на диаграммах активности в явном виде. Например, передачу заказа между отделами организации иллюстрирует рис. 3.29. В качестве передаваемых данных может быть указан пользователь, например, при построении карты веб-сайта.
   Вектор времени на диаграммах активности в явном виде не воспроизводится.
   Рис. 3.29. Движение заказа между отделами.

   Диаграмма последовательности.
   Идеология объектно-ориентированного программирования заключается в описании поставленной задачи образами некоторых самостоятельных сущностей (объектов), которые в процессе функционирования системы обмениваются сообщениями. Диаграммы последовательности служат инструментом отображения такого обмена.
   Основными компонентами диаграмм последовательности являются пользователь, объект, линия жизни объекта (object lifeline), сообщение (message) и фокус управления (focus of control). Объект графически изображается, как и на других UML-диаграммах, прямоугольником с подчеркнутым именем, линия жизни объекта – вертикальной пунктирной линией, сообщение – горизонтальной стрелкой, фокус управления – прямоугольником на линии жизни объекта.
   Примеры диаграмм последовательности приведены на рис. 3.30. На рис. 3.30, а пользователь создает объект, который через некоторое время уничтожается (символ уничтожения объекта – жирный крест). Рис. 3.30, б наглядно демонстрирует идею и параметры замера температурно-влажностного режима в помещении хранилища музея.
   Рис. 3.30. Примеры диаграмм последовательности.

   Фокус управления показывает, какой именно элемент находится в активном состоянии (действует). Фокус управления может быть одновременно как у одного, так и у нескольких объектов системы. Фокус управления может передаваться от одного объекта другому. На рис. 3.31 приведен пример передачи фокуса управления от объекта А объекту Б или В в зависимости от условия õ = 0 или x > 0, записываемого возле символа ветвления.
   Рис. 3.31. Передача фокуса управления.

   Сообщения на диаграммах последовательности могут быть помечены идентификаторами, поясняющими их смысловую нагрузку (стереотипы):
   • «call» – вызов объектом другого объекта;
   • «return» – возврат значения вызвавшему объекту;
   • «create» – создание объекта;
   • «destroy» – уничтожение объекта, которому передается это сообщение;
   • «send» – посылка асинхронного сигнала.
   Рекурсия (самовызов) объекта на диаграммах последовательности может быть показана как сообщение вызова, обращенное объектом самому себе (рис. 3.32, а), или специальным символом на изображении фокуса управления (рис. 3.32, б).
   Рис. 3.32. Варианты изображения рекурсии.

   Диаграмма сотрудничества.
   Диаграмма сотрудничества, как и диаграмма последовательности, является разновидностью диаграмм взаимодействия. Современные программные средства построения диаграмм обеспечивают автоматическое преобразование диаграмм данных видов друг в друга.
   Если диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия, то диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность-связь.
   Диаграммы сотрудничества бывают двух видов.
   • Диаграммы сотрудничества уровня спецификаций оперируют классами, пользователями, кооперациями и ролями, которые играют пользователи и классы. Пример диаграммы сотрудничества уровня спецификаций приведен на рис. 3.33. Окружность – это кооперация, пунктирная линия – роль пользователя в кооперации, стрелка– отношение обобщения, общее для всех UML-диаграмм. Кооперация определяет взаимодействие классов. Участвуя в кооперации, классы совместно производят некоторый кооперативный результат.
   Рис. 3.33. Пример диаграммы сотрудничества уровня спецификаций.

   • Диаграммы сотрудничества уровня примеров оперируют экземплярами классов (объектами), связями между ними и сообщениями, которыми обмениваются объекты.
   Объекты на диаграммах сотрудничества обозначаются так же, как и на других UML-диаграммах – прямоугольниками. Однако на диаграммах данного вида имя объекта может дополняться его ролью в сотрудничестве. На рис. 3.34, а показан образец, на рис. 3.34, б – пример обозначения имени объекта, любая из трех частей которого может отсутствовать.
   Рис. 3.34. Графическое изображение объектов на диаграммах сотрудничества.

   Объекты, которые могут управлять другими объектами, называются активными (active object) и помечаются словом {active}.
   Для обозначения группы объектов, которым адресован один и тот же сигнал, вводится понятие мультиобъекта, изображаемого графически двумя прямоугольниками, наложенными друг на друга (рис. 3.35).
   Рис. 3.35. Графическое изображение мультиобъекта.

   В отличие от мультиобъекта составной объект действительно состоит из других объектов (рис. 3.36).
   Рис. 3.36. Графическое изображение составного объекта.

   Между объектами диаграммы сотрудничества существуют связи (links), по которым объекты посылают друг другу сообщения. Связи не имеют названий (в терминах UML они являются анонимными), но могут быть специфицированы ключевыми словами (стереотипами):
   • «association» – связь означает некую зависимость объектов;
   • «parameter» – объект полагается параметром метода;
   • «Local» – локальная переменная метода, область видимости которой ограничена соседним объектом;
   • «global» – глобальная переменная, область видимости которой ограничена диаграммой сотрудничества;
   • «self» – связь объекта с самим собой.

   Приведенные стереотипы требуют пояснения. Связь между объектами в информационной системе на уровне программирования на определенном языке осуществляется посредством передачи параметров (переменных) от одного объекта другому объекту. Например, объект Отдел продаж передает объекту Склад некоторый принятый в организации документ (переменную), в котором сообщает о необходимости выделения продукции той или иной номенклатуры. Значение передаваемых параметров является содержанием передаваемого посредством связи сообщения.
   Сообщения на диаграммах сотрудничества изображаются стрелками вдоль связей. Порядок передачи сообщений может быть определен явным указанием номера сообщения возле стрелки. Вид сообщения несет дополнительную смысловую нагрузку в виде определения ролей взаимодействующих объектов. В зависимости от этого сообщения графически изображаются:
   • сплошной линией с треугольной стрелкой – такое сообщение означает вызов процедуры (метода объекта) или вызов другого потока управления (рис. 3.37, а);
   • сплошной линией с обычной стрелкой – такое сообщение означает простой поток управления, то есть просто передачу данных (рис. 3.37, б);
   • сплошной линией с полустрелкой – такое сообщение не имеет заранее обусловленного времени передачи, являясь, как правило, асинхронным (рис. 3.37, в);
   • пунктирной линией с обычной стрелкой – такое сообщение означает возврат значения из процедуры (рис. 3.37, г).
   Рис. 3.37. Графическое изображение сообщений на диаграммах сотрудничества.

   Сообщение записывается в определенном формате. Например, показанная ниже запись означает, что данное сообщение будет передано только после сообщений с номерами 1 и 2 (предшествующие сообщения), при условии истинности введенного пароля (сторожевое условие). В потоке последовательных сообщений оно будет занимать место между сообщениями 3.1 и 3.3, при этом возможна параллельная передача сообщения с другими сообщениями, имеющими номер 3.2. Само сообщение вызывает метод нахождения сведений о человеке по фамилии, имени и отчеству (список аргументов), предполагая предоставление карточки по форме 1А на запрашиваемое лицо (возвращаемое значение):
   1, 2 / [пароль] 3.2 Форма_1А:= найти_сведения (Фамилия, Имя, Отчество)
   В заключение приведем пример диаграммы сотрудничества. На рис. 3.38 показана диаграмма, иллюстрирующая отношения по расчетам чеками, широко используемые в хозяйственной деятельности предприятий (см. параграф 5 в главе 46 Гражданского кодекса Российской Федерации).
   Рис. 3.38. Расчеты чеками.
   Примечание.
   Приведенный пример значительно упрощен. В частности, не показаны действия в случае неоплаты чека, опущены параметры сообщений.
   Диаграмма компонентов.
   Информационные системы на уровне программного кода могут состоять из множества приложений, справочных файлов, исходных текстов, веб-документов, динамических библиотек. То, как именно будут распределены классы и их экземпляры по файлам, а также взаимосвязи между файлами позволяют отобразить диаграммы компонентов.
   Примечание.
   Диаграммы компонентов играют существенную роль при оптимизации быстродействия системы. С их помощью выявляются наиболее часто используемые компоненты, определяется их оптимальное распределение по модулям. На завершающих стадиях разработки информационной системы может возникнуть ситуация, когда незначительные изменения в реализации одного из компонентов потребуют перекомпиляции всех компонентов, созданных на его основе. В этом случае пренебрежительное отношение к диаграммам данного вида может существенно сказаться на сроках сдачи проекта. Особенно это касается приложений с числом модулей от тысячи и выше.
   Основным элементом диаграмм компонентов является компонент (component), который графически изображается прямоугольником со встроенными слева прямоугольными секциями. Внутри прямоугольника указывается имя компонента, которым может быть имя исполняемого файла, базы данных и т. д., а также служебная информация: версия, язык реализации, разработчик (рис. 3.39).
   Рис. 3.39. Графическое изображение компонента.

   Иногда перед именем компонента указывается его спецификация:
   • library – библиотека;
   • table – база данных, отдельная таблица;
   • file – исходный текст программ;
   • document – документ;
   • executable – исполняемый файл.
   Для ряда компонентов приняты специальные обозначения. К таким компонентам относятся динамические библиотеки (рис. 3.40, а), справочные файлы (рис. 3.40, б), исходные тексты программ (рис. 3.40, в), веб-документы (рис. 3.40, г). Эти обозначения вместе с обозначениями исполняемых модулей иногда называют артефактами.
   Рис. 3.40. Графическое изображение артефактов.

   Между компонентами и другими элементами диаграммы компонентов существуют отношения зависимости (рис. 3.41), показывающие, что один компонент зависит от другого и при его изменении тоже должен меняться, а также отношения реализации, изображаемые сплошной линией (3.42, а), либо указанием на соответствующие элементы внутри обозначения компонента (3.42, б).
   Рис. 3.41. Графическое изображение отношения зависимости.

   Рис. 3.42. Графическое изображение отношений реализации.

   Диаграмма развертывания.
   Диаграммы развертывания служат для иллюстрации физического размещения информационной системы на серверах, компьютерах пользователей, искусственных спутниках земли, поездах, морских судах, внутри ЭВМ, отображения физических каналов передачи информации между компонентами информационной системы.
   Основным обозначением, используемым на диаграммах данного вида, является узел (node), который графически изображается аксонометрической проекцией куба (рис. 3.43). Внутри обозначения узла указывается его имя (например, Сервер) и развертываемые на нем компоненты, изображаемые так же, как на диаграмме компонентов.
   Рис. 3.43. Графическое изображение узла.

   Между узлами сплошными линиями показывают соединения, которые могут содержать пояснения относительно характера реализации связи между компонентами (рис. 3.44).
   Рис. 3.44. Графическое изображение соединения.

Глава 4
Реляционные базы данных

   По мере развития вычислительной техники изменялись основные направления ее использования. Первоначально средства вычислительной техники предназначались для разного рода математических вычислений, которые невозможно было выполнить «вручную» за разумное время. Развитие этого направления привело к появлению разделов математики, связанных с численными методами вычислений, и алгоритмических языков, удобных для реализации алгоритмов численных методов и ориентированных на выполнение математических расчетов (одним из наиболее популярных языков программирования такого типа является Fortran, до сих пор широко применяющийся для научных расчетов).
   Затем, по мере расширения возможностей и снижения стоимости вычислительных средств, получило развитие второе направление, связанное с использованием средств вычислительной техники в автоматизированных информационных системах. Здесь вычислительные возможности компьютеров отходят на второй план – основные функции вычислительных средств в информационных системах направлены на надежное хранение информации, выполнение специфических для данного приложения преобразований информации и/или вычислений, предоставление пользователям удобного и легко осваиваемого интерфейса.
   Примечание.
   Несмотря на то, что сложность вычислений, выполняемых в информационных системах, несоизмеримо ниже, чем при проведении научных расчетов, требования к вычислительной мощности компьютеров в таких системах выше. Это связано с тем, что объемы обрабатываемой информации, как правило, достаточно велики, а сама информация имеет сложную структуру. Этим же объясняется существенное возрастание требований к объему оперативной памяти и устройств постоянного хранения информации.
   Со временем именно второе направление, связанное с хранением и обработкой данных, стало доминирующим, особенно после появления персональных компьютеров. Использование персональных компьютеров для выполнения сложных научных расчетов сейчас является скорее исключением. Интересно также отметить, что современные персональные компьютеры, оборудованные процессорами с громадными тактовыми частотами (на сегодняшний день рядовой дешевый процессор работает на частоте 1400–1500 МГц) при решении сложных научных задач могут даже уступать по вычислительным возможностям «большим» компьютерам 15-20-летней давности.

Общие сведения о базах данных

   Развитие компьютерных технологий, связанных с хранением и обработкой данных, привело к появлению в конце 60-х – начале 70-х годов специализированного программного обеспечения, получившего название систем управления базами данных, или СУБД (DataBase Management Systems, DBMS). СУБД позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Именно системы управления базами данных являются основой практически любой информационной системы.
   СУБД можно определить как некую систему управления данными, обладающую следующими свойствами:
   • поддержание логически согласованного набора файлов;
   • предоставление языка манипулирования данными;
   • восстановление информации после разного рода сбоев;
   • обеспечение параллельной работы нескольких пользователей.

Основные функции систем управления базами данных

   К основным функциям, выполняемым системами управления базами данных, обычно относят:
   • непосредственное управление данными во внешней памяти;
   • управление буферами оперативной памяти;
   • управление транзакциями;
   • протоколирование;
   • поддержка языков баз данных.
   Рассмотрим каждую из указанных функций более подробно.
Непосредственное управление данными во внешней памяти
   Функция непосредственного управления данными во внешней памяти включает предоставление необходимых структур внешней памяти (постоянных запоминающих устройств, как правило, магнитных дисков) как для хранения данных, непосредственно входящих в базу данных, так и для служебных целей, например, для ускорения доступа к данным в некоторых случаях (обычно для этого используются индексы). Причем пользователям базы данных в общем случае не нужно знать, применяет ли СУБД файловую систему, а если применяет, как организованы файлы. Обычно СУБД поддерживает собственную систему именования объектов базы данных. В зависимости от способа реализации СУБД может либо использовать возможности существующих файловых систем, либо работать с устройствами внешней памяти на низком уровне.
Управление буферами оперативной памяти
   Объем информации, хранящейся в базе данных, с которой работает СУБД, обычно достаточно велик и практически всегда превышает доступный объем оперативной памяти. При этом время доступа к данным, хранящимся в оперативной памяти, существенно меньше, чем к данным, хранящимся на устройствах внешней памяти. Очевидно, что если при обращении к любому элементу данных требуется обмен с внешней памятью, то вся система будет работать со скоростью функционирования устройства внешней памяти.
   Повышения скорости обмена данными можно достичь, используя буферизацию данных в оперативной памяти. При этом даже если операционная система выполняет общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, у которой гораздо больше информации, позволяющей судить о полезности буферизации той или иной части базы данных. Поэтому в СУБД обычно поддерживается собственный набор буферов оперативной памяти с собственным механизмом замены буферов.
   Примечание.
   Следует отметить, что существует направление развития СУБД, ориентированное на постоянное присутствие в оперативной памяти всей информации из базы данных. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что буферизация станет лишней.
Управление транзакциями
   Транзакцией называется последовательность операций над базой данных, рассматриваемых СУБД как единое целое. Если все операции успешно выполнены, то транзакция также считается успешно выполненной, и СУБД фиксирует (commit) все изменения данных, произведенные этой транзакцией (то есть заносит изменения во внешнюю память). Если же хотя бы одна операция транзакции заканчивается неудачей, то транзакция считается невыполненной, и производится ее откат (rollback) с отменой всех изменений данных, произведенных в ходе выполнения транзакции, и возвращением базы данных к состоянию до начала выполнения транзакции.
   Управление транзакциями необходимо для поддержания логической целостности базы данных.
   Поддержка механизма транзакций является обязательным условием работы даже однопользовательских, а тем более многопользовательских СУБД. Поскольку каждая транзакция начинается при целостном состоянии базы данных и оставляет это состояние целостным после своего завершения, понятие транзакции очень удобно использовать как единицу активности пользователя по отношению к базе данных. При должном управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может, в принципе, ощущать себя единственным пользователем СУБД.
   С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации и плана сериализации смеси транзакций. Под сериализаций понимается параллельное выполнение смеси транзакций, результат которого эквивалентен результату их последовательного выполнения. План сериализации смеси транзакций – это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться реальной сериализации смеси транзакций, то для каждого пользователя, по инициативе которого начата транзакция, выполнение других транзакций будет незаметным (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
   Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизированных захватах объектов базы данных. При использовании любого алгоритма сериализации возможны конфликты между несколькими транзакциями по доступу к объектам базы данных. В этом случае для поддержания сериализации необходимо выполнить откат одной или нескольких транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе обработки транзакций других пользователей.
Протоколирование
   Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.
   Аппаратные сбои обычно подразделяются на два вида:
   • мягкие сбои связаны с внезапной остановкой компьютера и обычно являются следствием внезапного выключения питания или «зависания» операционной системы;
   • жесткие сбои характеризуются потерей информации на носителях внешней памяти.
   Программные сбои обычно возникают вследствие ошибок в программах. Причем эти ошибки могут быть как в самой СУБД, что может привести к аварийному завершению ее работы, так и в пользовательской программе. Первый случай можно рассматривать как разновидность мягкого аппаратного сбоя. Во втором случае незавершенной остается только одна транзакция.
   В любом случае, для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для надежного хранения данных требуется их избыточность. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных.
   Журнал представляет собой недоступную пользователям и поддерживаемую с особой тщательностью часть базы данных, в которую поступают записи обо всех изменениях основной части базы данных. Иногда используются две копии журнала, располагаемые на разных физических дисках.
   В разных СУБД изменения базы данных протоколируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда – минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба подхода.
   Во всех случаях придерживаются стратегии упреждающей записи в журнал (Write Ahead Log, WAL). Несколько утрируя, можно сказать, что эта стратегия подразумевает внесение в журнал записи об изменении любого объекта базы данных до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД поддерживается протокол WAL, то с помощью журнала можно решить все проблемы восстановления базы данных после любого сбоя.
   Самая простая ситуация восстановления – откат отдельной транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а откат отдельной транзакции выполняют по общесистемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу).
   При мягком сбое во внешней памяти основной части базы данных могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине очистки буферов оперативной памяти при мягком сбое). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью восстановления после мягкого сбоя является приведение внешней памяти основной части базы данных в такое состояние, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не сохранились во внешней памяти.
   Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия – это полная копия базы данных, полученная к началу заполнения журнала (хотя имеются и другие варианты трактовки этого термина). Естественно, для нормального восстановления базы данных после жесткого сбоя необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что на основе данных архивной копии по журналу повторно выполняются все транзакции, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков баз данных
   Для работы с информацией, хранящейся в базе данных, используются специальные языки, носящие общее название языков баз данных. Чаще всего выделяется два языка:
   • язык определения схем данных (Schema Definition Language, SDL) служит главным образом для определения логической структуры базы данных;
   • язык манипулирования данными (Data Manipulation Language, DML) содержит набор операторов манипулирования данными, то есть операторов, позволяющих заносить данные в базу, а также удалять, модифицировать или выбирать существующие данные.
   Несколько разных специализированных языков баз данных поддерживалось лишь в ранних СУБД. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language – язык структурированных запросов). Таким образом, указанные выше языки баз данных на сегодняшний день фактически являются подмножествами единого стандартного языка SQL.
   Язык SQL позволяет определять схему реляционной базы данных и манипулировать данными. При этом именование объектов базы данных (для реляционной базы данных – именование таблиц и их полей) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.
   Язык SQL содержит специальные средства определения ограничений целостности базы данных. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и контроль целостности базы данных производится на языковом уровне – при компиляции операторов модификации базы данных компилятор SQL на основании имеющихся в базе данных ограничений целостности генерирует соответствующий программный код.
   Специальные операторы языка SQL позволяют определять так называемые представления базы данных, фактически являющиеся хранимыми в базе данных запросами (результатом любого запроса к реляционной базе данных является таблица) с именованными столбцами, называемыми полями. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в базе данных, но с помощью представлений можно ограничить или, наоборот, расширить видимость данных для конкретного пользователя. Поддержка представлений производится также на языковом уровне.
   Наконец, авторизация доступа к объектам базы данных тоже производится на основе специального набора SQL-операторов. Идея состоит в том, что для выполнения разных SQL-операторов пользователь должен обладать разными полномочиями. Пользователь, создавший таблицу базы данных, обладает полным набором полномочий для работы с данной таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
   Примечание.
   Здесь дается лишь общее представление о языке SQL. Более подробно данный язык и его функции рассматриваются далее.

Эволюция систем управления базами данных

   На эволюцию СУБД существенное влияние оказывает бурное развитие микроэлектронных технологий и связанное с этим развитие персональных компьютеров. Темпы развития персональных компьютеров за последние 15–20 лет существенно превышают темпы развития «больших» ЭВМ. Область применения персональных компьютеров за последние несколько лет существенно расширилась. Можно выделить основные причины этой тенденции:
   • цена персональных компьютеров значительно ниже, чем больших ЭВМ;
   • по функциональным возможностям персональные компьютеры превосходят большие ЭВМ;
   • существенно сократился разрыв между производительностью персональных компьютеров и больших ЭВМ, кроме того, для многих задач обработки данных производительность компьютера не является решающим фактором;
   • архитектура систем на основе персональных компьютеров обладает большей гибкостью и мобильностью, а сфера их использования значительно шире области применения больших ЭВМ.
   Общая тенденция движения от отдельных больших вычислительных машин (mainframes) к открытым распределенным системам оказала огромное влияние на развитие архитектур СУБД и поставила перед их разработчиками ряд сложных проблем. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД с собственными моделями, форматами представления данных и языками доступа к данным, к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в сеть компьютеров различных моделей и производителей.
   Постепенный переход от вычислительных систем на основе больших ЭВМ и централизованного управления данными к распределенным системам на основе персональных компьютеров, а также внедрение персональных компьютеров практически во все сферы деятельности, привели и к изменению подходов к организации систем управления базами данных. В истории развития и совершенствования систем управления базами данных можно условно выделить три основных этапа. Кратко рассмотрим каждый из них.
СУБД первого поколения
   Первый этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). В этот период времени на рынке вычислительной техники доминировали большие вычислительные машины, такие как IBM 360/370, которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем. СУБД первого поколения были в подавляющем большинстве закрытыми системами: отсутствовал стандарт внешних интерфейсов, не обеспечивалась переносимость прикладных программ.
   Ранние СУБД, с сегодняшней точки зрения, имели массу недостатков, из которых наиболее существенными были:
   • сложность использования;
   • необходимость знать физическую организацию базы данных;
   • сильная зависимость прикладных систем от физической организации базы данных;
   • перегрузка логики прикладных систем деталями организации доступа к базе данных;
   • отсутствие средств автоматизации проектирования баз данных;
   • очень высокая стоимость.
   Среди достоинств СУБД первого поколения можно отметить:
   • наличие развитых средств управления данными во внешней памяти на низком уровне;
   • возможность построения эффективных прикладных систем вручную;
   • возможность экономии памяти за счет совместного использования объектов (в сетевых системах).
   Несмотря на все свои недостатки, СУБД первого поколения оказались весьма долговечными: разработанное на их основе программное обеспечение используется по сей день, и большие ЭВМ по-прежнему хранят огромные массивы актуальной информации. Главной причиной этого является, вероятно, экономический фактор – в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства, в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат.
Реляционные СУБД
   Началом второго этапа в эволюции СУБД можно считать публикации в начале 70-х годов ряда статей Э. Кодда (Coad), в которых выдвигались, по сути, революционные идеи, существенно изменившие устоявшиеся представления о базах данных.
   Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двухмерных таблиц особого вида, известного в математике как отношение (по-английски – relationship, отсюда и название – реляционные базы данных).
   Одна из главных идей Кодда заключалась в том, что связь между данными должна устанавливаться в соответствии с их внутренними логическими взаимоотношениями.
   Примечание.
   В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае, когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, то для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать обращения к файлам. Естественно, это существенно упрощает работу с базами данных.
   Второй важный принцип, предложенный Коддом, заключается в том, что в реляционных системах одной командой могут обрабатываться целые файлы данных, в то время как в ранних СУБД одной командой обрабатывалась только одна запись. Реализация этого принципа существенно повысила эффективность программирования баз данных.
   Реализация реляционных принципов в СУБД сделала возможным разработку простых языков запросов, вполне доступных пользователям, не являющимся специалистами в области программирования. Таким образом, благодаря снижению требований к квалификации существенно расширился круг пользователей баз данных.
   Примечание.
   На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны QBE (Query by Example – запрос по образцу), Quel (Query Language – язык запросов) и SQL (Structured Query Language – структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение имеет SQL, который в 1986 г. был принят институтом ANSI (American National Standards Institute – Американский национальный институт стандартов) в качестве стандарта языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL-92.
   Сейчас реляционные базы данных получили очень широкое распространение и фактически их можно рассматривать как стандарт СУБД для современных информационных систем.
Объектно-ориентированные СУБД
   Несмотря на большую популярность реляционных СУБД, развитие технологии управления данными на них не остановилось. Следующим этапом этого развития стало появление объектно-ориентированных баз данных, для которых характерны объектно-ориентированный подход, распределенность данных, наличие активного сервера баз данных, языки программирования четвертого поколения, фрагментация и параллельная обработки запросов, технологии тиражирования данных, многопоточная архитектура и другие революционные достижения в области обработки данных.
   Объектно-ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:
   • возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;
   • простота эволюции системы за счет таких элементов объектного подхода как наследование и полиморфизм;
   • возможность объектного моделирования системы, позволяющего проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки.
   Объектная модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов.
   При занесении сложного объекта в реляционную базу обязательна процедура декомпозиции его данных для того, чтобы разместить их в таблицах. При чтении объекта из реляционной базы он собирается из отдельных элементов и только затем может использоваться. В объектных же СУБД данные объекта, а также методы изменения этих данных помещаются в хранилище как единое целое.
   Использование объектной модели представления данных (и, соответственно, объектно-ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.
   Примечание.
   Несмотря на все достоинства объектно-ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае применение реляционной модели может быть более эффективным. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конкретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными объектно-реляционными СУБД.

Реляционная модель данных

   Реляционная модель данных была предложена уже упоминавшимся Э. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 г. в статье «A Relational Model of Data for Large Shared Data Banks» (CACM, 1970, Vol. 13 № 6). Реляционная модель позволила решить одну из важнейших задач в управлении базами данных – обеспечить независимость представления и описания данных от прикладных программ, следствием чего стало бы существенное упрощение проектирования и программирования баз данных. Поэтому после опубликования работ Кодда начались активные исследования по созданию реляционной системы управления базами данных. В результате этих исследований во второй половине 70-х годов был создан ряд коммерческих и некоммерческих реляционных СУБД.
   К основным достоинствам реляционного подхода к управлению базой данных следует отнести:
   • наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;
   • наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;
   • возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
   Несмотря на все свои достоинства, реляционные системы далеко не сразу получили широкое признание. Хотя уже во второй половине 70-х годов появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.
   В настоящее время реляционные СУБД остаются одними из наиболее распространенных, несмотря на некоторые присущие им недостатки. Сейчас основным предметом критики реляционных СУБД является не их недостаточная эффективность, а также некоторая ограниченность таких систем при использовании в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования), в которых требуются предельно сложные структуры данных. Причем эта ограниченность реляционных СУБД является прямым следствием их простоты и проявляется лишь в отдельных предметных областях. Вторым часто отмечаемым недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области – средства представления знаний о семантической специфике предметной области в реляционных системах очень ограничены.
   На устранение именно этих недостатков в основном и направлены исследования по созданию объектно-ориентированных баз данных.

Базовые понятия реляционной модели данных

   Термин «реляционный» указывает, прежде всего, на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей, которые удобно представлять в виде двухмерной таблицы. Как показал Кодд, набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. Таким образом, реляционная модель данных представляет информацию в виде совокупности взаимосвязанных таблиц, которые принято называть отношениями, или реляциями.
   Основными понятиями реляционной модели данных являются:
   • тип данных;
   • домен;
   • атрибут;
   • кортеж;
   • ключ.
   Рассмотрим смысл этих понятий на примере отношения (таблицы) СТУДЕНТЫ, содержащего информацию о студентах некоторого вуза (табл. 4.1).
Таблица 4.1. Пример отношения СТУДЕНТЫ реляционной базы данных
Тип данных
   Понятие типа данных в реляционной модели данных полностью эквивалентно соответствующему понятию в алгоритмических языках. Набор поддерживаемых типов данных определяется СУБД и может значительно различаться в разных системах. Однако практически все СУБД поддерживают следующие типы данных:
   • целочисленные;
   • вещественные;
   • строковые;
   • специализированные типы данных для денежных величин;
   • специальные типы данных для временных величин (дата и/или время);
   • типы двоичных объектов – данный тип не имеет аналога в языках программирования; обычно для его обозначения используется аббревиатура BLOB (Binary Large Object – большой двоичный объект).
   Примечание.
   Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres).
   В рассматриваемом примере (см. табл. 4.1) используются три типа данных: строковый (столбцы Имя и Специальность), временной (столбец Дата_рождения) и целочисленный (Курс и №_студенческсто_билета).
Домен
   Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Доменом называется множество атомарных значений одного и того же типа. Иными словами, домен представляет собой допустимое потенциальное множество значений данного типа.
   В нашем примере для каждого столбца таблицы можно определить домен.
   • Домены Имена и Специальности для столбцов Имя и Специальность соответственно будут базироваться на строковом типе данных – в число их значений могут входить только те строки, которые могут представлять имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака).
   • Домен Даты_рождения для столбца Дата_рождения определяется на базовом временном типе данных – данный домен содержит только допустимый диапазон дат рождения студентов.
   • Домены Номера_курсов и Номера_студенческих_билетов базируются на целочисленном типе – в число их значений могут входить только те целые числа, которые позволяют обозначить номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число).
   Примечание.
   Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с диапазонными типами и множествами в ряде языков программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена.
   Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, если они относятся к одному домену. Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла. В нашем примере значения доменов Номера_курсов и Номера_студенческих_билетов, хотя и основаны на одном типе данных – целочисленном, сравнимыми не являются.
   Примечание.
   Понятие домена характерно далеко не для всех СУБД. В качестве примера реляционных баз данных, использующих это понятие, можно привести Oracle и InterBase.
Атрибуты, схема отношения, схема базы данных
   Столбцы отношения называют атрибутами, им присваиваются имена, по которым к ним затем производится обращение.
   Список имен атрибутов отношения с указанием имен доменов (или типов, если домены не поддерживаются), называется схемой отношения.
   Схема нашего отношения СТУДЕНТ запишется так:
   СТУДЕНТ {№_студенческого_билета Номера_студенческих_билетов
   Имя Имена,
   Дата_рождения Даты_рождения,
   Курс Номера_курсов,
   Специальность Специальности}
   Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, …, степени n – n-арным.
   Степень отношения СТУДЕНТЫ равна пяти, то есть оно является 5-арным.
   Схемой базы данных называется множество именованных схем отношений.
Кортеж
   Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Аргумент значение является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж– это набор именованных значений заданного типа.
   Таким образом, отношение, по сути, является множеством кортежей, соответствующим одной схеме отношения.
   Примечание.
   Схему отношения иногда называют также заголовком отношения, а отношение как набор кортежей – телом отношения.
   Примечание.
   Понятие схемы отношения напоминает понятие структурного типа данных в языках программирования (структура в C/C++, запись в Pascal). Однако в реляционных базах данных имя схемы отношения всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается также изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.
   Кардинальным числом, или мощностью отношения, называется число его кортежей. Мощность отношения СТУДЕНТЫ равна 6. В отличие от степени отношения, кардинальное число отношения изменяется во времени.
Пустые значения
   В некоторых случаях какой-либо атрибут отношения может быть неприменим. Например, в рассматриваемом в качестве примера отношении СТУДЕНТЫ может также храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты №_студенческого_билета и Курс (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому-либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестными и выясняться позже (при поступлении на подготовительные курсы абитуриент может еще не определиться окончательно, на какую специальность он будет поступать).
   В обоих указанных случаях в поля, соответствующие неприменимым или неизвестным атрибутам, ничего не заносится, и строка записывается в базу данных с пустыми значениями этих атрибутов.
   Следует понимать, что пустое значение – это не ноль и не пустая строка, а неизвестное значение атрибута, которое не определено в данный момент времени и, в принципе, может быть определено позднее.
   Примечание.
   Для обозначения пустых значений полей используется слово NULL.
Ключи отношения
   Поскольку отношение с математической точки зрения является множеством, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно заданный момент времени. Таким образом, в отношении всегда должен присутствовать некоторый атрибут (или набор атрибутов), однозначно определяющий каждый кортеж отношения и обеспечивающий уникальность строк таблицы. Такой атрибут (или набор атрибутов) называется первичным ключом отношения.
   Более строго определить понятие первичного ключа можно следующим образом. Если R – отношение с атрибутами A1, A2,…, An, то множество атрибутов K= (Ai, Aj , …, Ak) отношения R является первичным ключом этого отношения тогда и только тогда, когда удовлетворяются два независимых от времени условия:
   • уникальность – в произвольный момент времени никакие два кортежа отношения R не имеют одного и того же значения для Ai, Aj , …, Ak;
   • минимальность – ни один из атрибутов Ai, Aj,…, Ak не может быть исключен из K без нарушения уникальности.
   Для каждого отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако требуется обеспечить также условие минимальности. Поэтому, как правило, в отношении всегда имеется один атрибут, обладающий свойством уникальности и являющийся первичным ключом.
   В зависимости от количества атрибутов, входящих в ключ, различают простые и сложные (или составные) ключи.
   Простой ключ – ключ, содержащий только один атрибут. В общем случае операции объединения выполняются быстрее в том случае, когда в качестве ключа используется самый короткий и самый простой из возможных типов данных. С этой точки зрения наилучшим образом подходит целочисленный тип, который имеет аппаратную поддержку для выполнения над ним логических операций.
   Сложный, или составной, ключ – это ключ, состоящий из нескольких атрибутов.
   Примечание.
   Набор атрибутов, обладающий свойством уникальности, но не обладающий минимальностью, называется суперключом. Суперключ – сложный (составной) ключ с большим числом столбцов, чем необходимо для того, чтобы быть уникальным идентификатором. Такие ключи нередко используются на практике, так как избыточность может оказаться полезной пользователю.
   В зависимости от того, содержит ли атрибут, являющийся первичным ключом, какую-либо информацию, различают искусственные и естественные ключи.
   Искусственный, или суррогатный, ключ – это ключ, созданный самой СУБД или пользователем с помощью некоторой процедуры, но сам по себе не содержащий информации. Искусственный ключ используется для создания уникальных идентификаторов строк, когда сущность должна быть описана полностью, чтобы однозначно идентифицировать конкретный элемент. Искусственный ключ часто задействуют вместо значимого сложного ключа, который является слишком громоздким, чтобы применяться в реальной базе данных. Система поддерживает искусственный ключ, но он никогда не виден пользователю.
   Естественный ключ – это ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию.
   Примечание.
   В рассматриваемом нами примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ является естественным, так как несет вполне определенную информацию.
   Каждый из типов первичных ключей имеет свои достоинства и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей.
   Основными достоинствами естественных ключей является то, что они несут вполне определенную информацию и их использование не приводит к необходимости добавлять в таблицы атрибуты, значения которых не имеют никакого смысла и требуются лишь для связи между отношениями. Иными словами, естественные ключи позволяют получить более компактную форму таблиц (без избыточных, неинформативных данных) и более естественные связи между ними.
   Основным же недостатком естественных ключей является то, что их использование весьма затруднительно в случае изменчивости предметной области. Следует понимать, что значения атрибутов первичного ключа не должны меняться. То есть однажды заданное значение первичного ключа для кортежа не может быть позже изменено. Такое требование ставится в основном для поддержания целостности базы данных. Связь между отношениями обычно устанавливается именно по первичному ключу, и его изменение приведет к нарушению этих связей или к необходимости изменения записей в нескольких таблицах. Даже в сравнительно простых базах данных это может вызвать ряд трудноразрешимых проблем.
   Примечание.
   В некоторых реляционных СУБД допускается изменение первичного ключа. Иногда это бывает действительно полезно. Однако прибегать к этому следует лишь в случае крайней необходимости.
   Типичным примером изменчивой предметной области, в которой для сущности невозможно определить неизменяемый естественный ключ, является любая область с человеком в качестве сущности.
   Второй довольно существенный недостаток естественных ключей состоит в том, что, как правило, уникальные естественные ключи являются составными и содержат строковые атрибуты. Как уже отмечалось, максимальная скорость выполнения операций над данными обеспечивается при использовании простых целочисленных ключей. Таким образом, с точки зрения быстродействия системы естественные ключи часто оказываются неоптимальными.
   Оба недостатка естественных ключей можно преодолеть, определив в отношениях суррогатные ключи, представляющие собой некоторый универсальный атрибут, как правило, целочисленного типа, не зависящий ни от предметной области, ни, тем более, от структуры отношения, которое он идентифицирует. Таким образом можно обеспечить уникальность и неизменность ключа (раз он никаким образом не зависит от предметной области, то никогда не возникнет необходимость изменять его). Однако за это приходится платить избыточностью данных в таблицах.
   Примечание.
   Следует заметить, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам.
   В любой из таблиц может оказаться несколько наборов атрибутов, которые допустимо выбрать в качестве ключа. Такие наборы называются потенциальными, или альтернативными, ключами.
   Нередко в отношениях определяются так называемые вторичные ключи. Вторичный ключ представляет собой комбинацию атрибутов, отличную от комбинации, составляющей первичный ключ. Причем вторичные ключи не обязательно обладают свойством уникальности. При их определении могут задаваться следующие ограничения:
   • UNIQUE – ограничение уникальности, значения вторичных ключей при данном ограничении не могут дублироваться;
   • NOT NULL – при данном ограничении ни один из атрибутов, входящих в состав вторичного ключа, не может принимать значение NULL
   Перекрывающиеся ключи – сложные ключи, которые имеют один или несколько общих столбцов.

Связанные отношения

   В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relation). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями.
   Для анализа связанных отношений воспользуемся рассмотренным ранее примером – отношением СТУДЕНТЫ (см. табл. 4.1). Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Фрагмент такого отношения может выглядеть так, как показано в табл. 4.2.
Таблица 4.2. Фрагмент отношения УСПЕВАЕМОСТЬ, связанного с отношением СТУДЕНТЫ