Разработка информационных систем; инструментальные средства

`çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Оглавление Введение .................................................................................................... 1. Назначение и функции инструментальных средств информационных систем....................................................................................... 1.1. Структура программного обеспечения компьютера. Понятие «инструментальное средство» .......................................................... 1.2. Необходимость в инструментальных средствах ...................... 1.3. Инструментарии информационных технологий ...................... 1.4. Среды разработки программного обеспечения ....................... 2. Инструментальная база информационных технологий ............ 2.1. Программные средства ................................................................ 2.2. Технические средства.................................................................. 2.3. Методические средства .............................................................. 2.4. Выбор инструментального средства ......................................... 3. Информационные системы .............................................................. 3.1. Общие понятия об информационных системах ....................... 3.2. Классификация информационных систем ................................ 3.3. Профиль информационной системы.......................................... 3.3.1. Профиль прикладного программного обеспечения ........ 3.3.2. Профиль среды информационной системы ..................... 3.3.3. Профиль защиты информации .......................................... 3.3.4. Профиль инструментальных средств ............................... 4. Современные инструментальные средства информационных систем ........................................................................................................ 5. Структурный подход в инструментальных средствах............... 5.1. Принципы структурного подхода .............................................. 5.2. Методология SADT...................................................................... 5.2.1. Концепция IDEF0 ................................................................ 5.2.2. Концепция DFD ................................................................... 5.2.3. Концепция IDEF3 ................................................................ 6. Объектно-ориентированный подход в инструментальных средствах................................................................................................... 6.1. CASE-метод Баркера .................................................................... 6.2. Подход, используемый в CASE-средстве Vantage Team Builder 3 5 7 7 13 15 17 18 18 24 28 35 37 37 41 43 48 49 49 50 52 64 64 65 66 70 73 76 76 81 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 7. Классификация архитектур информационных приложений ... 7.1. Файл-серверные приложения ..................................................... 7.2. Клиент-серверные приложения ................................................. 7.3. Intranet-приложения ..................................................................... 7.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных.................................................... 7.5. Интегрированные распределенные приложения ..................... 8. Средства и методологии проектирования, разработки и сопровождения архитектур информационных приложений ............ 8.1. Средства и методологии разработки файл-серверных приложений .................................................................................................... 8.1.1. Традиционные средства и методологии разработки файл-серверных приложений ...................................................... 8.1.2. Средства и методы разработки приложений на основе СУБД на персональных компьютерах ........................................ 8.1.3. Новые средства разработки файл-серверных приложений................................................................................................... 8.1.4. Новые СУБД для персональных компьютеров и соответствующие инструментальные средства разработки ........... 8.2. Средства и методологии проектирования, разработки и сопровождения приложений в архитектуре «клиент – сервер» ....... 8.2.1. Базовые средства построения информационных систем 8.2.2. Серверы баз данных как базовая системная поддержка информационной системы ........................................................... 8.3. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений ................................................... 8.3.1. Основные понятия Intranet ................................................. 8.3.2. Серверы Intranet .................................................................. 9. Общие тенденции развития инструментальных средств для информационных систем ...................................................................... Заключение ............................................................................................... Список использованной литературы .................................................. 4 85 85 87 88 89 91 94 94 94 95 97 97 99 99 100 102 102 103 105 115 116 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Введение Информационные системы связаны с большим количеством информации, которая поступает из различных источников и имеет различные форматы: текст, графические модели и пр. Кроме того, с этой информацией должно работать достаточно большое количество людей. Для удовлетворения этих специфических потребностей создан целый класс программных продуктов. Инструментальные средства за полвека своего существования претерпели огромные изменения, пройдя путь от программ, способных выполнять только простейшие логические и арифметические операции, до сложных систем управления предприятиями. Хотя первоначально компьютеры предназначались главным образом для выполнения сложных математических расчетов, в настоящее время доминирующим является накопление и обработка информации [Петров]. Сегодня управление предприятием без компьютера просто немыслимо. Компьютеры давно и прочно вошли в такие области, как бухгалтерский учет, управление ассортиментом и закупками. Однако современный бизнес требует более широкого применения информационных технологий в управлении. Жизнеспособность и развитие информационных технологий объясняется тем, что современный бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первым. Для принятия любого грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности, будь то торговля, производство или предоставление услуг, поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьезнее должны быть подобные вложения. Они являются жизненной необходимостью в жесткой конкурентной борьбе. 5 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Создание сложных информационных систем представляет собой серьезную задачу, решение которой требует применения специальных методик и инструментов. Неудивительно, что в последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE (Computer-Aided Software/System Engineering) – технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения. 6 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 1. НАЗНАЧЕНИЕ И ФУНКЦИИ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ ИНФОРМАЦИОННЫХ СИСТЕМ 1.1. Структура программного обеспечения компьютера. Понятие «инструментальное средство» Под программным обеспечением (Software) понимается совокупность программ и соответствующей документации, выполняемых вычислительной системой. К программному обеспечению (ПО) относится также вся область деятельности по проектированию и разработке ПО: – технология проектирования программ (например, нисходящее проектирование, структурное и объектно-ориентированное проектирование и др.); – методы тестирования программ; – методы доказательства правильности программ; – анализ качества работы программ; – документирование программ; – разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения; и др. В первом приближении все программы, работающие на компьютере, можно условно разделить на три категории. 1. Прикладные программы, непосредственно обеспечивающие выполнение необходимых пользователям работ. 2. Системные программы, выполняющие различные вспомогательные функции, например: – управление ресурсами компьютера; – создание копий используемой информации; – проверка работоспособности устройств компьютера; – выдача справочной информации о компьютере; и др. 3. Инструментальные программные системы, облегчающие процесс создания новых программ для компьютера. 7 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Инструментальные программные средства – это программы, которые используются в ходе разработки, корректировки или развития других прикладных или системных программ. По своему назначению они близки системам программирования. К инструментальным программам, например, относятся: – текстовые редакторы; – интегрированные среды разработки; – SDK; – компиляторы; – интерпретаторы; – компановщики (линковщики); – парсеры; – ассемблеры; – отладчики; – профилировщики; – генераторы документации; – средства анализа покрытия кода; – средства непрерывной интеграции; – средства автоматизированного тестирования; – системы управления версиями; – графические пакеты программ. Инструментальные программные средства могут оказать помощь на всех стадиях разработки ПО. Текстовый редактор – самостоятельная компьютерная программа или компонента программного комплекса, предназначенная для создания и изменения текстовых данных. Построчный (строковый) текстовый редактор (line editor) работает с текстом как с последовательностью пронумерованных строк, выполняя операции над текстом в указанных строках. Примером такого редактора может быть Edlin, входивший в состав MS-DOS. Контекстный (строковый) редактор (context editor), примером которого может быть ECCE (Edinburgh Compatible Context Editor), выполняет операции над текстом в текущей позиции. Экранный текстовый редактор позволяет пользователю перемещать курсор в тексте с помощью клавиш или других устройств ввода. Многие текстовые редакторы являются редакторами исходного кода, то есть они ориентированы на работу с текстами программ на тех или иных компьютерных языках. Интегрированная среда разработки (ИСР) (IDE, Integrated development environment или Integrated debugging environment) – си8 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ стема программных средств, используемая программистами для разработки программного обеспечения. Обычно среда разработки включает в себя: – текстовый редактор; – компилятор и/или интерпретатор; – средства автоматизации сборки; – отладчик. Иногда среда разработки содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Хотя и существуют ИСР, предназначенные для нескольких языков программирования – такие как Eclipse, NetBeans, Embarcadero RAD Studio, Qt Creator или Microsoft Visual Studio, но обычно ИСР предназначается для одного определенного языка программирования, такого, например, как Visual Basic, Delphi, Dev-C++. Частный случай ИСР – среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы. ИСР обычно представляет собой единственную программу, в которой проводилась вся разработка. Она обычно содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. SDK (Software development kit) – комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определенного пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. Программист, как правило, получает SDK непосредственно от разработчика целевой технологии или системы. Часто SDK распространяется через Интернет. Многие SDK распространяются бесплатно для того, чтобы побудить разработчиков использовать данную технологию или платформу. Поставщики SDK иногда заменяют слово «software» в словосочетании «software development kit» на более точное определение. Например, Microsoft и Apple предоставляют Driver Development Kit (DDK) для разработки драйверов устройств, PalmSource называет свой инструментарий для разработки PalmOS Development Kit (PDK), а Oracle – Java Development Kit (JDK). 9 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Компилятор – программа или техническое средство, выполняющее компиляцию. Компиляция – трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке, близком машинному коду. Входной информацией для компилятора (исходный код) является описание алгоритма или программа на проблемно-ориентированном языке, а на выходе компилятора – эквивалентное описание алгоритма на машинноориентированном языке (объектный код). Компилировать – проводить трансляцию машинной программы с проблемно-ориентированного языка на машинно-ориентированный. Интерпретатор – программа (разновидность транслятора) или аппаратное средство, выполняющее интерпретацию. Интерпретация – пооператорный (покомандный, построчный) анализ, обработка и тут же выполнение исходной программы или запроса (в отличие от компиляции, при которой программа транслируется без ее выполнения). Компоновщик (редактор связей, линкер) – программа, которая производит компоновку: принимает на вход один или несколько объектных модулей и собирает по ним исполнимый модуль. Работа компоновщика заключается в том, чтобы в каждом модуле определить и связать ссылки на неопределенные имена. Для каждого импортируемого имени находится его определение в других модулях, упоминание имени заменяется на его адрес. Синтаксический анализ (парсинг) – это процесс сопоставления линейной последовательности лексем (слов, токенов) языка с его формальной грамматикой. Результатом обычно является дерево разбора (синтаксическое дерево). Например, XML, HTML, CSS, ini-файлы, специализированные конфигурационные файлы и т.п. Ассемблер (от англ. assembler – сборщик) – компьютерная программа, компилятор исходного текста программы, написанной на языке ассемблера, в программу на машинном языке. Как и сам язык (ассемблера), ассемблеры, как правило, специфичны для конкретной архитектуры, операционной системы и варианта синтаксиса языка. Вместе с тем существуют мультиплатформенные или вовсе универсальные (точнее, ограниченно-универсальные, потому что на языке низкого уровня нельзя написать аппаратно-независимые программы) ассемблеры, которые могут работать на разных платформах и операционных системах. Среди последних можно также выделить группу кросс-ассемблеров, спо10 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ собных собирать машинный код и исполняемые модули (файлы) для других архитектур и ОС. Отладчик (дебаггер) – компьютерная программа, предназначенная для поиска ошибок в других программах, ядрах операционных систем, SQL-запросах и других видах кода. Отладчик позволяет выполнять пошаговую трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения кода, устанавливать и удалять контрольные точки или условия остановки и т.д. Популярные отладчики: – AQtime – коммерческий отладчик для приложений, созданных для .NET Framework версии 1.0, 1.1, 2.0, 3.0, 3.5 (включая ASP.NET приложения), а также для Windows 32- и 64-битных приложений; – DBX – стандартный отладчик уровня исходного кода для языков C, C++, Фортран и Java, доступный для операционных систем Solaris, AIX, IRIX, Tru64 UNIX, GNU/Linux и BSD; – DDD – графический фронтэнд к отладчикам DBX и GDB, использующий библиотеку виджетов Motif; – DTrace – фреймворк динамической трассировки для Solaris, OpenSolaris, FreeBSD, Mac OS X и QNX; – GNU Debugger – портабельный отладчик уровня исходного кода и дизассемблер из системы программирования GNU, работающий со многими языками программирования, операционными системами и системными архитектурами; – Microsoft Visual Studio – среда разработки программного обеспечения корпорации Microsoft, включающая средства отладки уровня исходного кода; – TotalView – коммерческий отладчик для Unix; – WinDbg – бесплатный отладчик от корпорации Microsoft; – FlexTracer – коммерческий отладчик SQL-запросов для различных СУБД. Профилирование – сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т.д. Инструмент, используемый для анализа работы, называют профилировщиком. Обычно выполняется совместно с оптимизацией программы. Характеристики могут быть аппаратными (время) или вызванными программным обеспечением (функциональный запрос). Инструментальные средства анализа программы чрезвычайно важны для того, чтобы понять поведение 11 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ программы. Проектировщики ПО нуждаются в таких инструментальных средствах, чтобы оценить, как хорошо выполнена работа. Программисты нуждаются в инструментальных средствах, чтобы проанализировать их программы и идентифицировать критические участки программы. К профилировщикам можно отнести VTune, CodeAnalyst, AQtime. Генератор документации – программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и (в некоторых случаях) по исполняемым модулям (полученным на выходе компилятора). Покрытие кода – мера, используемая при тестировании программного обеспечения. Она показывает в процентах долю протестированного исходного кода программы. Непрерывная интеграция (Continuous Integration) – это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Автоматизированное тестирование программного обеспечения – часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс. Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и тестирование пользовательского интерфейса. Для автоматизации тестирования существует большое количество приложений: HP LoadRunner, HP QuickTest Professional, HP Quality Center, Segue SilkPerformer, IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio, SmartBear Software TestComplete. Система управления версиями (Version Control System, VCS или Revision Control System) – программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. В частности, системы управления версиями применяются 12 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ в системах автоматизированного проектирования (САПР), обычно в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (Software Configuration Management Tools). 1.2. Необходимость в инструментальных средствах Необходимость использования современных инструментальных средств, прежде всего, обусловлена постоянно меняющимся миром, а соответственно и требованиям к информационным системам, к их интеграции. Информационные системы, разработанные при помощи современных инструментальных средств проектирования позволяют разрабатывать новые информационные системы с использованием понятного графического интерфейса, позволяющего совместно работать разработчику и будущему пользователю, в результате разработки генерировать программный код на различных языках программирования, тестировать систему, интегрировать с существующими в организации системами. В мире существует громадное количество готовых к использованию информационно-вычислительных ресурсов. Они создавались в разное время, для их разработки использовались разные подходы. Почти всегда при разработке новой информационной системы можно найти подходящие по своим функциям уже работающие готовые компоненты. Проблема состоит в том, что при их создании не учитывались требования интероперабельности. Эти компоненты не понимают один другого, они не могут работать совместно. Желательно иметь механизм или набор механизмов, которые позволят сделать такие независимо разработанные информационно-вычислительные ресурсы интероперабельными. Первым шагом на пути решения проблемы интеграции информационных ресурсов была попытка создать средства, позволяющие интегрировать набор разнородных баз данных (иерархических, сетевых, реляционных и т.д.). Такие средства должны были обеспечить возможность работы с неоднородными базами данных в единой концептуальной модели данных. Известные подходы основывались на использовании реляционной модели данных в качестве единой модели. Несмотря на высокий уровень проработки, системы управления интегрированными распределенными неоднородными базами 13 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ данных так и не вышли за пределы академических экспериментов. Видимо, это связано с целым рядом причин, основной из которых является то, что реляционная модель данных слишком ограничена, чтобы ее можно было использовать в качестве единой концептуальной модели [Кузнецов]. Тем не менее, проблема интеграции остается очень актуальной, и в последние годы все большее число специалистов соглашаются с тем, что ее можно и нужно решать на основе объектно-ориентированного подхода. Проблема интеграции неоднородных автономно разработанных информационно-вычислительных ресурсов рассматривалась в двух контекстах. Первый контекст – повторное использование (reusability) существующих и доступных по сети ресурсов. Второй контекст – облегчение разработки корпоративных информационных систем, отдельные компоненты которых создаются разными, территориально распределенными группами, каждая из которых в силу исторических причин использует наиболее привычную для нее технологию. Например, канадская компания BNR для разработки новых программных продуктов использует коллективы программистов из разных стран мира. Некоторые группы предпочитают использовать Си++, другие – объектный ЛИСП, третьи – Smalltalk и т.д. В результате должна появиться единая реально работающая программная система. Но имеется и третий контекст, контекст унаследованных систем (legacy systems). В любой крупной, долгое время существующей корпорации накапливаются информационные подсистемы, разработанные в соответствии с морально устаревшими технологиями. Например, трудно найти корпорацию с возрастом больше 25 лет, в которой не использовались бы информационные подсистемы, созданные на основе ранних аппаратно-программных платформ компании IBM. Базы данных таких подсистем содержат громадные объемы ценной информации, и корпорация просто не может обойтись без их использования. С другой стороны, унаследованные системы очень трудно сопровождать и поддерживать. Очень часто программная часть системы написана на языке ассемблера, а люди, которые писали эти программы, больше не работают в корпорации. Возникают проблемы и с аппаратной частью. Для корпорации было бы желательно перевести унаследованные информационные подсистемы на новые технологии, но работоспособность унаследованной системы может быть настолько важна для корпорации, что эту систему нельзя вывести из использования даже на короткое время. 14 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Одно из наиболее признанных решений проблемы унаследованных систем основывается также на объектно-ориентированном подходе. Идея состоит в том, что «вокруг» системы создается объектная оболочка. Естественно, что при этом порождается и новый объектный интерфейс системы, но до поры сохраняется и ее старый интерфейс. После этого параллельно все другие подсистемы корпорации постепенно переводятся на использование нового интерфейса реконструируемой подсистемы, а сама эта подсистема переделывается в соответствии с современными технологиями. В конце концов, когда сторонние подсистемы полностью готовы работать в новом интерфейсе и процесс переделки унаследованной подсистемы завершен, она заменяется на вновь разработанный вариант. Для полной интеграции информационных систем необходимо знать, как возможно объединить разнородные системы, иметь план общей системы. Прежде всего для этого нужны полные и непротиворечивые функциональные модели информационных систем, возможность тестирования систем на совместимость, безопасность и т.д., то есть нужны соответствующие инструментальные средства. 1.3. Инструментарии информационных технологий Средства для создания приложений включают языки и системы программирования, а также инструментальную среду разработчика. Язык программирования – формализованный язык для описания алгоритма решения задачи на компьютере. Средства для создания приложений – совокупность языков и систем программирования, а также различные программные комплексы для отладки и поддержки разрабатываемых программных продуктов. Языки программирования разделяют на следующие классы (по синтаксису конструкций языка): – машинные языки – языки программирования, воспринимаемые аппаратной частью компьютера (машинные коды); – машинно-ориентированные языки – языки программирования, которые отражают структуру конкретного типа компьютера (ассемблеры); – алгоритмические языки – не зависящие от архитектуры компьютера языки программирования для отражения структуры алгоритма (Паскаль, Фортран, Бейсик и др.); 15 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – процедурно-ориентированные языки – языки программирования, где имеется возможность описания программы как совокупности процедур, подпрограмм; – проблемно-ориентированные языки – языки программирования, предназначенные для решения задач определенного класса (ЛИСП, РПГ, Симула и др.); – интегрированные системы программирования. Другой классификацией языков программирования является их деление на языки, предназначенные для реализации основ структурного программирования, и объектно-ориентированные языки, поддерживающие понятие объектов, их свойств и методов обработки. Программа, написанная на языке программирования, проходит этап трансляции, когда происходит преобразование исходного кода программы в объектный код, который далее пригоден к обработке редактором связей. Редактор связей – специальная подпрограмма, обеспечивающая построение загрузочного модуля, пригодного к выполнению. Трансляция может выполняться с использованием средств компиляторов или интерпретаторов. Компиляторы транслируют всю программу, но без ее выполнения. Интерпретаторы, в отличие от компиляторов, выполняют пооператорную обработку и выполнение программы. Необходимым средством для профессионального разработчика являются специальные программы, предназначенные для трассировки и анализа выполнения других программ, – отладчики. Современная система программирования состоит из следующих компонентов: – компилятор; – интегрированная среда разработчика программ; – отладчик; – средства оптимизации кода программ; – набор библиотек (возможно, с исходными текстами программ); – редактор связей; – сервисные средства (утилиты) для работы с библиотеками, текстовыми и двоичными файлами; – справочные системы; – документатор исходного кода программы; – система поддержки и управления проектом программного комплекса. 16 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 1.4. Среды разработки программного обеспечения Модель среды разработки (схема функционирования) определяет технологические процессы, совершаемые программистом, включает в себя наборы объектов и цепочки технологических операций. Модель существенно зависит от архитектуры, сложности и масштаба целевого объекта (программного средства), который должен быть получен в итоге. Для каждой категории объекта требуется своя модель, свой набор инструментальных средств. Категории программных средств: простая программа, сложная многокомпонентная программа, программа, работающая с базами данных, распределенная программная система, программа как сервис и др. Все перечисленные понятия имеют отношение к технологии программирования, определяя ее инструментальное обеспечение. Модель среды можно изобразить в виде диаграммы, на которой отражены основные процессы, объекты, с которыми они работают, а также условия и параметры, влияющие на формирование объектов [Свердлов]. Оценивая качество и эффективность операционной среды, необходимо обращать внимание на интерфейсы инструментальных средств [Проектирование пользовательского интерфейса]. Современный подход к пользовательскому интерфейсу был заложен в стандарте фирмы IBM. Этот стандарт воплотился во многих программных средствах, как инструментальных, так и прикладных. Стандарт определяет оконный интерфейс, правила размещения в окнах элементов управления, назначение горячих клавиш и даже рекомендует цветовые схемы интерфейса. Конечно, в рамках этого стандарта можно реализовать большое количество разнообразных интерфейсов. Развитие и нововведения в интерфейсах можно проследить на линейках продуктов типа MS Office. Одним из важных и необходимых свойств среды является возможность настройки. К интерфейсу также относится замечание об избыточности и необходимости минимизации возможностей. Технология программирования во многом определяется языком программирования, на котором пишутся программы. В языке могут быть заложены средства, влияющие на технологичность и архитектуру разрабатываемой системы (например, объектно-ориентированность, модульность и т.п.) [Эберт]. 17 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 2. ИНСТРУМЕНТАЛЬНАЯ бАЗА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИй Информационные технологии функционируют на основе инструментальной базы, включающей программные, технические и методические средства [Советов]. Инструментальная база информационных технологий представлена на рисунке 2.1. Инструментальная база информационных технологий Програмные средства Технические средства Методические средства Рис. 2.1. Инструментарий информационных технологий 2.1. Программные средства Программные средства информационных технологий можно разделить на две большие группы: базовые и прикладные (рис. 2.2). Базовые программные средства относятся к инструментальной страте информационных технологий и включают в себя: – операционные системы (ОС); – языки программирования; – программные среды; – системы управления базами данных (СУБД). Прикладные программные средства предназначены для решения комплекса задач или отдельных задач в различных предметных областях. 18 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Программные средства Базовые Прикладные Операционные системы Языки программирования Программные среды Системы управления базами данных Рис. 2.2. Группы программных средств Базовое программное обеспечение реализует технологии операционных систем, систем программирования и программ технического обслуживания компьютера. Операционные системы предназначены для управления ресурсами ЭВМ и процессами, использующими эти ресурсы. В настоящее время существуют две основные линии развития ОС: Windows и Unix. Генеалогические линии данных ОС развивались следующим образом: 1. СР/М → QDOS → 86-DOS → MS-DOS → Windows. 2. Multics → UNIX → Minix → Linux. Большинство алгоритмических языков программирования (Си, Паскаль) созданы на рубеже 1960 и 1970-х годов (за исключением Java). Периодически появлялись новые языки программирования, однако на практике они не получили широкого и продолжительного распространения. Другим направлением в эволюции современных языков программирования были попытки создания универсальных языков (Алгол, PL/1, Ада), объединяют в себе достоинства ранее разработанных. Появление ПК и ОС с графическим интерфейсом (Mac OS, Windows) привело к смещению внимания разработчиков программного обеспечения в сферу визуального или объектно-ориентированного программирования, сетевых протоколов, баз данных. 19 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Это привело к тому, что в настоящее время в качестве инструментальной среды используется конкретная среда программирования (Delphi, Access и др.) и знания базового языка программирования не требуется. Можно считать, что круг используемых языков программирования стабилизировался [Молокова и др. ]. Анализ синтаксиса и семантики языков программирования показывает, что их родственные конструкции различаются главным образом «внешним видом» (набором ключевых слов или порядком следования компонентов). Содержимое практически идентично, за исключением небольших различий, не имеющих существенного значения. Таким образом, конструкции современных языков имеют общее содержание (семантику), различный порядок следования компонент (синтаксис) и разные ключевые слова (лексику). Следовательно, различные языки предоставляют пользователю одинаковые возможности при различном внешнем виде программ. Стандартизацию языков программирования в настоящее время осуществляют комитеты ISO/ANSI, однако их деятельность направлена в основном на неоправданное синтаксическое расширение языков. Для исключения существующих недостатков предложены способы задания семантического и синтаксического стандартов языков программирования. Семантическое описание любой конструкции языка (оператор, тип данных, процедура и т.д.) должно содержать не менее трех обязательных частей: – список компонент (в Типе указателя это компоненты Имя типа и Базовый тип); – описание каждой компоненты; – описание конструкции в целом. Среди большого числа языков самую заметную роль в развитии программирования сыграли три пары: Алгол-60 и Фортран, Паскаль и Си, Java и Си++. Эти языки не случайно объединены в пары, так как противостояние заложенных в них идей способствовало их прогрессивному развитию. Важно различать язык программирования и его реализацию. Сам язык – это система записи, набор правил, определяющих синтаксис и семантику программы. Реализация языка – это программа, которая преобразует запись высокого уровня в последовательность машинных команд. Существуют два способа реализации языка: компиляция и интерпретация. При компиляции специальная рабочая программа (компилятор) осуществляет перевод рабочей программы в эквивалентную на ма20 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ шинном коде, и в дальнейшем ее выполнение совместно с данными. В методе интерпретации специальная программа (интерпретатор) устанавливает соответствие между языком и машинными кодами, применяя команды к данным. Любой язык программирования может быть как интерпретируемым, так и компилируемым, но в большинстве случаев есть свой предпочтительный способ реализации. К сожалению, в настоящее время не существует универсального компилятора, который мог бы работать с любым существующим языком. Это объясняется отсутствием единой семантической базы. Хотя современные языки программирования похожи друг на друга, идентичность их далеко не полная. Таким образом, существует общая семантическая зона, в которую входят конструкции, принадлежащие всем языкам программирования (или большинству из них), и область объединения, содержащая конструкции, специфические для данного языка, поэтому создание универсального компилятора возможно двумя путями: 1. Использование общих конструкций (область пересечения), исключение специфических конструкций языков (область объединения). Это приведет к обеднению всех языков программирования. 2. Использование всех имеющихся конструкций (область объединения + область пересечения). Такой подход приведет к значительному расширению семантической базы и использованию дополнительных ресурсов. С точки зрения информационных технологий программирование имеет промышленный характер, который соответствует традиционным стадиям жизненного цикла программного продукта: – анализу требований; – разработке спецификаций; – проектированию; – макетированию; – написанию исходного текста; – отладке; – документированию; – тестированию и сопровождению. Наряду с этим направлением развивается так называемое исследовательское программирование. Программные среды реализуют отдельные задачи и операции информационных технологий. К их числу относятся: – текстовые процессоры; – электронные таблицы; 21 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – личные информационные системы; – программы презентационной графики; – браузеры; – редакторы WEB-страниц; – почтовые клиенты; – редакторы растровой графики; – редакторы векторной графики; – настольные издательские системы; – средства разработки. Системы программирования в основном используются для проектирования ИС и представляют язык программирования и программу перевода (транслятор, компилятор, интерпретатор) с этого языка в машинные коды. Программы технического обслуживания предоставляют сервис для эксплуатации компьютера, выявления ошибок при сбоях, восстановления испорченных программ и данных. Прикладное программное обеспечение определяет разнообразие информационных технологий и состоит из отдельных прикладных программ или пакетов прикладных программ, называемых приложениями. Для классификации информационных технологий используются разные критерии. В настоящее время общеупотребительными критериями являются: – применение в предметной области; – функции применения; – тип обрабатываемых данных; – способ передачи данных; – способ объединения технологий. По применению в предметной области прикладное программное обеспечение делится на предметные и прикладные приложения. Предметные приложения представляют собой типовые пакеты программ решения конкретных задач, подсистем экономических информационных систем, функциональных информационных систем. Примерами типовых программ решения конкретных задач являются АРМ – автоматизированные рабочие места работников организации. Автоматизированным рабочим местом называют персональный компьютер, оснащенный профессионально ориентированными приложениями и размещенный непосредственно на рабочем месте. Его назначение – автоматизация рутинных работ 22 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ информационного работника. Примерами АРМ являются АРМ бухгалтера, складского работника, операциониста банка, менеджера. Примерами функциональных подсистем ЭИС являются подсистемы бухгалтерского учета, финансового планирования и анализа, маркетинга, кадров и т.д. Примерами функциональных информационных систем являются банковские, страховые, налоговые и другие системы. Для создания предметных приложений подсистем ЭИС, функциональных информационных систем и АРМ используются обеспечивающие предметные приложения и информационные технологии общего назначения. Примерами обеспечивающих предметных технологий являются Project Expert, Marketing Expert, приложения фирм 1С, Галактика, ПАРУС, BAAN, BaySIS и др. Для применения обеспечивающего предметного приложения требуется настройка на специфику конкретной организации и знание предметной области. Следовательно для изучения обеспечивающих предметных технологий требуются знания предметной области, поэтому они не рассматриваются в данном учебном пособии. Прикладные приложения являются информационными технологиями общего назначения и имеют общий, универсальный характер. Они применимы практически во всех сферах экономической и управленческой деятельности. Например, текстовые, табличные процессоры, электронная почта, интернет. Для их изучения не требуется знание предметной области. По функциям применения можно выделить следующие виды информационных технологий: расчеты, хранение данных, документооборот, коммуникации, организация коллективной работы, помощь в принятии решений. Для автоматизации типовых расчетов были созданы обеспечивающие предметные технологии. Одновременно стали создаваться информационные технологии, позволяющие производить расчеты во многих предметных областях, например электронные таблицы. Для хранения данных были разработаны базы данных и системы управления базами данных (СУБД). В дальнейшем увеличение объемов хранимых данных, использование разных устройств для хранения, усложнение методов управления данными привело к появлению распределенной обработки данных, информационных хранилищ. Документооборот означает, что на компьютере должны решаться задачи систематизации, архивации, хранения, поиска и контроля 23 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ исполнения документов. При этом обработке подлежат все типы документов, обращающихся в сфере деятельности информационных работников. Автоматизация обработки документов начиналась с использования текстовых, электронных, графических редакторов, гипертекстовой и мультимедийной технологий, системы управления базами данных. Позднее появились системы электронного документооборота, реализующие все перечисленные функции. Для автоматизации функций коммуникации разработаны сетевые технологии, обеспечиваемые сетевой операционной системой. Для обмена данными между удаленными пользователями разработана электронная почта. Для организации коллективной работы отдельных групп сотрудников и всего предприятия были разработаны технологии автоматизации деловых процессов и технологии организации групповой работы. Для поддержки принятия решений разрабатывались экспертные системы и базы знаний. В настоящее время к ним относятся системы поддержки принятия решений, деловые интеллектуальные технологии выбора аналитических данных и аналитические системы. По типу обрабатываемых данных можно выделить текстовые, табличные, графические, мультимедийные, геоинформационные, управленческие технологии. Текстовые данные обрабатываются текстовыми процессорами и гипертекстовой технологией. Числовые данные обрабатываются электронными таблицами, системами управления баз данных (СУБД). Графические данные обрабатываются двух- и трехмерными графическими процессорами. Мультимедийные технологии и видеоконференция обрабатывают все типы данных, включая объекты реального времени: звук и видео. Геоинформационные технологии обрабатывают все типы данных, включая географические и пространственные данные. Знания используются в экспертных системах, системах поддержки принятия решений, аналитических системах, относящихся к управленческим технологиям. 2.2. Технические средства Компьютеры являются ядром любой информационной системы. Первоначально они были созданы для реализации большого объема вычислений, представляющих длинные цепочки итера24 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ций. Главным требованием при этом были высокая точность и минимальное время вычислений. Такие процессы характерны для числовой обработки. По мере внедрения ЭВМ, их эволюционного развития, стали возникать другие области применения, отличные от вычислений, например обработка экономической информации, создание информационно-справочных систем, автоматизация учрежденческой деятельности и т.п. В данном случае не требовались высокая точность и большой объем вычислений, однако объем обрабатываемой информации мог достигать миллионов и миллиардов записей. При этом требовалось не только обработать информацию, а предварительно ее найти и организовать соответствующую процедуру вывода. Указанные процессы характерны для нечисловой обработки, требующей в большинстве случаев больших затрат машинного времени. Рассмотренные аспекты оказали решающее влияние на развитие архитектуры ЭВМ. ЭВМ классической (фоннеймановской) архитектуры состоит из пяти основных функциональных блоков: – запоминающего устройства (ЗУ); – устройства управления; – устройств управления и арифметически-логического устройства, рассматриваемых вместе и называемых центральным процессором; – устройства ввода; – устройства вывода. В фоннеймановской архитектуре для обработки огромного объема информации (миллиарды байт) используется один процессор. Связь с данными осуществляется через канал обмена. Ограничения пропускной способности канала и возможностей обработки в центральном процессоре приводят к тупиковой ситуации при нечисловой обработке в случае увеличения объемов информации. Для выхода из тупика было предложено два основных изменения в архитектуре ЭВМ: – использование параллельных процессоров и организация параллельной обработки; – распределенная логика, приближающая процессор к данным и устраняющая их постоянную передачу. Другой недостаток фоннеймановской архитектуры связан с организацией процесса обращения к ЗУ, осуществляемого путем указания адреса для выборки требуемого объекта из памяти. Это приемлемо для числовой обработки, но при нечисловой обработке 25 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ обращение должно осуществляться по содержанию (ассоциативная адресация). Поскольку для нечисловой обработки в основном используется та же архитектура, необходимо было найти способ организации ассоциативного доступа. Он осуществляется путем создания специальных таблиц (справочников) для перевода ассоциативного запроса в соответствующий адрес. При такой организации обращения к ЗУ, называемом эмуляцией ассоциативной адресации, в случае работы с большими объемами информации резко падает производительность ЭВМ. Это связано с тем, что нечисловая обработка – это не только просмотр, но и обновление данных. Для преодоления ограничений организации памяти были предложены ассоциативные запоминающие устройства. Таким образом, ЭВМ для нечисловой обработки должна удовлетворять следующим требованиям: ассоциативность, параллелизм, обработка в памяти. Кроме этого на более высоком уровне к архитектуре предъявляются следующие требования: – перестраиваемость параллельных процессоров и запоминающих устройств; – сложные топологии соединений между процессорами; – мультипроцессорная организация, направленная на распределение функций. Перечисленные выше ограничения и требования были реализованы в машинах баз данных (МБД). Приведем классификацию архитектур ЭВМ: – архитектура с одиночным потоком команд и одиночным потоком данных (SISD); – архитектура с одиночным потоком команд и множественным потоком данных (SIMD); – архитектура с множественным потоком команд и одиночным потоком данных (MISD); – архитектура с множественным потоком команд и множественным потоком данных (MIMD). К классу SISD относятся современные фоннеймановские однопроцессорные системы. В этой архитектуре центральный процессор работает с парой «атрибут – значение». Атрибут (метка) используется для локализации соответствующего значения в памяти, а одиночная команда обрабатывает содержимое накопителя (регистра) и значение – результат. В каждой итерации из входного потока данных используется только одно значение. 26 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ К классу SIMD относят большой класс архитектур, основная структура которых состоит из одного контроллера, управляющего комплексом одинаковых процессоров. В зависимости от возможностей контроллера и процессорных элементов, числа процессоров, организации поиска и характеристик маршрутных и выравнивающих сетей выделяют четыре типа SIMD: – матричные процессоры, организованные так, что при выполнении заданных вычислений, инициированных контроллером, они работают параллельно (предназначены для решения векторных и матричных задач, относящихся к числовой обработке); – ассоциативные процессоры, обеспечивающие работу в режиме поиска по всему массиву за счет соединения каждого процессора непосредственно с его памятью (используются для решения нечисловых задач); – процессорные ансамбли, представляющие совокупность процессоров, объединенных определенным образом для решения заданного класса задач, ориентированных на числовую и нечисловую обработку; – конвейерные процессоры (последовательные и векторные), осуществляющие выполнение команд и обработку потоков данных по принципу, аналогичному транспортному конвейеру. В этом случае каждый запрос использует одни и те же ресурсы. Как только некоторый ресурс освобождается, его можно использовать для следующего запроса, не дожидаясь окончания выполнения предыдущего. Если процессоры выполняют аналогичные, но не тождественные задания, то это последовательный конвейер, если все задания одинаковы – то векторный конвейер. К классу MISD может быть отнесена единственная архитектура – конвейер, но при условии, что каждый этап выполнения запроса является отдельной командой. К классу MIMD, хотя и не всегда однозначно, относят следующие конфигурации: – мультипроцессорные системы; – системы с мультиобработкой; – вычислительные системы из многих машин; – вычислительные сети. Общим для данного класса является наличие ряда процессоров и мультиобработки. В отличие от параллельных матричных систем число процессоров невелико, а термин «мультиобработка» используют для обозначения функционально распределенной обработки (сортировки, слияния, ввода-вывода и др.). 27 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Другим направлением развития вычислительной техники является нейрокомпьютеринг, основанный на нейронных сетях. Разработки проводятся в двух направлениях: аппаратном и программном. Нейрокомпьютеры обладают сверхвысокой производительностью, но благодаря сложным технологиям имеют очень высокую стоимость, поэтому они используются узким кругом пользователей для решения суперзадач. В последние годы ведутся работы по созданию биокомпьютера на основе молекулярных технологий. Идея молекулярного вычислителя состоит в представлении «машинного» слова в виде состояний молекул. Несмотря на развитие средств вычислительной техники, наиболее популярными в настоящее время остаются компьютеры с традиционной фоннеймановской архитектурой. ЭВМ такой архитектуры в процессе эволюции последовательно прошли этапы аппаратной реализации от электронно-ламповой, транзисторной, интегрально-схемной до сверхбольших интегральных схем (СБИС). В настоящее время наиболее распространенным типом ЭВМ являются персональные компьютеры (ПК), относящиеся к фоннеймановской архитектуре. 2.3. Методические средства Для большинства технологий характерной чертой их развития является стандартизация и унификация. Стандартизация – нахождение решений для повторяющихся задач и достижение оптимальной степени упорядоченности. Унификация – относительное сокращение разнообразия элементов по сравнению с разнообразием систем, в которых они используются. Главная задача стандартизации в рассматриваемой области – создание системы нормативно-справочной документации, определяющей требования к разработке, внедрению и использованию всех компонентов информационных технологий. На сегодняшний день в области информационных технологий наблюдается неоднородная картина уровня стандартизации. Для ряда технологических процессов характерен высокий уровень стандартизации (например, для транспортирования информации), для других он находится в зачаточном состоянии. 28 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Многообразные стандарты и подобные им методические материалы упорядочим по следующим признакам: 1. По утверждающему органу: – официальные международные стандарты; – официальные национальные стандарты; – национальные ведомственные стандарты; – стандарты международных комитетов и объединений; – стандарты фирм-разработчиков; – стандарты «де-факто». 2. По предметной области стандартизации: – функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы, кодирование, шифрование и др.); – стандарты на фазы развития (жизненного цикла) информационных систем (стандарты на проектирование, материализацию, эксплуатацию, сопровождение и др.). В зависимости от методического источника в качестве стандартов могут выступать метод, модель, методология, подход. Следует отметить, что указанные стандарты обладают разной степенью обязательности, конкретности, детализации, открытости, гибкости и адаптируемости. В качестве примера рассмотрим ряд стандартов различного уровня. Международный стандарт ISO/OSI разработан международной организацией по стандартизации (International Standards Organization – ISO). Он предназначен для использования в области сетевого информационного обмена и представляет эталонную семиуровневую модель, известную как модель OSI (Open System Intercongtction – связь открытых систем). Первоначально усилия были направлены на разработку структуры (модели) протоколов связи цифровых устройств. Основная идея была связана с разбиением функций протокола на 7 различных категорий (уровней), каждый из которых связан с одним более высоким и с одним более низким уровнем (за исключением самого верхнего и самого нижнего). Идея семиуровневого открытого соединения состоит не в попытке создания универсального множества протоколов связи, а в реализации «модели», в рамках которой могут быть использованы уже имеющиеся различные протоколы. В последнее время достигнут значительный прогресс в реализации различных типов протоколов, о чем говорит успешное функционирование многих сетей передачи данных, например Интернета. 29 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Международный стандарт ISO/IEC 12207:1995-08-01 – базовый стандарт процессов жизненного цикла программного обеспечения, ориентированный на различные его виды, а также типы информационных систем, куда программное обеспечение входит как составная часть. Он разработан в 1995 году объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения» и включает описание основных, вспомогательных и организационных процессов. Основные процессы программного обеспечения: – процесс приобретения, определяющий действия покупателя, приобретающего информационную систему, программный продукт или его сервис; – процесс поставки, регламентирующий действия поставщика, снабжающего указанными выше компонентами; – процесс разработки, определяющий действия разработчика принципов построения программного изделия; – процесс функционирования, определяющий действия оператора, обслуживающего информационную систему в интересах пользователей и включающий помимо требований инструкции по эксплуатации консультирование пользователей и организацию обратной связи с ними; – процесс сопровождения, регламентирующий действия персонала по модификации программного продукта, поддержке его текущего состояния и функциональной работоспособности. Вспомогательные процессы регламентируют документирование, управление конфигурацией, обеспечение качества, верификацию, аттестацию, совместную оценку, аудит. Степень обязательности для организации, принявшей решение о применении ISO/IEC 12207, обусловливает ответственность в условиях торговых отношений за указание минимального набора процессов и задач, требующих согласования с данным стандартом. Стандарт содержит мало описаний, направленных на проектирование баз данных, что объясняется наличием отдельных стандартов по данной тематике. ГОСТ 34 в качестве объекта стандартизации рассматривает автоматизированные системы различных видов и все виды их компонентов, в том числе программное обеспечение и базы данных. Стандарт в основном рассматривает проектные документы, что 30 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ отличает его от стандарта ISO/IEC 12207. В структуре стандарта выделяют стадии и этапы разработки автоматизированных систем (АС). Рассмотрим их краткую характеристику: 1. Формирование требований к автоматизированной системе: – обследование объекта и обоснование необходимости создания АС; – формирование требований пользователя к АС; – оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания). 2. Разработка концепции автоматизированной системы: – изучение объекта; – проведение необходимых научно-исследовательских работ; – разработка вариантов концепции АС, удовлетворяющей требованиям пользователя; – оформление отчета о выполненной работе. 3. Техническое задание: разработка и утверждение технического задания. 4. Эскизный проект: – разработка предварительных проектных решений по системе и ее частям; – разработка документации на АС и ее части. 5. Технический проект: – разработка проектных решений по системе и ее частям; – разработка документации на АС и ее части; – разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; – разработка заданий на проектирование в смежных частях проекта объекта автоматизации. 6. Рабочая документация: – разработка рабочей документации на систему и ее части; – разработка или адаптация программ. 7. Ввод в действие: – подготовка объекта автоматизации к вводу АС в действие; – подготовка персонала; – комплектация АС поставляемыми изделиями (программными, техническими и информационными средствами); – строительно-монтажные работы; – пуско-наладочные работы; 31 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – предварительные испытания; – опытная эксплуатация; – приемочные испытания. 8. Сопровождение автоматизированной системы: – выполнение работ в соответствии с гарантийными обязательствами; – послегарантийное обслуживание. ГОСТ 34 содержит обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов. В настоящее время обязательность выполнения этого ГОСТа отсутствует, поэтому его используют в качестве методической поддержки. Методика Oracle CDM (Custom Development Method) является развитием ранее разработанной версии Oracle CASE-Method, известной по использованию Designer/2000. Она ориентирована на разработку прикладных информационных систем под заказ. Структурно построена как иерархическая совокупность этапов, процессов и последовательностей задач. Этапы: – стратегия (определение требований); – анализ (формирование детальных требований); – проектирование (преобразование требований в спецификации); – реализация (разработка и тестирование приложений); – внедрение (установка, отладка и ввод в эксплуатацию); – эксплуатация (поддержка, сопровождение, расширение). Процессы: – RD – определение производственных требований; – ES – исследование и анализ существующих систем; – ТА – определение технической архитектуры; – DB – проектирование и построение базы данных; – MD – проектирование и реализация модулей; – CV – конвертирование данных; – DO – документирование; – ТЕ – тестирование; – TR – обучение; – TS – переход к новой системе; – PS – поддержка и сопровождение. Процессы состоят из последовательностей задач, причем задачи разных процессов взаимосвязаны ссылками. 32 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Методика не предусматривает включение новых задач, удаление старых, изменение последовательности выполнения задач. Методика необязательна, она может считаться фирменным стандартом. В связи с широким использованием в настоящее время объектной технологии большой интерес представляет CORBA (Common Object Request Broker Architecture) – стандарт в виде набора спецификаций для промежуточного программного обеспечения (middleware) объектного типа. Его автором является международный консорциум OMG (Object Management Group), объединяющий более 800 компаний (IBM, Siements, Microsoft, Sun, Oracle и др.). OMG разработал семантический стандарт, включающий 4 основных типа: – объекты, моделирующие мир (студент, преподаватель, экзамен); – операции, относящиеся к объекту и характеризующие его свойства (дата рождения студента, пол и др.); – типы, описывающие конкретные значения операций; – подтипы, уточняющие типы. На основе этих понятий OMG определил объектную модель, спецификацию для развития стандарта CORBA, постоянно развиваемую. В настоящее время CORBA состоит из 4 основных частей: – Object Request Broker (посредник объектных запросов); – Object Services (объектные сервисы); – Common Facilities (общие средства); – Application and Domain Interfaces (прикладные и отраслевые интерфейсы). Параллельно с CORBA корпорацией Microsoft был разработан стандарт COM/DCOMB (Component Object Model/Distributed СОМ), предназначенный для объединения мелких офисных программ. Основным недостатком данного стандарта была ориентация на Windows и Microsoft. Корпорация Microsoft долгое время не присоединялась к OMG и развивала собственный стандарт. Однако жизнь заставила приступить к мирным переговорам. OMG взаимодействует с другими центрами стандартизации: ISO, Open Group, WWW-консорциум, IEEE и многими другими. CORBA стал неотъемлемой частью распределенных объектных компьютерных систем. Приведенные примеры стандартов дают представление о подходах к решению проблем стандартизации. Естественно, затраты на стандартизацию могут сделать проектные работы по внедрению информационных технологий более до33 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ рогостоящими, однако эти затраты с лихвой окупаются в процессе эксплуатации и развития системы, например, при замене оборудования или программной среды. Таким образом, стандартизация является единственной возможностью обеспечения порядка в бурно развивающихся информационных технологиях. По аналогии с современным строительством, когда дома строят из блоков или панелей, программные приложения реализуются из компонентов. Под компонентом в данном случае понимают самостоятельный программный продукт, поддерживающий объектную идеологию, реализующий отдельную предметную область и обеспечивающий взаимодействие с другими компонентами с помощью открытых интерфейсов. Такая технология направлена на сокращение сроков разработки программных приложений и обеспечение гибкости внедрения. В плане реализации подобной технологии естественным является переход от стандартизации интерфейсов к стандартизации компонентов. Для унификации этого процесса необходимы метастандарты проектирования бизнес-процессов, которые формулируют основные установочные концепции. На первый взгляд, бизнес-процессы и информационные технологии имеют мало общего. Однако внедрение информационных технологий всегда приводит к реорганизации бизнеса, потому методики моделирования бизнеса имеют много общего с проектированием информационных систем. Здесь может быть выстроена следующая цепочка: предметная область – бизнес-модель – модель информационной системы – технологическая модель – детальное представление – функционирование системы. Среди стандартов проектирования бизнес-процессов можно отметить следующие: семейство стандартов IDEF (Integration Definition for Function), RUP (компании Rational Software), Catalysis (компании Computer Associates). Каждый из этих стандартов базируется на исходных понятиях. Например, в стандарте IDEF0 (Integration Definition for Function Modeling) такими понятиями являются: – работа (Activity) – для обозначения действия; – вход (Input), выход (Output), управление (Control), механизм (Mechanism) – для обозначения интерфейсов. Использование стандартов проектирования бизнес-процессов позволяет унифицировать процесс абстрагирования и формализации представления предметной области. Мощным методо34 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ логическим средством в этой области является концепция CASE (Computer Aided Software Engineering). Инструментальные средства CASE – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО [Федотов]. 2.4. Выбор инструментального средства Быстрое расширение сфер применения систем, основанных на знаниях, потребовало развитие адекватных инструментальных средств для создания информационных систем. Существует уже несколько десятков таких средств. Они отличаются друг от друга способами представления знаний, механизмами получения решений и интерфейсами, допустимыми размерами разрабатываемых баз данных, оборудованием, стоимостью и другими характеристиками. При этом правильный выбор широты постановки задачи и подходящего инструментального средства – это два самых трудных решения, которые необходимо принять при разработке информационных систем. Трудность, однако, заключается и в том, что разработчики инструментальных средств в действительности не имеют ясного представления, какие характеристики средств построения информационных систем требуются для решения конкретных классов задач. Эта ситуация привела к тому, что был сформулирован эмпирический закон Дэвиса (по типу законов Мэрфи): для каждого инструментального средства имеется задача, прекрасно подходящая для него. Однако обратное утверждение (достаточность) неверно, так как для любой заданной задачи можно найти несколько средств, с помощью которых можно одинаково хорошо разработать эту задачу. Также верно и то, что ни одно из этих средств не будет вполне подходить для этой задачи. Большинство современных информационных систем было построено с помощью средств, выбранных по следующим признакам: – разработчик был уже хорошо знаком с этим средством; 35 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – выбранное средство было наиболее эффективным и доступным из числа тех, которые могли быть использованы на вычислительной технике разработчика; – вначале было разработано средство, и лишь потом были найдены приложения для его проверки [Дубейковский]. Рассмотрим одну из возможных классификаций инструментальных средств построения прикладных ЭС, предложенную Э.В. Поповым. В настоящее время завершенная критериальная система выбора подходящего инструментального средства отсутствует. Рассмотрим один из возможных подходов к построению такой системы. Инструментальные средства разработки информационных систем должны обеспечивать выполнение следующих функций: – работа в реальном масштабе времени; – взаимодействие с внешними программами; – генерация кода на традиционных языках программирования; – обращение к репозиторию; – работа разработчиков в команде; – графический интерфейс; – встроенная издательская система. В свою очередь, при активизации внимания на пользовательском аспекте, который, в конечном счете, и определяет применимость инструментального средства для разработки информационной системы и ее жизнеспособность, обычно рассматриваются следующие критерии: – мощность и гибкость средства; – спектр средств пользователя; – пользовательский интерфейс; – совместимость с другими программными средствами; – трудности изучения и наличие документации; – легкость обновления. В соответствии с ГОСТ 28805-90 понятие «качество программного средства» отражает совокупность свойств этого средства, которые обусловливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его назначением. Поэтому применительно к инструментальным средствам разработки их качество – это мера, в которой комплекс свойств этих средств отвечает комплексу требований, имеющих решающее значение для выполнения этим средством его функций в заданных условиях при минимуме как его стоимости, так и расходов на конструирование информационной системы. 36 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 3. ИНФОРМАЦИОННЫЕ СИСТЕМЫ 3.1. Общие понятия об информационных системах В зависимости от конкретной области применения информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Однако можно выделить, по крайней мере, два свойства, которые являются общими для всех информационных систем. Во-первых, любая информационная система предназначена для сбора, хранения и обработки информации. Во-вторых, информационные системы ориентируются на конечного пользователя, например, банковского служащего. Такие пользователи могут быть очень далеки от мира компьютеров. Для них терминал, персональный компьютер или рабочая станция представляют собой всего лишь орудие их собственной профессиональной деятельности, поэтому информационная система обязана обладать простым, удобным, легко осваиваемым интерфейсом, который должен предоставить конечному пользователю все необходимые для его работы функции, но в то же время не дать ему возможность выполнять какие-либо лишние действия [Кузнецов, 2001]. Информационная система (ИС) – это организационно-упорядоченная взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели. Такое понимание информационной системы предполагает использование в качестве основного технического средства переработки информации ЭВМ и средств связи, реализующих информационные процессы и выдачу информации, необходимой в процессе принятия решений задач из любой области. Современное понимание информационной системы предполагает использование персонального компьютера в качестве основного технического средства переработки информации. 37 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ИС невозможно представить без персонала, взаимодействующего с компьютерами и телекоммуникациями [Дик]. Иными словами, ИС – это человеко-машинная система, основанная на средствах вычислительной техники, математических методах, современных методах управления, которая имеет целью повышение эффективности предприятия путем обеспечения специалистов и руководителей качественной информацией. Информационная система является средой, составляющими элементами которой являются компьютеры, компьютерные сети, программные продукты, БД, люди, различного рода технические и программные средства связи и т.д. Хотя сама идея ИС и некоторые принципы их организации возникли задолго до появления компьютеров, однако компьютеризация в десятки и сотни раз повысила эффективность ИС и расширила сферы их применения. Информационные технологии (ИТ) тесно связаны с информационными системами, которые являются для них основной средой. Добавление к понятию «система» слова «информационная» отражает цель ее создания и функционирования. Реализация функций информационной системы невозможна без знания ориентированной на нее ИТ. Информационная технология может существовать и вне сферы ИС. Таким образом, ИТ является более емким понятием, отражающим современное представление о процессах преобразования информации в информационном обществе [Майстренко А.В., Майстренко Н.В.]. В зависимости от конкретной области применения информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Можно выделить основные свойства, которые являются общими для всех ИС. Основные свойства информационных систем: 1. Соответствие структуры ИС, ее функционального назначения поставленным целям. 2. Производство достоверной, надежной, своевременной и систематизированной информации, основанной на использовании БД, экспертных систем и баз знаний. Так как любая ИС предназначена для сбора, хранения и обработки информации, то в основе любой ИС лежит среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, которые соответствуют области применения ИС. 38 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 3. Контроль, понимание и использование ИС людьми в соответствии с основными принципами, реализованными в виде стандарта предприятия на ИС. Интерфейс пользователя ИС должен быть легко понимаем на интуитивном уровне. 4. Использование сетей передачи данных. ИС решают следующие основные задачи: 1. Поиск, обработка и хранение информации, которая долго накапливается и утрата которой невосполнима. Компьютеризованные ИС предназначены для более быстрой и надежной обработки информации, чтобы сэкономить время и расходы, избежать свойственных человеку случайных ошибок, сделать жизнь людей более комфортной. 2. Хранение данных разной структуры. Не существует развитой ИС, работающей с одним однородным файлом данных. Более того, разумным требованием к информационной системе является то, чтобы она могла развиваться. Могут появиться новые функции, для выполнения которых требуются дополнительные данные с новой структурой. При этом вся накопленная ранее информация должна остаться сохранной. Теоретически можно решить эту задачу путем использования нескольких файлов внешней памяти, каждый из которых хранит данные с фиксированной структурой. В зависимости от способа организации используемой системы управления файлами эта структура может быть структурой записи файла или поддерживаться отдельной библиотечной функцией, написанной специально для данной ИС. В результате развития большинства таких систем в них выделился отдельный компонент, который представляет собой разновидность системы управления базами данных (СУБД). 3. Анализ и прогнозирование потоков информации различных видов и типов, перемещающихся в обществе. Изучаются потоки с целью их минимизации, стандартизации и приспособления для эффективной обработки на вычислительных машинах, а также особенности потоков информации, протекающей через различные каналы распространения информации. 4. Исследование способов представления и хранения информации, создание специальных языков для формального описания информации различной природы, разработка специальных приемов сжатия и кодирования информации, аннотирования объемных документов и реферирования их. В рамках этого направления развиваются работы по созданию банков данных большого объема, 39 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ хранящих информацию из различных областей знаний в форме, доступной для вычислительных машин. 5. Построение процедур и технических средств для их реализации, с помощью которых можно автоматизировать процесс извлечения информации из документов, не предназначенных для вычислительных машин, а ориентированных на восприятие их человеком. 6. Создание информационно-поисковых систем, способных воспринимать запросы к информационным хранилищам, сформулированым на естественном языке, а также специальных языках запросов для систем такого типа. 7. Создание сетей хранения, обработки и передачи информации, в состав которых входят информационные банки данных, терминалы, обрабатывающие центры и средства связи. Конкретные задачи, которые должны решаться информационной системой, зависят от той прикладной области, для которой предназначена система. Области применения информационных приложений разнообразны: банковское дело, управление производством, медицина, транспорт, образование и т.д. Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности ИС, создаваемых в различных областях. Современные крупные проекты ИС характеризуются, как правило, несколькими особенностями. 1. Сложность описания – наличие достаточно большого количества функций, процессов, элементов данных и сложных взаимосвязей между ними, требующих тщательного моделирования и анализа данных и процессов. 2. Наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционные приложения, связанные с обработкой транзакций и решением регламентных задач, и приложения аналитической обработки (поддержки принятия решений), использующие нерегламентированные запросы к данным большого объема). 3. Отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем. 4. Необходимые интеграции существующих и вновь разрабатываемых приложений. 5. Функционирование в неоднородной среде на нескольких аппаратных платформах. 40 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 6. Разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств. 7. Существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС [Вендров]. 3.2. Классификация информационных систем Информационные системы классифицируются по разным признакам. I. Масштаб. 1. Одиночные – реализуются, как правило, на автономном персональном компьютере и рассчитаны на одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. 2. Групповые информационные системы – ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. 3. Корпоративные информационные системы – являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы и сети. II. Сфера применения. 1. Системы обработки транзакций. 2. Системы поддержки принятия решений. 3. Информационно-справочные системы. 4. Офисные информационные системы. III. Способ организации. 1. Системы на основе архитектуры файл – сервер. 2. Системы на основе архитектуры клиент – сервер. 3. Системы на основе многоуровневой архитектуры. 4. Системы на основе Интернет-технологий. IV. Области применения и реализации информационных систем. 1. Бухгалтерский учет – классическая и наиболее часто реализуемая на сегодняшний день область применения информационных технологий. 41 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 2. Управление финансовыми потоками – область, где внедрение информационных технологий обусловлено критичностью этой сферы управления предприятия к ошибкам. Неправильно построив систему расчетов с поставщиками и потребителями, можно спровоцировать кризис наличности даже при налаженной сети закупки, сбыта и хорошем маркетинге. И наоборот, точно просчитанные и жестко контролируемые условия финансовых расчетов могут существенно увеличить оборотные средства фирмы. 3. Управление складом, ассортиментом, закупками. Заморозить оборотные средства в чрезмерном складском запасе – самый простой способ сделать любое предприятие потенциальным инвалидом. Можно просмотреть перспективный товар, вовремя не вложить в него деньги. 4. Управление производственным процессом. Автоматизированное решение подобной задачи дает возможность правильно планировать, учитывать затраты, проводить техническую подготовку производства, оперативно управлять процессом выпуска продукции в соответствии с производственной программой. 5. Управление маркетингом. Подразумевается сбор и анализ данных о фирмах-конкурентах, их продукции и ценовой политике, а также моделирование параметров внешнего окружения для определения оптимального уровня цен, прогнозирования прибыли и планирования рекламных кампаний 6. Документооборот. Хорошо отлаженная система учетного документооборота отражает реально происходящую на предприятии текущую производственную деятельность и дает управленцам возможность воздействовать на нее. 7. Оперативное управление предприятием. Информационная система, решающая задачи оперативного управления предприятием, строится на основе базы данных, в которой фиксируется вся возможная информация о предприятии. Такая информационная система является инструментом для управления бизнесом и обычно называется корпоративной информационной системой. 8. Предоставление информации о фирме. Активное развитие Интернета привело к необходимости создания корпоративных серверов для предоставления различного рода информации о предприятии. Практически каждое уважающее себя предприятие сейчас имеет свой веб-сервер. Кроме того, использование веб-технологий открывает широкие перспективы для электронной коммерции и обслуживания покупателей через Интернет. 42 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Основные требования, предъявляемые к информационной системе – это гибкость, надежность, эффективность и безопасность. Гибкость – способность к адаптации и дальнейшему развитию, подразумевающая возможность приспособления информационной системы к новым условиям, новым потребностям предприятия. Требование надежности обеспечивается созданием резервных копий хранимой информации, выполнением операций протоколирования, поддержанием качества каналов связи и физических носителей информации, использованием современных программных и аппаратных средств. Система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на нее задачи в минимальные сроки. Эффективность системы обеспечивается оптимизацией данных и методов их обработки, применением оригинальных разработок, идей, методов проектирования. Под безопасностью, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют доступа к информационным ресурсам организации, кроме тех, которые для них предназначены. Требование безопасности обеспечивается современными средствами разработки информационных систем, современной аппаратурой, методами защиты информации, применением паролей и протоколированием, постоянным мониторингом состояния безопасности операционных систем и средств их защиты [Избачков, Петров]. 3.3. Профиль информационной системы При создании и развитии сложных, распределенных, тиражируемых информационных систем требуется гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций системы. Для унификации и регламентирования такие совокупности базовых стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, функций, процессов и компонентов системы. В связи с этим выделилось и сформировалось понятие профиля информационной системы как основного инструмента функциональной стандартизации. 43 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Профиль – это совокупность нескольких (или подмножество одного) базовых стандартов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций. Профиль формируется, исходя из функциональных характеристик объекта стандартизации. В профиле выделяются и устанавливаются допустимые возможности и значения параметров каждого базового стандарта и/или нормативного документа, входящего в профиль. Профиль не должен противоречить использованным в нем базовым стандартам и нормативным документам. Он должен применять выбранные из альтернативных вариантов необязательные возможности и значения параметров в пределах допустимых. На базе одной совокупности базовых стандартов могут формироваться и утверждаться различные профили для разных проектов информационных систем. Ограничения базовых документов профиля и их согласованность, проведенная разработчиками профиля, должны обеспечивать качество, совместимость и корректное взаимодействие отдельных компонентов системы, соответствующих профилю, в заданной области его применения. Базовые стандарты и профили в зависимости от проблемно-ориентированной области применения информационных систем могут использоваться как непосредственные директивные, руководящие или рекомендательные документы, а также как нормативная база, необходимая при выборе или разработке средств автоматизации технологических этапов или процессов создания, сопровождения и развития информационных систем. Обычно рассматривают две группы профилей: – регламентирующие архитектуру и структуру информационной системы; – регламентирующие процессы проектирования, разработки, применения, сопровождения и развития системы. В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения: – профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта; – профили информационной системы, предназначенные для решения некоторого класса прикладных задач. 44 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Профили информационных систем унифицируют и регламентируют только часть требований характеристик, показателей качества объектов и процессов, выделенных и формализованных на базе стандартов и нормативных документов. Другая часть функциональных и технических характеристик системы определяется заказчиками и разработчиками творчески, без учета положений нормативных документов [Липаев, Филинов]. Использование профилей информационных систем призвано решить следующие задачи: – снижение трудоемкости проектов; – повышение качества компонентов информационной системы; – обеспечение расширяемости и масштабируемости разрабатываемых систем; – обеспечение возможности функциональной интеграции в информационную систему задач, которые раньше решались раздельно; – обеспечение переносимости прикладного программного обеспечения. В зависимости от того, какие из указанных задач являются наиболее приоритетными, производится выбор стандартов и документов для формирования профиля. Актуальность использования профилей информационных систем обусловлена современным состоянием стандартизации информационных технологий, которое характеризуется следующими особенностями: 1. Существует множество международных и национальных стандартов, которые не полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и применения сложных информационных систем. 2. Длительные сроки разработки, согласования и утверждения международных и национальных стандартов приводят к их консерватизму и хроническому отставанию от современных информационных технологий. 3. Функциональными стандартами поддержаны и регламентированы только самые простые объекты и рутинные, массовые процессы: телекоммуникации, программирование, документирование программ и данных. Наиболее сложные и творческие процессы создания и развития крупных распределенных информационных систем – системный анализ и проектирование, интеграция компонентов и систем, испытания и сертификация – почти не поддержаны требованиями и рекомендациями стандартов из-за трудности их формализации и унификации. 45 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 4. Совершенствование и согласование нормативных и методических документов в ряде случаев позволяют создать на их основе национальные и международные стандарты. Подходы к формированию профилей информационных систем могут быть различными. В международной функциональной стандартизации информационных технологий принято довольно жесткое понятие профиля. Считается, что его основой могут быть только международные и национальные утвержденные стандарты. Использование стандартов де-факто и нормативных документов фирм не допускается. При таком подходе затруднены унификация, регламентирование и параметризация множества конкретных функций и характеристик сложных объектов архитектуры и структуры современных информационных систем. Другой подход к разработке и применению профилей информационных систем состоит в использовании совокупности адаптированных и параметризованных базовых международных и национальных стандартов и открытых спецификаций, отвечающих стандартам де-факто и рекомендации международных консорциумов. Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы – Application Program Interface (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды системы. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде профилей компонентов системы. Таким образом, профили информационной системы с иерархической структурой могут включать в себя: – стандартизованные описания функций, выполняемых данной системой; – функции взаимодействия системы с внешней для нее средой; – стандартизованные интерфейсы между приложениями и средой информационной системы; – профили отдельных функциональных компонентов, входящих в систему. 46 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Для эффективного использования конкретного профиля необходимо: – выделить объединенные логической связью проблемно-ориентированные области функционирования, где могут применяться стандарты, общие для одной организации или группы организаций; – идентифицировать стандарты и нормативные документы, варианты их использования и параметры, которые необходимо включить в профиль; – документально зафиксировать участки конкретного профиля, где требуется создание новых стандартов или нормативных документов, и идентифицировать характеристики, которые могут оказаться важными для разработки недостающих стандартов и нормативных документов этого профиля; – формализовать профиль в соответствии с его категорией, включая стандарты, различные варианты нормативных документов и дополнительные параметры, которые непосредственно связаны с профилем; – опубликовать профиль и/или продвигать его по формальным инстанциям для дальнейшего распространения. При использовании профилей важное значение имеет обеспечение проверки корректности их применения путем тестирования, испытаний и сертификации. Для этого требуется создание технологии контроля и тестирования в процессе применения профиля. Данная технология должна поддерживаться совокупностью методик, инструментальных средств, составом и содержанием оформляемых документов на каждом этапе выполнения проекта [Двоеглазов и др.]. Использование профилей способствует унификации при разработке тестов, проверяющих качество и взаимодействие компонентов проектируемой информационной системы. Профили должны определяться таким образом, чтобы тестирование их реализации можно было проводить по возможности наиболее полно по стандартизованной методике. При этом возможно применение ранее разработанных методик, так как международные стандарты и профили являются основой для создания общепризнанных аттестационных тестов. Формирование и применение профилей конкретных информационных систем выполняется на основе использования международных и национальных стандартов, ведомственных нормативных 47 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ документов, а также стандартов де-факто при условии доступности соответствующих им спецификаций. Для обеспечения корректного применения профилей их описания должны содержать: – определение целей использования данного профиля; – точное перечисление функций объекта или процесса стандартизации, определяемого данным профилем; – формализованные сценарии применения базовых стандартов и спецификаций, включенных в данный профиль; – сводку требований к информационной системе или ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия; – нормативные ссылки на конкретный набор стандартов и других нормативных документов, составляющих профиль, с точным указанием применяемых редакций и ограничений, способных повлиять на достижение корректного взаимодействия объектов стандартизации при использовании данного профиля; – информационные ссылки на все исходные документы. На стадиях жизненного цикла информационной системы выбираются и затем применяются основные функциональные профили: – профиль прикладного программного обеспечения; – профиль среды информационной системы; – профиль защиты информации в информационной системе; – профиль инструментальных средств, встроенных в информационную систему. 3.3.1. Профиль прикладного программного обеспечения Прикладное программное обеспечение всегда является проблемно-ориентированным и определяет основные функции информационной системы. Функциональные профили системы должны включать в себя согласованные базовые стандарты. При использовании функциональных профилей информационных систем следует еще иметь в виду согласование этих профилей между собой. Необходимость такого согласования возникает, в частности, при использовании стандартизованных API, в том числе интерфейсов приложений со средой их функционирования и со средствами защиты информации. При согласовании функциональных профилей возможны также уточнения профиля среды системы и профиля встраиваемых инструментальных средств создания, сопровождения и развития прикладного программного обеспечения. 48 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 3.3.2. Профиль среды информационной системы Профиль среды информационной системы должен определять ее архитектуру в соответствии с выбранной моделью обработки данных. Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по функциональным областям эталонной модели OSE/RM: – область графического пользовательского интерфейса; – область реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных); – область операционных систем с учетом сетевых функций, выполняемых на уровне операционной системы; – область телекоммуникационной среды в части услуг и служб прикладного уровня: электронной почты, доступа к удаленным базам данных, передачи файлов, доступа к файлам и управления файлами. Профиль среды распределенной системы должен включать стандарты протоколов транспортного уровня, стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3), а также стандарты средств сопряжения проектируемой информационной системы с сетями передачи данных общего назначения. Выбор аппаратных платформ информационной системы связан с определением их параметров: вычислительной мощности серверов и рабочих станций в соответствии с проектными решениями по разделению функций между клиентами и серверами; степени масштабируемости аппаратных платформ; надежности. Профиль среды должен содержать стандарты, определяющие параметры технических средств и способы их измерения (например, стандартные тесты измерения производительности). 3.3.3. Профиль защиты информации Профиль защиты информации должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в 49 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ соответствии с требуемой категорией безопасности и критериями безопасности, заданными в техническом задании на систему. Построение профиля защиты информации в распределенных системах «клиент – сервер» методически связано с точным определением компонентов системы, ответственных за те или иные функции, службы и услуги, и средств защиты информации, встроенных в эти компоненты. Функциональная область защиты информации включает в себя следующие функции защиты, реализуемые разными компонентами системы: – функции, реализуемые операционной системой; – функции защиты от несанкционированного доступа, реализуемые на уровне программного обеспечения промежуточного слоя; – функции управления данными, реализуемые СУБД; – функции защиты программных средств, включая средства защиты от вирусов; – функции защиты информации при обмене данными в распределенных системах, включая криптографические функции; – функции администрирования средств безопасности. Профиль защиты информации должен включать указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей. Профиль должен также включать указания на методы и средства резервного копирования информации и восстановления информации при отказах и сбоях аппаратуры системы. 3.3.4. Профиль инструментальных средств Профиль инструментальных средств, встроенных в информационную систему, должен отражать решения по выбору методологии и технологии создания, сопровождения и развития информационной системы. В этом профиле должны содержаться ссылки на описание выбранных методологии и технологии, выполненное на стадии эскизного проектирования системы. Состав инструментальных средств определяется на основании решений и нормативных документов об организации сопровождения и развития информационной системы. При этом должны быть учтены правила и порядок, регламентирующие внесение изменений в действующие системы. Функциональная область профиля инструментальных средств, встроенных в систему, охватывает функции централизованного управления и администрирования, связанные: 50 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – с контролем производительности и корректности функционирования системы в целом; – управлением конфигурацией прикладного программного обеспечения, тиражированием версий; – управлением доступом пользователей к ресурсам системы и конфигурацией ресурсов; – перенастройкой приложений в связи с изменениями прикладных функций информационной системы; – настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов); – ведением баз данных системы; – восстановлением работоспособности системы после сбоев и аварий. Дополнительные ресурсы, необходимые для функционирования встроенных инструментальных средств, такие как минимальный и рекомендуемый объем оперативной памяти, размеры требуемого дискового пространства и т.п., должны быть учтены в разделе проекта, относящемся к среде информационной системы. Выбор инструментальных средств, встроенных в систему, должен производиться в соответствии с требованиями профиля среды. Ссылки на соответствующие стандарты, входящие в профиль среды, должны содержаться и в профиле инструментальных средств. В этом профиле должны также содержаться ссылки на требования к средствам тестирования, которые необходимы для процессов сопровождения и развития системы и должны быть в нее встроены. В число встроенных в информационную систему средств тестирования должны входить средства функционального тестирования приложений, тестирования интерфейсов, системного тестирования и тестирования серверов/клиентов при максимальной нагрузке. 51 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 4. СОВРЕМЕННЫЕ ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ Ведущие специалисты в области человеко-машинных компьютерных систем уже в середине 70-х годов осознали необходимость формирования единых подходов к реализации пользовательского интерфейса. В настоящее время солидные фирмы серьезно относятся к проблемам интерфейса. Существуют специальные организации, отвечающие за разработку стандартов [Будаева]. Американский национальный институт стандартов (ANSI) имеет по данному направлению специальную консультативную группу – Комитет по стандартам интерфейса «человек-компьютер» (The Human-Computer Interface Standard Committee). Среди международных организаций можно назвать, например, Международный консультативный комитет по телеграфии и телефонии (International Telegraph and Telephone Consultation Committee), изучающий особенности интерактивных элементов интерфейса. В 1987 году IBM положила начало создания единой среды разработки приложений – Systems Application Architecture (SAA). Данный проект предусматривал не только разработку единых принципов создания приложений, но и «материализацию» этих принципов на основе соответствующей технологической базы. Проект SAA содержит четыре компонента: – Соглашения по интерфейсу пользователя – CUA (Common User Access); – Соглашения по программному интерфейсу – CPI (Common Programming Interface); – Соглашения по разработке приложений – CA (Common Applications); – Соглашения по коммуникациям – CCS (Common Communications Support). В качестве технологической базы для реализации соглашений по пользовательскому интерфейсу было предложено конкретное 52 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ инструментальное средство – Programming Toolkit для операционной системы OS/2. Первоначально в разработке проекта SAA участвовали преимущественно фирмы IBM и Microsoft. Основные положения проекта воплотились корпорацией IBM применительно к OS/2, а фирмой Microsoft – в рамках семейства OC Windows. В марте 1997 года фирма Microsoft выпустила пакет Visual Studio 97, в который вошли все созданные ею инструментальные средства разработки приложений, а также средства автоматизации сопровождения программных продуктов Visual SourceSafe. Поскольку разработка интерфейса является необходимой частью разработки любого программного обеспечения, основные требования к интерфейсам можно найти в стандартах, посвященных жизненному циклу программных средств. Примерами таких стандартов являются следующие: – MIL-STD-498 – стандарт разработки ПО Министерства обороны США; – ISO/IEC 12207:1995 «Процессы жизненного цикла программных средств». Нормативы затрагивают три области проектирования интерфейсов: физическую, синтаксическую и семантическую. Физическая область относится к аппаратному обеспечению программного пользовательского интерфейса. Синтаксическая область обобщает правила размещения информации на экране и последовательности действий пользователя. Семантическая раскрывает сущность элементов и действий, составляющих часть интерфейса (например, Exit – конец взаимодействия с диалоговым окном, выход из программы; Cancel – остановка любого незаконченного действия и возврат на шаг назад). Технология построения пользовательского интерфейса и инструментальные средства, используемые для ее реализации, образуют единое целое. Очередной шаг в развитии любой из этих составляющих дает толчок к дальнейшему развитию другой. Средства визуальной разработки были созданы практически для всех популярных языков программирования, а также для вновь появившихся. Все эти инструменты обладают двумя основными достоинствами: во-первых, существенно повышают производительность труда программиста и, во-вторых, обеспечивают стандартизацию пользовательского интерфейса за счет использования однотипных базовых элементов. В результате, глядя на готовое 53 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ приложение, практически невозможно определить, на каком языке и с помощью какого инструмента оно было создано. Наиболее удачно реализованные инструменты визуального программирования позволяют не только формировать облик отдельных окон и диалоговых панелей, но и представлять в наглядной форме взаимосвязь между элементами пользовательского интерфейса. Как и до появления средств визуального программирования особое место среди других проблемно-ориентированных систем разработки занимают СУБД. Применение в них технологии WYSIWYG позволило им практически сравняться по мощности и эффективности с универсальными инструментами разработки GUI-приложений. Кроме того, наличие в СУБД средств визуального представления инфологической модели данных позволяет создавать более корректную модель пользовательского интерфейса по сравнению с универсальными инструментами. Интерфейс систем реального времени имеет целый ряд существенных особенностей. Для его построения используются, как правило, специализированные инструментальные средства. Они сформировались в результате слияния SCADA-систем (Supervisory Control and Data Acquisition system – система сбора данных и оперативного диспетчерского управления) и средств визуального программирования общего назначения на базе одного из универсальных языков. Такой симбиоз получил название HMI/SCADA-систем (или MMI/SCADA). В настоящее время такие инструментальные средства существуют практически для всех платформ, на базе которых разрабатываются системы реального времени. Несмотря на огромные потенциальные возможности систем визуального программирования, они в большинстве своем обладают одним существенным недостатком – в них не предусмотрена поддержка проектирования, разработки и сопровождения создаваемых приложений как единого технологического процесса. Это обстоятельство зачастую негативно влияет как на уровень программного продукта в целом, так и на качество его пользовательского интерфейса. Осознание этого факта привело к тому, что разработчики инструментов стали дополнять их относительно самостоятельными компонентами, поддерживающими отдельные этапы жизненного цикла программных продуктов. Появились специализированные инструменты тестирования GUI-приложений. Наиболее мощным из них считается продукт 54 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Rational Performance Suite фирмы Rational Rose. Данное средство обеспечивает автоматическую генерацию тестов, имитирующих работу пользователя, а также регистрацию и анализ результатов тестирования приложения, прежде всего с точки зрения качества пользовательского интерфейса. Тем не менее, в инструментах визуального программирования поддержку получают в основном этапы жизненного цикла, относящиеся к разработке и реализации приложений, и в значительно меньшей степени – к этапам проектирования. Указанного недостатка лишены так называемые CASE-системы (Computer Aided Software Engineering – компьютерное проектирование программного обеспечения). Обязательным атрибутом такой системы является автоматическая (или автоматизированная) генерация программного кода на основе спецификации. Особенностью CASE-систем является поддержка практически всех этапов жизненного цикла создаваемого приложения: – стратегическое планирование (описание целей, факторов, ресурсов; моделирование стратегии; формирование структуры плана и политики фирмы-разработчика); – описание предметной области (описание объектов предметной области и отношений между ними; интеграция различных моделей предметной области); – анализ возможностей реализации (анализ существующих проектов); – определение требований (моделирование потоков данных; создание и анализ прототипов; контроль полноты и согласованности требований); – системное проектирование (декомпозиция и сборка проекта, имитационное моделирование создаваемого приложения); – программирование (генерация кода и анализ его метрических характеристик); – тестирование (автоматическая генерация контрольных примеров, регистрация и анализ результатов тестирования); – документирование (создание и сопровождение библиотеки спецификаций); – сопровождение и управление проектом. Таким образом, применение CASE-систем способствует проектированию и реализации пользовательского интерфейса, обладающего требуемыми свойствами. Некоторые из таких систем имеют в своем составе компоненты, предназначенные специально для раз55 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ работки пользовательского интерфейса создаваемого приложения. Таким продуктом является CASE/4/0 фирмы MicroTOOL GmbH. Он содержит «дизайнер диалогов», обеспечивающий создание и моделирование пользовательского интерфейса. Такие инструментальные компьютерные средства предоставляют такие возможности, повышающие эффективность реинжиниринга, как: – систематизация информации о проекте и его компонентах, что облегчает внесение дополнений и изменений, позволяет отслеживать процесс принятия решений, упрощает верификацию проекта и сопутствующей ему документации; – визуальное моделирование, заменяющее разработчику бумагу и карандаш на компьютер и позволяющее формировать графический проект в интерактивном режиме с использованием визуальных средств (диаграмм, блок-схем, графов), дополненный различного рода описаниями (спецификациями, словарями); – анализ построенных моделей, включая возможность просчитать стоимостные и временные характеристики различных процессов, проверить гипотезы «что, если…», проверить возможные последствия различных ситуаций и т.д.; – поддержка коллективной работы – возможность параллельной разработки отдельных компонент проекта различными группами разработчиков с возможностью интеграции результатов в один общий проект; – использование типовых решений – использование ранее накопленного опыта при принятии решений, а также использование готовых типовых компонент; – автоматическое создание компонент системы, например автоматическая кодогенерация (создание компьютерных программ, баз данных на основе введенных моделей и диаграмм), формирование различного рода отчетов, документации по заданному шаблону и т.д. Большинство современных консалтинговых фирм при проведении реинжиниринга используют CASE-средства. Первоначально термин CASE расшифровывался как Computer Aided Software Engineering – компьютерная поддержка проектирования программного обеспечения, т.к. CASE-средства представляли собой инструментальные системы для автоматизации разработки компьютерных программ. Поскольку составной частью разработки программных систем является создание моделей автоматизируемой предметной области, то все больше CASE-средств стало ори56 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ентироваться на моделирование и проектирование сложных систем широкого назначения. Постепенно понятие CASE приобрело новый смысл и все чаще стало расшифровываться как – Computer Aided System Engineering – компьютерная поддержка проектирования систем [Калянов]. Современный рынок CASE-средств насчитывает сотни систем, различающихся по функциональным возможностям. Большинство средств ориентировано на достаточно узкий диапазон функций: либо это средства для построения функциональных моделей, либо для проектирования баз данных, либо для управления проектом и т.д. Однако в последнее время идет активное развитие интегрированных многофункциональных средств. Такие средства поддерживают широкий спектр функций, начиная от построения и анализа моделей бизнеса и заканчивая автоматическим или автоматизированным программированием. При реализации больших проектов по реинжинирингу рекомендуется использовать именно эти средства. Однако, как правило, эти средства достаточно дороги, сложны для использования, требуют длительного обучения работе с ними. В современных CASE-пакетах используются практически все известные методологии проектирования. По некоторым оценкам примерно четверть известных CASE-средств поддерживает лишь одну методологию, столько же поддерживает 2-3 методологии. Имеются пакеты, поддерживающие 7 и более методологий. Существуют средства, не поддерживающие ни одной методологии проектирования (средства управления проектом, средства планирования) и средства, не зависимые от методологий, т.е. обладающие исключительными возможностями по адаптации к любым методам. Немаловажное значение для распространения CASE-средств имеют вычислительные платформы, на которых они реализуются. Немаловажную роль играет многопользовательский доступ к инструментарию. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современ57 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями: – мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; – интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС; – использование специальным образом организованного хранилища проектных метаданных (репозитория). Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам: – применяемые методологии и модели систем и БД; – степень интегрированности с СУБД; – доступные платформы. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: – средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works)); 1. Средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE-Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных. 58 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 2. Средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV. 3. Средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично в Silverrun. 4. Средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают: – средства планирования и управления проектом (SE Companion, Microsoft Project и др.); – средства конфигурационного управления (PVCS (Intersolv)); – средства тестирования (Quality Works (Segue Software)); – средства документирования (SoDA (Rational Software)) [Вендров]. Рассмотрим еще один подход к классификации CASE-средств. I. Средства управления проектом. Используются на подготовительном этапе BPR для планирования хода выполнения работ, а также для сопровождения проекта (контроля и корректировки планов выполнения работ). Кроме того, средства этой категории могут быть использованы на этапах обратного и прямого инжиниринга для создания модели бизнес-процесса в виде последовательности работ. Основные функции: 1. Формирование календарных графиков работ, построение диаграммы Ганта и сетевых графиков. При этом можно задавать 59 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ различные связи между работами: выполнение работы может допускаться по завершении другой работы, при наступлении определенного момента времени и доступности ресурса и т.д. 2. Управление ресурсами, включающее возможность задавать распределение ресурсов между работами во времени, строить диаграммы ресурсов, проводить анализ их загруженности, автоматически перераспределять ресурсы. 3. Управление затратами, позволяющее рассчитывать финансовые показатели проекта, например составление бюджета проекта, учитывающего затраты труда, расход материалов и накладные расходы. К ним можно отнести: CA-SuperProject (Computer Associates International), Microsoft Project (Microsoft), Time Line (Symantec). II. Средства создания диаграмм. Это средства, используемые на этапах визуализации, обратного и прямого инжиниринга для формирования статических моделей существующего и нового бизнеса. Кроме того, средства этой категории используются при разработке информационной системы нового бизнеса. Основные функции: 1. Формирование функциональной модели бизнеса или информационной системы. Наиболее распространенный метод реализации данной функции – метод SADT (технология IDEF0), позволяющий описать бизнес-процесс или процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями. 2. Формирование информационной модели бизнес-процессов, в том числе выделение объектов бизнеса, описание их поведения и связей друг с другом. Наиболее распространенный метод реализации данной функции – метод IDEF1X, с помощью которого создается описание информационного пространства выполнения бизнес-процессов, содержащего информационные объекты (сущности), их свойства (атрибуты), отношения с другими объектами (связи). 3. Анализ эффективности организации бизнеса, включающий выделение показателей эффективности бизнес-процессов, функционально-стоимостной анализ, выделение центров затрат, анализ загрузки и распределения ресурсов. Наиболее распространенный 60 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ метод реализации данной функции – метод ABC (Activity Based Costing – функционально-стоимостной анализ) – метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах. Большинство CASE-средств поддерживает лишь одну из выше перечисленных функций. Примеры инструментальных средств: Design/IDEF (Meta Software), BPWin (Logic Works), EasyABC (ABC Technologies), Staffware (Staffware plc). III. Средства имитационного моделирования/анимации. Средства этой категории используются на этапах визуализации, обратного и прямого инжиниринга для анализа динамики бизнеспроцессов как существующего, так и нового бизнеса. Основные функции: 1. Построение потоковых диаграмм, в которых представлены основные рабочие процедуры бизнеса и описано их поведение, а также информационные и материальные потоки между ними. При описании потоков учитываются различные метрики (например, частота появления заявок, время выполнения каждой рабочей процедуры, время передачи выходных данных и т.д.). 2. «Проигрывание» моделей в сжатом времени или пошаговом режиме, изменение характеристик потоков и распределения ресурсов по принципу «что, если». При этом используются анимационные эффекты для демонстрации работы модели. Наиболее распространенный метод имитационного моделирования – CPN (Color Petri Nets – раскрашенные сети Петри) – методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов для входящих потоков различной структуры. Примеры инструментальных средств: ServiceModel (ProModel), ReThink (Gensym), ModSym (CASI). IV. Средства создания информационных систем. Это средства, используемые на этапе прямого инжиниринга для разработки информационных систем в составе новых бизнес-процессов. Основные функции: 1. Формирование функциональной структуры (архитектуры) информационной системы. Наиболее распространенный метод ре61 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ализации данной функции – DFD (Data Flow Diagrams – диаграммы потоков данных) – методология структурно-функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных. 2. Структурирование (моделирование) данных, в том числе создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили метод построения ER (Entity-Relationship) диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development). 3. Быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств. Примеры инструментальных средств: S-Designor (PowerSoft), CASE Designer (Oracle), Power Builder, Rational Rose (Rational Software). V. Интегрированные многофункциональные средства. Это средства, автоматизирующие все основные этапы BPR, начиная от планирования работ по проекту, формирования статических и динамических моделей существующего и нового бизнеса и заканчивая формированием информационной системы поддержки нового бизнеса. Основные функции: 1. Спецификация бизнес-процессов, построение и анализ функциональной, структурной моделей бизнеса (поддержка методологии IDEF, потоки работ в сочетании с объектной ориентацией и т.д.). 2. Возможности имитационного моделирования. 3. Включение средств разработки приложений или стыковка с RAD-средствами. Кроме того, средства данной категории, как правило, поддерживают многопользовательский доступ к инструментарию. Некоторые средства используют методы инженерии знаний (экспертных систем), позволяющие представлять в моделях плохо формализуемые, эвристические знания экспертов о бизнес-процессах. Примеры инструментальных средств: G2 (Gensym), SPARKS (Coopers & Lybrand). 62 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASEсредствами: а) Vantage Team Builder (Westmount I-CASE); б) Rational Rose; в) Designer/2000; г) Silverrun; д) ERwin+BPwin; е) S-Designor; ж) CASE-Аналитик. 63 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 5. СТРУКТУРНЫй ПОДХОД В ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВАХ 5.1. Принципы структурного подхода Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и т.д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие: – принцип «разделяй и властвуй» – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; – принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: – принцип абстрагирования, заключающийся в выделении существенных аспектов системы и отвлечении от несущественных; 64 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – принцип формализации, заключающийся в необходимости строгого методического подхода к решению проблемы; – принцип непротиворечивости, заключающийся в обоснованности и согласованности элементов; – принцип структурирования данных, заключающийся в том, что данные должны быть структурированы и иерархически организованы [Маклаков]. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: – SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; – DFD (Data Flow Diagrams) диаграммы потоков данных. 5.2. Методология SADT Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США [Вендров]. МетодологияSADTпредставляетсобойсовокупностьметодов,правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях. 1. Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются. 2. Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. 65 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Правила SADT включают: – ограничение количества блоков на каждом уровне декомпозиции (3-6 блоков); – связность диаграмм (номера блоков); – уникальность меток и наименований (отсутствие повторяющихся имен); – синтаксические правила для графики (блоков и дуг); – разделение входов и управлений (правило определения роли данных); – отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Рассмотрим три основных методологии SADT. 1. С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показываются информационные, людские и производственные ресурсы, потребляемые каждой работой. 2. С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями. 3. С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса [Гурьев и др.]. 5.2.1. Концепция IDEF0 Наиболее удобным языком моделирования бизнес-процессов является IDEF0. В IDEF0 система представляется как совокупность взаимодействующих работ и функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. 66 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Результатом применения методологии является модель, построенная с четко сформулированной целью и с единой точкой зрения, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Модель не может быть построена без четко сформулированной цели (purpose). Цель должна отвечать на следующие вопросы: а) почему этот процесс должен быть замоделирован? б) что должна показать модель? Точку зрения (Viewpoint) можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Основными элементами концепции являются работы и связи между ними. Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы на диаграммах изображаются прямоугольниками (рис. 5.1). Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Порядок подачи заявки Заявка клиента Рыночные условия Оформление заявки для биржи Контракт Брокер Рис. 5.1. Работа Диаграммы декомпозиции содержат дочерние работы. Работы никогда не размещаются на диаграмме случайным образом. Они размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий – в правом нижнем углу. В результате получается «ступенчатая» схема. 67 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: А1 будет указывать на наибольшее доминирование, А2 – на следующее после наибольшего и т.д. Блок любой диаграммы далее может быть описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм (рис. 5.2). Более общее представление А-0 Более детальное представление 1 2 3 4 А0 Эта диаграмма является «родителем» этой диаграммы 41 42 43 А4 Декомпозиция функции 42 421 422 А42 423 Рис. 5.2. Иерархия диаграмм 68 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Взаимодействие работ между собой и внешним миром описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, сырье). В IDEF0 различают 5 типов стрелок (рис. 5.3). 1. Вход (Input) – материал или информация, которые используются или преобразуются работой для получения результата (выхода). Работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы. 2. Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. 3. Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. 4. Механизм (Mechanism) – ресурсы, которые выполняют работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. 5. Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. Исходные данные в стандартном представлении (рабочие материалы, результаты предыдущей операции) Методические материалы, инструкции и стандарты, критерии оценки результатов Техническая операция Результаты в стандартном представлении Исполнители, программные и техничексие средства Вызов Рис. 5.3. Функциональный блок и интерфейсные дуги 69 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Взаимодействие между блоками изображается дугами. Существует 5 видов взаимосвязей между блоками. 1. Выход – Вход (Output – Input). Выход одного блока является входом другого. Связь по входной обратной связи имеет место тогда, когда выход одного блока становится входом другого блока с большим доминированием. 2. Выход – Управление (Оutput – Сontrol). Выход одного блока является управляющим воздействием другого. 3. Выход – Механизм (Оutput – Mechanism). Выход одного блока является средством другого. 4. Выход – Механизм – Обратная связь (Output – MechanismFeedback). 5. Выход – Управление – Обратная связь (Output – Control – Feedback). Обратная связь по управлению возникает тогда, когда выход некоторого блока влияет на блок с большим доминированием. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. Стрелки в IDEF0, как правило, изображают наборы предметов, поэтому они могут разветвляться и соединяться вместе различным образом. Разветвления стрелки означают, что часть ее содержимого (или весь набор предметов) может появиться в каждом ответвлении стрелки. Стрелка всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждое ответвление стрелки может быть помечено в соответствии со следующими правилами: считается, что непомеченная ветвь содержит все предметы, указанные в метке перед разветвлением; каждая метка ветви уточняет, что именно содержит эта ветвь. Слияние стрелок указывает, что содержимое каждой ветви участвует в формировании после слияния объединенной стрелки. После слияния стрелка всегда помечается для указания нового набора, кроме того, каждая ветвь перед слиянием может помечаться в соответствии со следующими правилами: считается, что непомеченные ветви содержат все предметы, указанные в общей метке после слияния; каждая метка уточняет, что именно содержит эта ветвь. 5.2.2. Концепция DFD Диаграммы потоков данных (Data flow diagramming – DFD) используются для описания документооборота и обработки информации. DFD описывает: 70 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – функции обработки информации (работы); – документы (стрелки), объекты, сотрудников или отделы, которые участвуют в обработке информации; – внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границей моделируемой системы; – таблицы для хранения документов (хранилища данных). Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии определяют основные процессы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором они становятся элементарными и декомпозировать их далее оказывается невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов, хранение объектов, поставка и распространение объектов. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Таким образом, основными компонентами диаграмм потоков данных являются: – работы; – внешние сущности; – стрелки (потоки данных); – хранилище данных. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Работы изображаются прямоугольни71 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ками со скругленными углами. Их смысл совпадает со смыслом работ IDEF0, они также имеют входы и выходы, но не поддерживают управления и механизмы. Внешние сущности изображают входы в систему и/или выходы из системы. Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы (рис. 5.4). Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Директор Рис. 5.4. Внешняя сущность Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD применяются двунаправленные стрелки для описания диалогов типа «команда – ответ» между работами, между работой и внешней сущностью и между внешними сущностями (рис. 5.5). Банк Информация о клиенте/ Номер счета Регистрация счета налогоплатильщика Рис. 5.5. Диалог типа «команда – ответ» В DFD стрелки могут сливаться и разветвляться, что позволяет описывать декомпозицию стрелок. Каждый новый сегмент сливающейся и разветвляющейся стрелки может иметь свое собственное имя. 72 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. Хранилища данных могут быть реализованы физически в виде ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Хранилища данных на диаграмме потоков данных изображаются, как показано на рисунке 5.6. D1 Получаемые счета Рис. 5.6. Накопитель данных В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. 5.2.3. Концепция IDEF3 Диаграммы IDEF3 могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации. Под сценарием будем понимать повторяющуюся последовательность ситуаций или действий, которые описывают типичный класс проблем, присутствующих в организации или системе, описание последовательности свойств объекта, в рамках рассматриваемого процесса. IDEF3 представляет инструментарий для наглядного исследования и моделирования сценариев выполнения процессов. Метод позволяет проводить описание с необходимой степенью подробности посредством использования декомпозиции. IDEF3 как инструмент моделирования фиксирует следующую информацию о процессе: – объекты, которые участвуют при выполнении сценария; – роли, которые выполняют эти объекты (например, агент, транспорт и т.д.); – отношения между работниками в ходе выполнения сценария процесса; – состояния и изменения, которым подвергаются объекты; – время выполнения и контрольные точки синхронизации работ; – ресурсы, которые необходимы для выполнения работ. 73 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Unit of Work (UOW), также называемые работами, являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, обозначающее процесс действия. Связи показывают взаимоотношение работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Model/Default Arrow Types. 1. Старшая (Precedence) – сплошная линия, связывающая единицы работ. Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется. 2. Отношения (Relational Link) – пунктирная линия, использующаяся для изображения связей между единицами работ (работацель начинается, когда работа-источник еще не закончилась), а также между единицами работ и объектами ссылок. 3. Потоки объектов (Object Flow) – стрелка с двумя наконечниками. Она применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой. Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка. Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ – работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник. Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки (Junction) используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом 74 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может одновременно использоваться для слияния и разветвления. Различают несколько типов перекрестков (табл. 5.1). Таблица 5.1 Наименование Смысл в случае слияния стрелок (Fan-in Junction) Asynchronous (AND) Все предшествующие процессы должны быть завершены Synchronous (AND) Все предшествующие процессы завершены одновременно Asynchronous (OR) Один или несколько предшествующих процессов должны быть завершены Synchronous (OR) Один или несколько предшествующих процессов завершены одновременно XOR (Exclusive OR) Только один предшествующий процесс завершен Смысл в случае разветвления стрелок (Fan-out Junction) Все следующие процессы должны быть запущены Все следующие процессы запускаются одновременно Один или несколько следующих процессов должны быть запущены Один или несколько следующих процессов запускаются одновременно Только один следующий процесс запускается Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 5.7). Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. В качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Загрузка из бункера OBJECT/БУНКЕР Рис. 5.7. Объект ссылки 75 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 6. ОбЪЕКТНО-ОРИЕНТИРОВАННЫй ПОДХОД В ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВАХ 6.1. CASE-метод баркера Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы «сущность – связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах Баркера. Метод Баркера будет излагаться на примере моделирования деятельности компании по торговле автомобилями. Ниже приведены выдержки из интервью, проведенного с персоналом компании. Главный менеджер: «Одна из основных обязанностей – содержание автомобильного имущества. Он должен знать, сколько заплачено за машины и каковы накладные расходы. Обладая этой информацией, он может установить нижнюю цену, за которую мог бы продать данный экземпляр. Кроме того, он несет ответственность за продавцов и ему нужно знать, кто что продает и сколько машин продал каждый из них». Продавец: «Ему нужно знать, какую цену запрашивать и какова нижняя цена, за которую можно совершить сделку. Кроме того, ему нужна основная информация о машинах: год выпуска, марка, модель и т.п.». Администратор: «Его задача сводится к составлению контрактов, для чего нужна информация о покупателе, автомашине и про76 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ давце, поскольку именно контракты приносят продавцам вознаграждения за продажи» [Вендров]. Первый шаг моделирования – извлечение информации из интервью и выделение сущностей. <имя сущности> Рис. 6.1. Графическое изображение сущности Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рис. 6.1). Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами: 1. Иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами. 2. Обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь. 3. Обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. 4. Обладать любым количеством связей с другими сущностями модели. Обращаясь к приведенным выше выдержкам из интервью, видно, что сущности, которые могут быть идентифицированы с главным менеджером, – это автомашины и продавцы. Продавцу важны автомашины и связанные с их продажей данные. Для администратора важны покупатели, автомашины, продавцы и контракты. Исходя из этого, выделяются четыре сущности (автомашина, продавец, покупатель, контракт), которые изображаются на диаграмме так, как это представлено на рисунке 6.2. Автомашина Продавец Покупатель Контракт Рис. 6.2. Выделенные сущности Следующим шагом моделирования является идентификация связей. 77 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности-родителя. Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка. Например, связь продавца с контрактом может быть выражена следующим образом: – продавец может получить вознаграждение за один или большее число контрактов; – контракт должен быть инициирован одним продавцом. Степень связи и обязательность графически изображаются так, как это представлено на рисунке 6.3. Много Необязательная Один Обязательная Рис. 6.3. Виды связей Таким образом, два предложения, описывающие связь продавца с контрактом, графически будут выражены так, как на рисунке 6.4. Продавец Контракт Рис. 6.4. Связь между сущностями Описав также связи остальных сущностей, получим схему (рис. 6.5). 78 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Контракт Автомашина Продавец Покупатель Рис. 6.5. Связи между сущностями Последним шагом моделирования является идентификация атрибутов. Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута – это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязательным (рис. 6.6). Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа). <ИМЯ СУЩНОСТИ> * <атрибут-1> 0 <атрибут-2> Рис. 6.6. Виды атрибутов: * – обязательный атрибут; 0 – необязательный атрибут Уникальный идентификатор – это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае 79 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя. Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом существительного, описывающим представляемую атрибутом характеристику. Атрибуты изображаются в виде списка имен внутри блока ассоциированной сущности, причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещаются наверху списка и выделяются знаком #. Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ сущности – это один или несколько атрибутов, чьи значения однозначно определяют каждый экземпляр сущности. При существовании нескольких возможных ключей один из них обозначается в качестве первичного ключа, а остальные – как альтернативные ключи. С учетом имеющейся информации дополним построенную ранее диаграмму (рис. 6.7). Контракт # И/Н (идентификационный номер) * дата * Автомашина Продавец Покупатель # Р/Н * год * марка * модель * запрашиваемая модель # И/Н * имя * адрес # И/Н * имя * адрес Рис. 6.7. Окончательная модель Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных. 80 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей (рис. 6.8). Летательный аппарат Супертипы Аэроплан Планер Самолет Вертолет Подтипы Другой тип Рис. 6.8. Подтипы и супертипы Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рис. 6.9). А В С Рис. 6.9. Взаимно исключающие связи 6.2. Подход, используемый в CASE-средстве Vantage Team Builder В CASE-средстве Vantage Team Builder (Westmount I-CASE) используется один из вариантов нотации П. Чена. На ER-диаграммах сущность обозначается прямоугольником, содержащим имя сущности (рис. 6.10), а связь – ромбом, связанным линией с каждой из 81 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ взаимодействующих сущностей. Числа над линиями означают степень связи. n 1 Рис. 6.10. Обозначение сущностей и связей Связи являются многонаправленными и могут иметь атрибуты (за исключением ключевых). В необязательной связи (рис. 6.11) могут участвовать не все экземпляры сущности. Инженер ПК Имеет Рис. 6.11. Необязательная связь В отличие от необязательной связи в полной (total) связи участвуют все экземпляры хотя бы одной из сущностей. Это означает, что экземпляры такой связи существуют только при условии существования экземпляров другой сущности. Полная связь может иметь один из четырех видов: обязательная связь, слабая связь, связь «супертип-подтип» и ассоциативная связь. Обязательная (mandatory) связь описывает связь между «независимой» и «зависимой» сущностями. Все экземпляры зависимой («обязательной») сущности могут существовать только при наличии экземпляров независимой («необязательной») сущности, т.е. экземпляр «обязательной» сущности может существовать только при условии существования определенного экземпляра «необязательной» сущности. В примере (рис. 6.12) подразумевается, что каждый автомобиль имеет по крайней мере одного водителя, но не каждый служащий управляет машиной. Автомобиль 1 Ведет n Служащий Рис. 6.12. Обязательная связь В слабой связи существование одной из сущностей, принадлежащей некоторому множеству (слабой сущности) зависит от существования определенной сущности, принадлежащей другому множеству (сильной сущности), т.е. экземпляр слабой сущности может 82 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ быть идентифицирован только посредством экземпляра сильной сущности. Ключ сильной сущности является частью составного ключа «слабой» сущности. Слабая связь всегда является бинарной и подразумевает обязательную связь для слабой сущности. Сущность может быть слабой в одной связи и сильной в другой, но не может быть слабой более, чем в одной связи. Слабая связь может не иметь атрибутов. Пример на рисунке 6.13: ключ (номер) строки в документе может не быть уникальным и должен быть дополнен ключом документа. Строка n 1 Документ Рис. 6.13. Слабая связь Связь «супертип – подтип» изображена на рисунке 6.14. Общие характеристики (атрибуты) типа определяются в сущности-супертипе, сущность-подтип наследует все характеристики супертипа. Экземпляр подтипа существует только при условии существования определенного экземпляра супертипа. Подтип не может иметь ключа (он импортирует ключ из супертипа). Сущность, являющаяся супертипом в одной связи, может быть подтипом в другой связи. Связь супертипа не может иметь атрибутов. Служащий Работа Менеджер Секретарь Техник Рис. 6.14. Связь «супертип – подтип» В ассоциативной связи каждый экземпляр связи (ассоциативный объект) может существовать только при условии существования определенных экземпляров каждой из взаимосвязанных сущностей. Ассоциативный объект – объект, являющийся одновременно сущностью и связью. Ассоциативная связь – это связь между несколькими «независимыми» сущностями и одной «зависимой» сущностью. Связь между независимыми сущностями имеет атрибуты, которые определяются в зависимой сущности. Таким обра83 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ зом, зависимая сущность определяется в терминах атрибутов связи между остальными сущностями. В примере, иллюстрируемом рисунком 6.15, самолет выполняет посадку на взлетную полосу в заданное время при определенной скорости и направлении ветра. Поскольку эти характеристики применимы только к конкретной посадке, они являются атрибутами посадки, а не самолета или взлетной полосы. Пилот, выполняющий посадку, связан гораздо сильнее с конкретной посадкой, чем с самолетом или взлетной полосой. Взлетная полоса Самолет Выполняет Посадка Пилот Рис. 6.15. Ассоциативная связь Первичный ключ каждого типа сущности помечается звездочкой (*). ER-диаграмма должна подчиняться следующим правилам: – каждая сущность, каждый атрибут и каждая связь должны иметь имя (связь супертипа или ассоциативная связь может не иметь имени); – имя сущности должно быть уникально в рамках модели данных; – имя атрибута должно быть уникально в рамках сущности; – имя связи должно быть уникально, если для нее генерируется таблица БД; – каждый атрибут должен иметь определение типа данных; – сущность в необязательной связи должна иметь ключевой атрибут (то же самое относится к сильной сущности в слабой связи, супертипу в связи «супертип – подтип» и необязательной сущности в обязательной (полной) связи); – подтип в связи «супертип – подтип» не может иметь ключевой атрибут; – в ассоциативной или слабой связи может быть только одна ассоциативная (слабая) сущность; – связь не может быть одновременно обязательной, связью «супертип – подтип» или ассоциативной. 84 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 7. КЛАССИФИКАЦИЯ АРХИТЕКТУР ИНФОРМАЦИОННЫХ ПРИЛОЖЕНИй Проектирование и разработка информационной системы может базироваться на разных архитектурных решениях. Начать можно с традиционных архитектурных решений, основанных на использовании выделенных файл-серверов или серверов баз данных. Затем рассматриваются варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции «склада данных» (DataWarehouse) – интегрированной информационной среды, включающей разнородные информационные ресурсы. Наконец, последняя архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектноориентированного подхода [Кузнецов, 2001]. 7.1. Файл-серверные приложения Организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с большим количеством персональных компьютеров разного уровня развитости и сравнительной дешевизной связывания их в локальные сети. Фактически, компоненты информационной системы, выполняемые на разных персональных компьютерах, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждом компьютере дублируются не только прикладные программы, но и средства управления базами данных. Файл-сервер представляет собой разделяемое всеми персональными компьютерами комплекса расширение дисковой памяти. 85 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Основным достоинством является простота организации. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД, но во многом эта простота является кажущейся. Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области. Во-вторых, необходимыми требованиями к базе данных информационной системы являются поддержание ее целостного состояния и гарантированная надежность хранения информации. Минимальными условиями, при соблюдении которых можно удовлетворить эти требования, являются: – наличие транзакционного управления; – хранение избыточных данных (например, с применением методов журнализации); – возможность формулировать ограничения целостности и проверять их соблюдение. В третьих, интерфейс развитых серверов баз данных основан на использовании высокоуровневого языка баз данных SQL, что позволяет использовать сетевой трафик между клиентом и сервером баз данных только в полезных целях (от клиента к серверу в основном пересылаются операторы языка SQL, от сервера к клиенту – результаты выполнения операторов). В файл-серверной организации клиент работает с удаленными файлами, что вызывает существенную перегрузку трафика (поскольку система управления базами данных, основанная на файл-серверной архитектуре, работает на стороне клиента, то для выборки полезных данных в общем случае необходимо просмотреть на стороне клиента весь соответствующий файл целиком). Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто небольшой компании для 86 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем персональном компьютере. Конечно, и в этом случае требуется большая аккуратность конечных пользователей (или администраторов, наличие которых в этом случае сомнительно) для надежного хранения и поддержания целостного состояния данных; однако в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файлсерверные архитектуры становятся недостаточными. 7.2. Клиент-серверные приложения Под клиент-серверным приложением понимается информационная система, основанная на использовании серверов баз данных. На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции. Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения. Между клиентской частью приложения и клиентской частью сервера баз данных существует, как правило, связь, основанная на использовании языка SQL; поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения. Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL. Архитектура «клиент – сервер» на первый взгляд кажется гораздо более дорогой, чем архитектура «файл – сервер». Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию. 87 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. 7.3. Intranet-приложения Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система – это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа. Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web – Всемирная Паутина). Для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей – браузеров, или «обходчиков», избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы оказывается достаточной для удовлетворения потребностей компании. Однако, при всех своих преимуществах (простота организации, удобство использования, стандартность интерфейсов и т.д.) эта схема обладает сильными ограничениями. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее гипертекстовые структуры трудно 88 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ модифицируются. Для того, чтобы изменить наполнение Webсервера, необходимо приостановить работу системы, внести изменения в HTML-описания и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы. Все перечисленные трудности могут быть разрешены с использованием более развитых механизмов Web-технологии. Эти механизмы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появляются новые возможности. Плохо, потому что отсутствует стандартизация. 7.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных До сих пор рассматривались способы и возможные архитектуры информационных систем, предназначенных для оперативной обработки данных, т.е. для получения текущей информации, позволяющей решать повседневные проблемы корпорации. Однако у аналитических отделов корпорации и у высшего звена управляющего состава имеются и другие задачи: проанализировав поведение корпорации на рынке с учетом сопутствующих внешних факторов и спрогнозировав хотя бы ближайшее будущее, выработать тактику, а возможно, и стратегию корпорации. Для решения таких задач требуются данные и прикладные программы, отличные от тех, которые используются в оперативных информационных системах. В последние несколько лет все более популярным становится подход, основанный на концепциях склада данных и системы оперативной аналитической обработки данных. Возможно, в российских условиях трудно производить долговременные прогнозы бизнес-деятельности (слишком изменчивы внешние факторы), но анализ прошлого и краткосрочные прогнозы будущего могут оказаться очень полезными. Основным источником информации, поступающей в оперативную базу данных является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Тем самым 89 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ склад данных должен включать как внутренние, так и внешние корпоративные данные, характеризующие рынок в целом. Если для оперативной обработки, как правило, требуются свежие данные (обычно в оперативных базах данных информация сохраняется не более нескольких месяцев), то в складе данных нужно поддерживать хранение информации о деятельности корпорации и состоянии рынка на протяжении нескольких лет (для проведения достоверного анализа и точного прогнозирования). Вследствие этого аналитические базы данных имеют объем как минимум на порядок больший, чем оперативные. Во многих достаточно крупных корпорациях одновременно существует несколько оперативных информационных систем с собственными базами данных. Оперативные базы данных могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую (например, из-за ошибок ввода данных). Склад данных корпорации должен содержать единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оперативных баз данных и быть согласованной. Отсюда следует необходимость наличия компонента склада данных, извлекающего информацию из оперативных баз данных и «очищающего» эту информацию. В 1993 году основоположник реляционного подхода к организации баз данных Эдвар Кодд, исходя из потребностей систем динамической аналитической обработки данных, сформулировал 12 основных требований к системам, поддерживающим аналитические базы данных: – многомерное концептуальное представление данных; – прозрачность; – доступность; – согласованная эффективность производства отчетов; – архитектура «клиент – сервер»; – родовая многомерность; – управление динамическими разреженными матрицами; – поддержка многопользовательского режима; – неограниченные операции между измерениями; – интуитивное манипулирование данными; – гибкая система отчетов; – неограниченное число измерений и уровней агрегации. 90 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 7.5. Интегрированные распределенные приложения Нет никаких проблем, если с самого начала информационное приложение проектируется и разрабатывается в духе подхода открытых систем: все компоненты являются мобильными и интероперабельными, общее функционирование системы не зависит от конкретного местоположения компонентов, система обладает хорошими возможностями сопровождаемости и развития. К сожалению, на практике этот идеал является трудно достижимым. По разным причинам возникают потребности в интеграции независимо и по-разному организованных информационно-вычислительных ресурсов, поэтому теперь существует путь решения проблемы, который сам лежит в русле открытых систем, – подход, предложенный крупнейшим международным консорциумом OMG (Object Management Group). Решение проблемы интеграции неоднородных информационных ресурсов началось с попыток интеграции неоднородных баз данных. Направление интегрированных или федеративных систем неоднородных БД и мульти-БД появилось в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД. Основной задачей интеграции неоднородных БД является предоставление пользователям интегрированной системы глобальной схемы БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня операторов, понятных соответствующим локальным СУБД. Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. Это в значительной степени усложняет реализацию. Кроме проблем интеграции приходится решать все проблемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевая оптимизация запросов и т.д. Очень трудно добиться эффективности. Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель данных. В последнее время все чаще предлагается использовать объектно-ориентированные модели, но на практике пока основой является реляционная модель; поэтому, в частности, включение в интегрированную систему локальной реляционной СУБД существенно проще и эффективнее, чем включение СУБД, основанной на другой модели данных. Ос91 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ новным недостатком систем интеграции неоднородных баз данных является то, что при этом не учитываются «поведенческие» аспекты компонентов прикладной системы. Легко заметить, что даже при наличии развитой интеграционной системы большинство из указанных выше проблем не решается. Естественным развитием взглядов на информационные ресурсы является их представление в виде набора типизированных объектов, сочетающих возможности сохранения информации (своего состояния) и обработки этой информации (за счет наличия хорошо определенного множества методов, применимых к объекту). Наиболее существенный вклад в создание соответствующей технологии внес международный консорциум OMG, выпустивший ряд документов, в которых специфицируются архитектура и инструментальные средства поддержки распределенных информационных систем, интегрированных на основе общего объектно-ориентированного подхода. Согласованная с архитектурой OMA (Object Management Architecture) прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB – Object Request Broker). ORB, общие средства (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории «общие средства» (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.). В основе OMA лежит базовая объектная модель COM (Core Object Model), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах. Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (Interface Definition Language), который очень напоминает компонент спецификации 92 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMG API брокера объектных заявок. Правила построения и использования ORB определены в документе OMG CORBA (Common Object Request Broker Architecture). 93 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 8. СРЕДСТВА И МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ, РАЗРАбОТКИ И СОПРОВОЖДЕНИЯ АРХИТЕКТУР ИНФОРМАЦИОННЫХ ПРИЛОЖЕНИй 8.1. Средства и методологии разработки файл-серверных приложений 8.1.1. Традиционные средства и методологии разработки файл-серверных приложений Файл-серверная информационная система, это система, которая в основном базируется на персональных компьютерах, используя в качестве внешней поддержки один или несколько файловых серверов, обеспечивающих значительные возможности управления внешней памятью, но не обладающих «интеллектом», поддерживая в основном только управление файлами. Практически во всех файл-серверных средствах и методологиях имеется тенденция к переходу на технологию «клиент – сервер». Файл-серверные архитектуры являются в большой степени облегченными вариантами клиент-серверных архитектур, хотя во многих случаях предлагаемые решения являются достаточными для небольшого по объему класса информационных систем. Хотя для разработки файл-серверных приложений имеется целый ряд инструментальных средств, отсутствуют общепринятые методологии [Кузнецов, 2001]. Когда методологии используются, то они те же, что в клиент-серверных приложениях. Обычно же файл-серверные приложения проектируются и разрабатываются «по месту» без использования каких-либо стандартных методов. Системы программирования третьего поколения 3GL являются предшественниками современных инструментальных средств и могут использоваться для разработки информационных прило94 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ жений при наличии соответствующих встроенных или библиотечных средств для реализации диалога и доступа к базам данных. Системы программирования для персональных компьютеров прошли долгий путь развития. Можно выделить три четкие языковые линии, которые оказывали друг на друга большое влияние, взаимно обогащаясь – это Си, Паскаль и Бейсик. Основные вехи на пути развития систем программирования: 1. Переход от одиночных утилит систем программирования к интегрированным диалоговым средам программирования (например, семейство Turbo-продуктов фирмы Borland). 2. Развитие инструментальных наборов, расширяющих возможности систем программирования, в частности в области диалога (разного рода Tool Box). 3. Появление объектно-ориентированных диалектов языков Си и Паскаль. 4. Возникновение операционной среды Windows со встроенной поддержкой диалога и первых Windows-приложений с помощью SDK (Software Development Keet). 5. Создание объектно-ориентированных библиотек, поддерживающих диалоговый режим работы в среде DOS и Windows (TurboVision, Object Windows и MFC). 6. Появление систем программирования, облегчающих создание приложений для DOS и Windows. 7. Развитие механизма встраивания и связывания объектов OLE 2. 8. Переход к визуальным системам программирования (Visual Си++, Delphi, Visual Basic), которые ориентированы на разработку информационных приложений. Поддержка диалогового режима развивалась совместно с развитием самих систем программирования и была естественным образом интегрирована с ними. Библиотеки же доступа к базам данных развивались своим путем. Наибольшее число библиотек доступа из языков программирования уровня 3GL к реляционным СУБД на персональных компьютерах поддерживает семейство xBase (Clipper, FoxPro, dBase). Из языков программирования чаще всего используется Си. 8.1.2. Средства и методы разработки приложений на основе СУБД на персональных компьютерах Приложения, созданные с использованием инструментальных средств программирования приложений, связанных с использова95 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ нием баз данных на персональных компьютерах, занимают существенную долю файл-серверных приложений. Если рассматривать только реляционные СУБД, то семейство xBase-продуктов является явным лидером по использованию для разработки одиночных и групповых информационных приложений. Следующее место занимает СУБД Paradox, а далее идут приложения, базирующиеся на применении системы управления записями Clarion. Особняком стоят такие пакеты, как MS Access и Lotus Approach, которые позволили взглянуть по-новому на возможности персональных СУБД и до сих пор не оценены по-настоящему как профессиональные средства разработки приложений. Можно отметить следующие вехи на пути развития инструментальных средств и самих СУБД на персональных компьютерах: – появление компонентов Assistant и Application Gentrator в dBase III Plus, упрощающих работу пользователя и позволяющих генерировать простейшие приложения или макеты приложений; – выход в свет dBase-совместимых систем программирования (dBFast и Clipper), создающих исполняемый модуль приложения; – разработка быстрого интерпретатора FoxBase для частично откомпилированного кода dBase-совместимых приложений; – возникновение системы Paradox с оригинальным макроязыком PAL, существенно ориентированной на конечного пользователя; – развитие многопользовательских версий СУБД для локальных сетей персональных компьютеров, дополненных средствами синхронизации на основе блокировок файлов и записей; – появление системы dBase IV, включающей диалоговую среду Control Center, индексы, встроенные в файл БД, поддержку языка SQL и средства защиты БД; – развитие Clipper с объектной ориентацией; – обеспечение доступа из файл-серверных приложений к серверам БД (Borland SQL Link и Microsoft Connectivity Kit); – внедрение технологии Rushmore, ускоряющей доступ к данным при помощи использования индексов; – появление в FoxPro развитой среды разработки, ориентированной на разработку проектов и близкой по возможностям к средствам 4GL; – дальнейшее расширение средств диалога (Foundation Read) в направление событийной управляемости; – первые версии инструментальных средств, поддерживающие Windows-приложения, а вместе с ними типы данных Blob (Binary Large Objects); 96 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – появление универсальных интерфейсов к различным СУБД (Borland IDAPI и Microsoft ODBC); – первый продукт MS Access, направленный сугубо на создание Windows-приложений и содержащий средства объектно-ориентированного диалога, событийно-управляемого программирования, визуального конструирования интерфейса пользователя и многие другие черты, присущие системам программирования 4GL и RAD; – появление новых визуальных объектно-ориентированных инструментальных средств и СУБД на ПК (MS Access 2.0, Visual FoxPro, CA-VisualObjects и Visual dBase). 8.1.3. Новые средства разработки файл-серверных приложений Чем дальше, тем больше файл-серверные приложения сближаются с более развитыми технологиями клиент-серверных приложений. В последнее время появилась целая серия программных продуктов, позиционируемая одновременно как средства «легкой» разработки приложений для персональных компьютеров, так и более «тяжеловесной» разработки приложений в технологии «клиент – сервер». Это и хорошо, поскольку позволяет плавно изменять технологию. В индустрии СУБД для персональных компьютеров отразились тенденции нормализации систем (Rightsizing). В последнее время в этой области происходили два встречных процесса: 1. Разукрупнение серверов БД – появление новых версий серверов БД Informix, Oracle и т.д. сначала в варианте для рабочих групп, а потом в виде облегченных версий для одиночных персональных компьютеров. 2. Укрупнение СУБД для персональных компьютеров. Новые «персональные» СУБД и связанные с ними инструментальные средства развивались в сторону «истинно реляционных» СУБД, т.е. серверов БД, приложений «клиент – сервер» и инструментальных средств программирования 4GL и быстрой разработки RAD. 8.1.4. Новые СУБД для персональных компьютеров и соответствующие инструментальные средства разработки Визуальный характер программирования приложений, особенно в части создания диалогового графического интерфейса пользователя, – это множество поддерживаемых диалоговых объектов, 97 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ поддержка механизма drag-and-drop и наличие мастеров, помогающих реализовать сложные процедуры. Управляемость приложений в соответствии с событиями диалога и обеспечение доступа к БД позволяет строить гибкий интерфейс пользователя и поддерживать ссылочную целостность БД. Встроенная поддержка языка структурированных запросов SQL (Standard Query Language) закладывает возможность масштабирования создаваемых файл-серверных приложений до уровня приложений «клиент – сервер». Имеется возможность построения приложений «клиент – сервер» за счет реализации доступа к серверам БД напрямую или через интерфейс ODBC для открытого взаимодействия с базами данных. Использование объектно-ориентированного языка разработки приложений (по крайней мере в части диалога) позволяет широко использовать механизм наследования и тем самым использовать ранее произведенные программные компоненты. Поддержка компонентно-ориентированного программирования дает возможность расширения приложений за счет использования готовых внешних визуальных объектов типа VBX и OCX (ActiveX). «Истинно реляционная» база данных представляет собой объединенный набор файлов, содержащий таблицы, индексы и т.п., что облегчает сопровождение БД и приложений и является основой для поддержки целостности данных. Поддерживается общий для информационной системы словарь данных (data dictionary), который содержит описание структуры БД, типы полей, правила поддержки ограничений целостности и т.п. Поддержка целостности БД (данных, ссылок и транзакций) позволяет создавать приложения с необходимым уровнем надежности и сохранности данных. Возможности серверных процедур обработки (триггеров и хранимых процедур) закладывают основу для масштабирования приложений, позволяют гибко распределять прикладную логику между клиентом и сервером при переходе к архитектуре «клиент – сервер». Хранение в БД описания проекта создаваемого приложения является прообразом репозитория инструментальных средств быстрой разработки RAD и CASE-систем. 98 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 8.2. Средства и методологии проектирования, разработки и сопровождения приложений 8.2.1. Базовые средства построения информационных систем Применительно к системам баз данных архитектура «клиент – сервер» актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре «клиент – сервер», являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных. Реальное распространение архитектуры «клиент – сервер» стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Основным смыслом подхода открытых систем является упрощение комплексирования вычислительных систем за счет международной и национальной стандартизации аппаратных и программных интерфейсов. Главной побудительной причиной развития концепции открытых систем явились повсеместный переход к использованию локальных компьютерных сетей и необходимость решения проблем комплексирования аппаратно-программных средств, которые вызвал этот переход. В связи с бурным развитием технологий глобальных коммуникаций открытые системы приобретают еще большее значение и масштабность. Характерной особенностью открытых систем для пользователей является независимость от конкретного поставщика. Ориентируясь на продукцию компаний, придерживающихся стандартов открытых систем, потребитель, который приобретает любой продукт такой компании, не попадает к ней в рабство. Он может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств и не является необоснованной декларацией. Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось прийти к соглашению об основных 99 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным (а в большинстве случаев и системным) программистам. По всей видимости, несмотря на появление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в ближайшие годы. Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам. Использование подхода открытых систем выгодно и производителям, и пользователям. Прежде всего, открытые системы обеспечивают естественное решение проблемы поколений аппаратных и программных средств. Производители таких средств не должны решать все проблемы заново, они могут, по крайней мере, временно продолжать комплексировать системы, используя существующие компоненты. Преимуществом для пользователей является то, что они могут постепенно заменять компоненты системы на более совершенные, не утрачивая работоспособности системы. В частности, в этом кроется решение проблемы постепенного наращивания вычислительных, информационных и других мощностей компьютерной системы. Общим решением проблемы мобильности систем, основанных на архитектуре «клиент – сервер» является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC – Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. 8.2.2. Серверы баз данных как базовая системная поддержка информационной системы Термин «сервер баз данных» обычно используют для обозначения всей СУБД, основанной на архитектуре «клиент – сервер», 100 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети. Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Этот язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов. Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество – стандартность интерфейса. В пределе, который вряд ли полностью достижим, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел. Недостаток тоже довольно очевиден. При таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция, но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы. Типичный сервер баз данных отвечает за выполнение следующих функций: – поддержание логически согласованного набора файлов; – обеспечение языка манипулирования данными; – восстановление информации после разного рода сбоев; – организация параллельной работы нескольких пользователей. 101 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 8.3. Средства и методологии проектирования, разработки и сопровождения Intranet-приложений Intranet-система может основываться на локальной сети компьютеров, собственной корпоративной глобальной сети или виртуальной корпоративной подсети Internet. Различают несколько типов Intranet-систем, для реализации каждого из которых применяются разные средства. 1. Коммуникационные Intranet-системы предназначены главным образом для связывания территориально разнесенных подразделений корпорации. При этом уменьшается потребность в многочисленных выделенных линиях связи. 2. Интегрирующие Intranet-системы служат для интеграции разнородных существующих коммуникационных и обрабатывающих корпоративных подсистем. 3. Intranet-системы с упрощенной для пользователей процедурой доступа обычно основываются на механизме электронной подписи. Такие системы должны быть особенно надежно защищены от внешнего мира. В общем случае информационная Intranet-система может включать свойства каждого из перечисленных типов, и в этом случае при ее разработке придется учитывать все требования. 8.3.1. Основные понятия Intranet Поскольку для разработки Intranet-систем используются методы и средства Internet, и главным образом, технология WWW, то и понятия и термины Internet и Intranet совпадают. Некоторые из них: – HTTP (HyperText Transfer Protocol) – протокол обмена гипертекстовой информацией; – URL (Universal Resource Locator) – универсальный локатор ресурсов, используемый в качестве универсальной схемы адресации ресурсов в сети; – HTML (HyperText Markup Language) – язык гипертекстовой разметки документов, специальная форма подготовки документов для их опубликования в World Wide Web; – CGI (Common Gateway Interface) – спецификация на формат обмена данными между сервером протокола HTTP и прикладной программой; 102 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ – API (Application Program Interface) – в данном контексте это спецификация, определяющая правила обмена данными между сервером и программным модулем, который должен быть включен в состав сервера; – VRML (Virtual Reality Modeling Language) – язык описания трехмерных сцен и взаимодействия трехмерных объектов; – Javaapplets – мобильные (независимые от архитектуры «железа») программные коды, написанные на языке программирования Java; – Java – объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems и используемый в качестве основного средства мобильного программирования; – MIME (Multipurpose Internet Mail Exchange) – формат почтового сообщения Internet (в данном контексте стандарт MIME используется для установления соответствия между типом информационного файла, именем этого файла и программой просмотра этого файла); – CCI (Common Client Interface) – спецификация обмена данными между прикладной программой и браузером Mosaic. В случае применения программного обеспечения, выполненного согласно CCI, браузер превращается в сервер-посредник для программного обеспечения пользователя. 8.3.2. Серверы Intranet В Intranet можно использовать все возможные сервисы Internet (например, электронную почту, возможности удаленного терминала и т.д.). FTP-серверы являются одним из основных информационных ресурсов Internet. Фактически это распределенный депозитарий текстов, программ, фильмов, фотографий, аудиозаписей и прочей информации, хранящейся в виде файлов на различных компьютерах во всем мире. Информация в FTP-архивах разделена на три категории: 1. Защищенная информация, режим доступа к которой определяется ее владельцами и разрешается по специальному соглашению с потребителем. К этому виду ресурсов относятся коммерческие архивы (например, коммерческие версии программ в архивах ftp. microsoft.com или ftp.bsdi.com), закрытые национальные и международные некоммерческие ресурсы (например, работы по международным проектам CES или IAEA), частная некоммерческая информация со специальными режимами доступа (например,частные благотворительные фонды). 103 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 2. Информационные ресурсы ограниченного использования, к которым относятся, например, программы класса shareware (Trumpet Winsock, Atis Mail, Netscape и т.п.). В данный класс могут входить ресурсы ограниченного времени использования или ограниченного времени действия, т.е. пользователь может использовать текущую версию на свой страх и риск, но никто не будет оказывать ему поддержку. 3. Свободно распространяемые информационные ресурсы или freeware, если речь идет о программном обеспечении. К этим ресурсам относится все, что можно свободно получить по сети без специальной регистрации. Это может быть документация, программы или что-либо еще. Наиболее известными свободно распространяемыми программами являются программы проекта GNU Free Software Foundation. Следует отметить, что свободно распространяемое программное обеспечение не имеет сертификата качества, но, как правило, его разработчики открыты для обмена опытом. Технология FTP была разработана в рамках проекта ARPA и предназначена для обмена большими объемами информации между машинами с различной архитектурой. Главным в проекте было обеспечение надежной передачи, и поэтому с современной точки зрения FTP кажется перегруженным излишними редко используемыми возможностями. Стержень технологии составляет FTP-протокол. Сервер World Wide Web – это программа, обслуживающая запросы клиентов по протоколу HTTP. Главной задачей сервера «паутины» является обеспечение доступа пользователей к базе данных HTML-документов. Однако в настоящее время функциональные возможности серверов значительно расширились и вышли за пределы простой отсылки документов на запросы клиентов. Наиболее типичными для современных серверов являются следующие функции: – ведение иерархической базы данных документов; – контроль за доступом к информации со стороны программклиентов; – предварительная обработка данных перед ответом на запрос; – взаимодействие с внешними программами через Common Gateway Interface; – реализация взаимодействия с клиентами и другими серверами в режиме посредника; – реализация встроенных или взаимодействие с внешними поисковыми машинами. 104 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 9. ОбЩИЕ ТЕНДЕНЦИИ РАЗВИТИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ ДЛЯ ИНФОРМАЦИОННЫХ СИСТЕМ Общие тенденции развития инструментальных средств для информационных систем можно описать рядом ключевых положений. 1. Активное использование объектных технологий. В разработках информационных систем прочные позиции заняли объектные технологии. Их использование в этой области продолжает расширяться. В значительной мере этому способствует создание развитой объектной инфраструктуры. Большой вклад в ее формирование вносит консорциум OMG (Object Management Group), который с начала 1990-х годов ведет активную работу по созданию комплекса стандартов интероперабельных неоднородных распределенных объектных сред. Существенный вклад в компонентные технологии внесла корпорация Microsoft, которая первой разработала компонентную объектную модель COM (Component Object Model) и ее распределенную версию DCOM (Distributed Component Model), ставшие основой ряда программных продуктов компании. Важное значение имеет создание компанией Sun Microsystems и широкое распространение объектного языка программирования Java, а также основанного на этом языке комплекса средств компонентной разработки приложений из повторно используемых объектных компонентов – компонентная модель JavaBeans, архитектура Enterprise JavaBeans, а также технология Java 2 Enterprise Edition. Наряду с указанными общими элементами объектной инфраструктуры, не зависимыми от класса информационных систем, созданы также ее элементы, ориентированные на отдельные классы систем, – системы баз данных, Web, текстовые системы. Основой разработки коммерческих объектных СУБД стал стандарт объектных баз данных консорциума ODMG (Object Data Management Group). 105 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Объектный подход нашел применение и в технологиях Web. Технология Java-аплетов обеспечивает мобильность программного обеспечения в среде Web с помощью Web-браузеров со встроенной виртуальной машиной Java (Java Virtual Machine, JVM). Консорциумом W3C был разработан стандарт DOM (Document Object Model), обеспечивающий объектное представление XMLдокументов – единицы информационных ресурсов в новой технологической платформе Web, основанной на языке XML. Языковые средства DOM используются как спецификации API для XMLориентированных СУБД. Для работы с текстовыми информационными ресурсами объектные типы данных, поддерживаемые расширителями типов, используются в объектно-реляционных серверах DB2, Oracle, Informix. Объектное направление в области информационных систем хорошо оснащено инструментальными средствами CASE, основанными на методах объектного анализа и проектирования и использующими стандартизованный консорциумом OMG язык UML (Unified Modeling Language) для представления метаданных. 2. Интеграция неоднородных информационных ресурсов. Благодаря активным разработкам информационных систем многие организации стали обладателями коллекций информационных ресурсов разной природы, каждая из которых поддерживается собственными программными средствами, обеспечивающими для пользователя свой специфический интерфейс. Под интеграцией информационных ресурсов понимается обеспечение пользователям доступа к нескольким источникам информационных ресурсов в терминах единого материализованного или виртуального представления, исключающего избыточность информации на логическом или семантическом уровне. Неоднородность информационных ресурсов может проявляться в различных аспектах, например: – в различии парадигм моделирования данных (реляционная модель, объектная модель и т.п.); – в многообразии сред представления ресурсов (текстовая, аудио и т.д.); – в разной степени структурированности данных (структурированные, слабоструктурированные, неструктурированные); – в различиях интерпретации их содержания, в различии программных систем, которые их поддерживают, и т.д. 106 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Интеграция информационных ресурсов охватывает большой комплекс проблем, к числу которых относятся, в частности: – разработка интегрирующих моделей данных; – создание методов отображения моделей данных; – создание архитектур систем интеграции; – разработка адаптеров (Wrapper) – компонентов таких архитектур, обеспечивающих интероперабельность интегрируемых неоднородных информационных ресурсов; – создание посредников (Mediator) – компонентов архитектур интеграции, обеспечивающих семантическую интеграцию информационных ресурсов; – интеграция схем объединяемых баз данных; – разработка языков описания онтологии; – создание методов слияния онтологии и др. Технологии интеграции неоднородных информационных ресурсов уже находят практическое применение. Некоторые относительно простые возможности интеграции обеспечиваются программными продуктами. Более сложные проблемы семантической интеграции пока еще являются предметом изучения многих исследовательских проектов. 3. Архитектура распределенных систем. Распределенные информационные системы стали в настоящее время обыденной реальностью. В многочисленных корпоративных информационных системах используются распределенные базы данных. Отработаны методы распределения данных и управления распределенными данными, архитектурные подходы, обеспечивающие масштабируемость систем, реализующие принципы многозвенной архитектуры «клиент – сервер», а также архитектуры промежуточного слоя. Начинают применяться на практике мобильные архитектуры. Это относится как к системам баз данных, так и к приложениям Web. Возрождается подход к построению распределенных систем, основанный на одноранговой архитектуре (Peer-to-Peer), при котором, в отличие от доминирующей сегодня в распределенных системах архитектуры «клиент – сервер», роли взаимодействующих сторон в сети не фиксируются. Они назначаются в зависимости от ситуации в сети, от загруженности ее узлов. 4. Мобильные информационные системы. В связи с интенсивным развитием коммуникационных технологий активно развиваются мобильные информационные системы. Разработаны технические средства и программное обеспечение для их создания. 107 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Благодаря этому стали развиваться мобильные системы баз данных. Многие научные коллективы проводят исследования специфических особенностей таких систем, создают разнообразные их прототипы. Важным инструментом для разработки мобильного программного обеспечения стали технологии Java. Создан стандарт протокола беспроводного доступа приложений в Web (WirelessApplication Protocol, WAP), который уже поддерживается некоторыми моделями сотовых телефонов. На основе WAP и языка XML консорциум W3C разработал язык разметки для беспроводных коммуникаций WML (Wireless Markup Language). 5. Поддержка метаданных. В разработках информационных систем больше внимания стали уделять метаданным. Здесь предпринимаются шаги в двух направлениях – стандартизация представления метаданных и обеспечение их поддержки в системе. В информационных системах используются разнообразные способы и средства представления метаданных (различного рода репозитории метаданных). Отсутствие унификации в этой области значительно осложняет решение проблем мобильности приложений, повторного использования и интеграции информационных ресурсов и информационных технологий, а также реинжиниринга информационных систем. Для преодоления указанных трудностей активно ведутся разработки стандартов метаданных, ориентированных на различные информационные технологии. В этой области уже существует ряд международных, национальных и индустриальных стандартов, определяющих представление метаданных и обмен метаданными в информационных системах. Некоторые из них уже приобрели статус стандартов де-факто. Ограничимся здесь упоминанием лишь наиболее значимых из них. Вероятно, первым стандартом де-факто этой категории был язык описания данных CODASYL для баз данных сетевой структуры. Из более поздних стандартов следует назвать: стандарт языка запросов SQL для реляционных баз данных, содержащий определение так называемой информационной схемы – совокупности представлений схем реляционных баз данных; компонент стандарта объектных баз данных ODMG, описывающий интерфейсы репозитория объектных схем; международный стандарт IRDS (Information Resource Dictionary Systems), описывающий системы для создания и поддержки справочников информационных ресурсов организации. 108 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Далее следует упомянуть разработанный консорциумом OMG стандарт CWM (Common Warehouse Metamodel) представления метаданных хранилищ данных, основанный на ранее созданном для более широких целей стандарте OIM (Open Information Model) консорциума MDC (Meta Data Coalition). Новая технологическая платформа XML для Web также включает стандарты представления метаданных. Поддержка метаданных – это одно из важнейших нововведений Web, радикальным образом изменяющее технологии управления его информационными ресурсами. В то время как в технологиях баз данных поддержка метаданных была изначально необходимой, в Web первого поколения метаданные не поддерживались. К числу стандартов метаданных Web относится подмножество языка XML, используемое для описания логической структуры XML-документов некоторого типа. Это описание называется DTD (Document Type Definition). Кроме того, платформа XML включает стандарт XML Schema, предлагающий более развитые возможности для описания XML-документов. Стандарт RDF (Resource Definition Framework) определяет простой язьк представления знаний для описания содержимого XML-документов. Наконец, разрабатываемый стандарт OWL (Ontology Web Language) определяет формальный язык описания онтологии, предназначенный для семантического Web. Стандарт языка UML (Unified Modeling Language), обеспечивающий представление метаданных инструментов CASE для визуального объектного анализа и проектирования, разработан консорциумом OMG. Этот язык поддерживается во многих программных продуктах CASE. Консорциум OMG создал также стандарт XMI (XML Metadata Interchange) для обмена метаданными между инструментами CASE, использующими язык UML. Следует упомянуть здесь также стандарт Дублинского ядра (Dublin Core, DC) – набора элементов метаданных для описания содержания документов различной природы. Этот стандарт быстро приобрел популярность и нашел, в частности, широкое применение в среде Web . Работы по развитию существующих и созданию новых стандартов представления метаданных для информационных систем продолжаются. Более подробные сведения о рассматриваемых стандартах можно найти в энциклопедии. 109 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 6. Семантическая обработка информационных ресурсов. Еще в 70–80-х годах предпринимались попытки создания систем, основанных на знаниях. Был выполнен ряд посвященных этим проблемам исследовательских проектов в Стэнфордском университете (США), в университете Торонто (Канада) и других крупных научных центрах. Были созданы различные исследовательские прототипы систем баз данных, поддерживающих семантические модели данных, а также информационно-поисковых систем, в которых в качестве языков запросов использовались естественные языки. Поисковые системы такого типа создавались и в нашей стране. В последние годы активно велись работы по семантическому текстовому поиску. Консорциум W3C и несколько крупных исследовательских центров в США и Европе развернули и активно проводят работы по созданию семантического Web. В то время как действующая реализация Web предусматривает интерпретацию информационных ресурсов человеком, семантический Web позволит создавать приложения с компьютерной их интерпретацией. Он будет располагать также средствами логического вывода. 7. Управление потоками данных. Управление потоками данных – одно из новых формирующихся направлений в области информационных систем, связанное с обработкой данных сетевого трафика, данных, порождаемых различного рода датчиками, потоков сообщений электронной почты и т.п. Стали создаваться предназначенные для этой цели инструментальные средства, которые называют системами управления потоками данных (Data Stream Management System, DSMS) общего назначения. Возникло специфическое направление, связанное с потоками документов, в текстовых системах – фильтрация потоков. Специфика этого класса информационных систем состоит в том, что, в отличие от систем баз данных и систем текстового поиска, они имеют дело не с базой данных или коллекцией документов, содержащейся в среде хранения информационных ресурсов системы, а с потоком транзитных ресурсов, которые нужно обрабатывать «на проходе». В связи с этим необходимо разрабатывать новые технологии для решения проблем, связанных с информационными ресурсами такой природы. 8. Совместное использование информационных технологий. В последние годы стали появляться инструментальные средства и крупные информационные системы, в которых совместно используются различные информационные технологии из области баз 110 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ данных, текстовых систем и Web. Так, создан ряд коммерческих СУБД, которые наряду с традиционными для технологий баз данных функциями управления данными предоставляют возможности текстового поиска. Простейшие возможности контекстного поиска обеспечивают популярные Web-браузеры. Поисковые машины Web используют реализованную в этой среде технологию доступа к информационным ресурсам вместе с технологиями текстового поиска. В новом классе СУБД, называемых XML-ориентированными, совместно используются технологии баз данных и технологии XML. В среде Web обеспечивается доступ к базам данных SQL по запросам пользователей. Создаются интегрированные системы, предусматривающие доступ к базам данных и к текстовым информационным ресурсам с использованием единого интерфейса. Одна из таких систем создана компанией IBM. С середины 90-х годов во многих странах стали активно разрабатываться информационные системы нового класса, называемые электронными библиотеками. Одной из основных особенностей продвинутых систем такого рода является поддержка и обеспечение интеграции неоднородных информационных ресурсов, поэтому настоятельной необходимостью в электронных библиотеках стало совместное использование различных информационных технологий – технологий баз данных, технологий текстового поиска, технологий Web. 9. Рост масштабов информационных систем. Совершенствование технических возможностей средств вычислительной техники, развитие коммуникационных средств и технологий управления информационными ресурсами в последние годы привели к появлению более крупных информационных систем. Речь идет о масштабах систем не только относительно объема поддерживаемых информационных ресурсов, но и числа их пользователей. Появились системы очень больших баз данных, поддерживающие многие гигабайты и даже петабайты данных, системы текстового поиска с очень большими коллекциями документов. Объем информационных ресурсов Web в настоящее время исчисляется многими миллионами страниц. Корпоративные системы баз данных насчитывают тысячи пользователей. На порядок больше пользователей имеют некоторые информационные сервисы Web. Количество таких крупных систем продолжает расти. 10. Глобализация информационных систем. Усиливается тенденция к глобализации информационных систем. Глобализация 111 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ информационных систем имеет две стороны – обеспечение глобального доступа пользователей к системе и интеграция информационных ресурсов, распределенных в глобальной сети. Уникальной глобальной информационной системой является Web. В нем воплощаются обе указанные стороны глобализации информационных систем. Он обеспечивает глобальный доступ к явно представленным на Web-сайтах информационным ресурсам, а также к ресурсам «скрытого» Web. Вместе с тем на платформе Web создаются разнообразные приложения, обеспечивающие интеграцию распределенных в Web информационных ресурсов. Многочисленные глобальные системы создаются в настоящее время как приложения Web для электронного бизнеса, для поддержки научной кооперации различных коллективов ученых во многих областях знаний в международном и национальном масштабе, в библиотечном деле и в других сферах. Среда Web предоставляет для поддержки таких систем идеальные условия. 11. Конвергенция технологий. Одна из важных тенденций в области информационных систем состоит в конвергенции различных пластов технологий информационных систем. Имеет место взаимопроникновение идей, заимствование подходов и техники из смежных областей информационных технологий. Действительно, в системах текстового поиска используются заимствованные из технологий баз данных методы прямого доступа к информационным ресурсам на основе техники индексирования. Технологии Web используют методы текстового поиска, отработанные за долгие годы в специально предназначенных для этого системах текстового поиска. В технологической платформе XML, создаваемой для Web нового поколения, используются многие ключевые концепции и подходы к управлению данными, созданные в области баз данных, такие как модель данных, схема, многоуровневое представление данных, ограничения целостности данных и др. В свою очередь, в технологиях баз данных зарождается новый класс систем баз данных, предназначенных для поддержки коллекций XML-документов. Появились коммерческие XMLориентированные СУБД. 12. Развитие стандартов информационных технологий. Последнее десятилетие стало периодом интенсивной деятельности по стандартизации различных аспектов информационных технологий. Эта деятельность осуществляется не только силами официальных органов стандартизации, но и многочисленными специально для этих целей учрежденными индустриальными консорциумами. 112 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ Благодаря созданию стандартов в этой области обеспечивается переносимость приложений и информационных ресурсов между различными программно-аппаратными платформами, интероперабельность программных продуктов различных поставщиков и созданных на их основе приложений, повторное использование ресурсов, в частности метаданных и программных компонентов приложений. Появилась возможность измерения производительности различных систем на эталонных тестах и сравнительной оценки результатов измерений и т.д. Создано немалое количество международных, национальных и индустриальных стандартов разного назначения, многие из которых стали уже стандартами де-факто. Стандарты реляционных и объектных баз данных, многочисленные стандарты Web, хранилищ данных, интероперабельных неоднородных распределенных объектных сред, стандарты геоданных, компонентных моделей и архитектур представляют лишь часть проведенной в этой области огромной работы. Деятельность по созданию и развитию стандартов информационных технологий активно продолжается. 13. Автоматизированная разработка информационных систем. Крупное достижение технологий современных информационных систем состоит в создании методов их анализа и проектирования, которые в течение двух-трех десятилетий прошли испытания на практике. На их основе разработаны инструментальные средства CASE, которые поставляются многими компаниями – разработчиками программного обеспечения. Такие технологии широко применяются прежде всего для создания систем баз данных. Важное место в этой области принадлежит методам объектного анализа и проектирования. Консорциумом OMG создан стандарт унифицированного визуального языка моделирования UML, основанного на таких методах. Язык UML поддерживают в настоящее время многие программные продукты. Разработчики Web-сайтов также располагают развитым инструментальным оснащением, которое существенно облегчает создание страниц Web со сложным дизайном, позволяет динамически генерировать страницы Web на основе содержимого баз данных по запросам пользователей, разрабатывать и отлаживать встраиваемые в страницы Web Java-скрипты и т.д. Создатели систем текстового поиска имеют в своем распоряжении вспомогательные средства для автоматизированной разработ113 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ки тезаурусов, словарей и т.д., для сканирования и ввода документов, автоматического их индексирования [Зубарева]. Важная тенденция в области информационных систем состоит в том, что повышается удельный вес систем, которые создаются с использованием тех или иных средств автоматизированной разработки. Повышается культура проектирования и реализации крупных информационных систем, основанных на технологиях баз данных. Все большее признание специалистов получают стандарты системного проектирования, обеспечивающие эффективное управление жизненным циклом создаваемой системы, отсутствие упущений в процессе разработки, высокое ее качество. В условиях рыночной экономики уделяется серьезное внимание управлению проектами систем, не только технологическим, но и экономическим их аспектам. Для этого развиваются необходимые методы и создаются инструментальные средства. 114 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ ЗАКЛЮЧЕНИЕ Разработка информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, оказывают влияние на структуру информационной системы, но в тоже время структуры разных предприятий в целом схожи между собой. Внедрение современных информационных технологий позволяет сократить время, требуемое на подготовку конкретных маркетинговых и производственных проектов, уменьшить непроизводительные затраты при их реализации, исключить возможность появления ошибок в подготовке бухгалтерской, технологической и других видов документации, что дает коммерческой компании прямой экономический эффект [Колесник]. Современные программные системы становятся сложнее, чтобы обеспечить возможность решения глобальных задач, например таких, как создание единой системы управления предприятием. При разработке подобных систем важно хорошо представлять современные подходы, существующие в этой области, и основные сложности этого процесса. Разумеется, для раскрытия всех потенциальных возможностей, которые несет в себе использование компьютеров, необходимо применять в работе на них комплекс программных и аппаратных средств, максимально соответствующий поставленным задачам; поэтому в настоящее время велика потребность коммерческих компаний в компьютерных программах, поддерживающих работу управленческого звена компании, а также в информации о способах оптимального использования имеющегося у компании компьютерного оборудования. 115 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ СПИСОК ИСПОЛЬЗОВАННОй ЛИТЕРАТУРЫ 1. Проектирование пользовательского интерфейса на персональных компьютерах. Стандарт фирмы IBM. Вильнюс: DBS Ltd, 1992. 2. Будаева А.А. Интерфейсы АСОИУ: учебное пособие. Владикавказ, 2008. URL: http://www.skgmi-gtu.ru/aoi/Method/Учебное пособие интерфейсы АСОИиУ.htm 3. Вендров А.М. Case-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998. 4. Гурьев А.Т., Абрамова Л.В., Кузнецова Е.А. Функциональное моделирование процессов лесного комплекса. Архангельск: Изд-во Архангельского гос. техн. ун-та, 2003. 5. Информационные системы в управлении информсредой образования: учебно-методический комплекс интегративной дисциплины «Информсреда образования» в четырех частях с системой обновляемых выпусков / Д.В. Двоеглазов [и др.]. М.: МГДД(Ю)Т; МИРЭА; ГНИИ ИТТ «Информика», 2002. 6. Дик В.В. Информационные системы в экономике. М.: Финансы и статистика, 1996. 7. Дубейковский В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как?. М.: ДиалогМИФИ, 2004. 8. Зубарева Н.В. Информационные системы маркетинга: электронный учебно-методический комплекс. 2007. URL: http://www. kgau.ru/istiki/umk/ismar/index.htm#c_2_2.htm 9. Избачков Ю., Петров В. Информационные системы. СПб.: Питер, 2005. 10. Калянов Г.Н. CASE-технологии. Консалтинг в автоматизации бизнес-процессов. М.: Горячая линия-Телеком, 2000. 11. Колесник А.П. Компьютерные системы в управлении финансами. М.: Финансы и статистика, 1994. 116 `çéóêáÖÜí = ! " ! = …# $ % = …% & % $ ! ' ⁄ = C= ! ! ! = …^( ) * + , + - . = h* / ( 0 J`) 1 - / , ⁄ 12. Кузнецов С.Д. (1998). Разновидности и архитектуры информационных приложений // Стратегическое планирование сетей масштаба предприятия. URL: http://citforum.ru/nets/spsmp/ spsmpred_20.shtml 13. Кузнецов С.Д. (2001) Проектирование и разработка корпоративных информационных систем. URL: http://www.citforum.idknet. com/cfin/prcorpsys/index.shtml 14. Липаев В., Филинов Е. Формирование и применение профилей открытых информационных систем // Открытые системы. 1997. № 5. 15. Майстренко А.В., Майстренко Н.В. Информационные технологии в науке, образовании и инженерной практике: учебное пособие. Тамбов: Изд-во Тамбовского гос. техн. ун-та, 2009. 16. Маклаков С.В. BPWin и ERWin. CASE – средства разработки информационных систем. 2-е изд., испр. и доп. М.: ДИАЛОГ-МИФИ, 2001. 17. Информационные технологии: курс лекций / Н.В. Молокова [и др.]. Красноярск: Сибирский федер. ун-т, 2007. 18. Петров В.Н. Информационные системы. СПб.: Питер, 2003. 19. Свердлов С.З. Языки программирования и методы трансляции: учебное пособие. СПб.: Питер, 2007. 20. Советов Б.Я. Информационные технологии: учеб. для вузов. М.: Высшая школа, 2003. 21. Федотов Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии. М.: Горячая линия телеком, 2005. 22. Эберт К. Экскурс в историю программных технологий // Открытые системы. 2008. № 10. 117