«А.В. Маслов ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ Учебное пособие Издательство Томского политехнического университета 2008 УДК 004.415.2(076.5) ББК 65ф.я73 М 31 Маслов А.В. М 31 Проектирование информационных ...»

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

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

Этап реализации проекта ИХ выполняется на основе выбранных программных (U3) и технических средств (U4), а также построенных на этапе концептуального моделирования компонентов ИХ (Д4–Д6) и схемы размещения ИХ (Д7) путем наполнения репозитория (G1), настройки или программирования других инструментальных средств (G2), наполнения информационного хранилища для MOLAP-структуры (G3), создания проектной документации (Д8).

Наполнение репозитория ИХ осуществляется путем ввода определений:

• структуры ИХ, источников и витрин данных;

• правил ввода данных в ИХ из одного источника, из нескольких источников, при отсутствии данных;

• правил преобразования форматов при поступлении данных из источника и при выводе данных в предоставление пользователю;

• параметров использования методов интеллектуального анализа данных.

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

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

П5. Внедрение и опытная эксплуатация Заключительный этап создания ИХ предполагает комплексное тестирование всех компонентов ИХ (G1–G3) с исправлением всех возникающих ошибок (G4–G6), последующим обучением пользователей и постоянным администрированием в соответствии с установленными правилами и документацией проекта (Д8).

1. Что понимается под клиент-серверной архитектурой? Что такое сервер и клиент?

2. Какие существуют уровни представления клиент-серверной архитектуры?

3. Какие существуют варианты клиент-серверной архитектуры?

4. Какие преимущества обеспечивает клиент-серверная архитектура?

5. Что такое репликация данных, и какие существуют режимы ее осуществления?

6. Какие операции выполняются на стадии техно-рабочего проектирования клиент-серверной архитектуры?

7. Какие операции включает проектирование базы данных в клиент-серверной среде?

8. Что представляет собой система оперативной обработки транзакций (OLTP-система)?

9. Каковы особенности создания систем управления рабочими потоками?

10. Каковы особенности создания Интернет-приложений?

11. Что представляет собой система оперативного анализа данных (OLAP-система)?

12. Каковы особенности организации информации в информационных хранилищах?

13. Какие требования предъявляются к архитектуре информационных хранилищ?

14. Каковы основные компоненты архитектуры информационного хранилища?

15. Каковы основные технологические операции проектирования информационного хранилища?

Тема 7. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС

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

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

Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

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

• подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

• широкое внедрение и постоянный рост производительности персональных ЭВМ, позволяющих использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

• улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

• возможность повторного использования компонентов разработки;

• поддержание адаптивности и сопровождения ЭИС;

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

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

• возможность коллективной разработки ЭИС в режиме реального времени.

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

Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.

Метод – это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных).

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

Инструментальные средства CASE – специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

Рассмотрим архитектуру CASE-средства, которая представлена на рис. 7.1.

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

Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов:

• проектировщиков и их прав доступа к различным компонентам системы;

• организационных структур;

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

• связей между диаграммами;

• структур данных;

• программных модулей;

• библиотеки модулей и т.д.

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

Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции:

• создавать элементы диаграмм и взаимосвязи между ними;

• задавать описания элементов диаграмм;

• задавать описания связей между элементами диаграмм;

• редактировать элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции:

• мониторинг правильности построения диаграмм;

• диагностику и выдачу сообщений об ошибках;

• выделение на диаграмме ошибочных элементов.

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

• инициализации проекта;

• задания начальных параметров проекта;

• назначения и изменения прав доступа к элементам проекта;

• мониторинга выполнения проекта.

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

Современные CASE-системы классифицируются по следующим признакам:

1) по поддерживаемым методологиям проектирования: функционально (или структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2) по поддерживаемым графическим нотациям построения диаграмм, с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных – репозиторием);

4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6) по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших ЭВМ.

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

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

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

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

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

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

• Интерфейсы с другими CASE-системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE-системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методологий.

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

• Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект.

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

• Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью совершенствоваться с учетом появления новых требований или новых предметных областей.

• Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.

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

• Автоматическая генерация отчетов о проектных решениях.

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

• Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.

• Планирование и управление проектом. Использование CASEсистем не исключает потребности в эффективном управлении проектом.

Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спецификации, которые используются этими средствами, представляют собой опорные точки управления, позволяющие определять сроки разработки.

7.2. Функционально-ориентированное проектирование ЭИС Основными идеями функционально-ориентированной CASEтехнологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:

1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;

2) представление всей информации в виде графической нотации.

Систему всегда легче понять, если она изображена графически.

В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:

• BFD (Bussiness Function Diagram) – диаграмма бизнес-функций (функциональные спецификации);

• DFD (Data Flow Diagram) – диаграмма потоков данных;

• STD (State Transition Diagram) – диаграмма переходов состояний (матрицы перекрестных ссылок);

• ERD (Entity Relationship Diagram) – ER-модель данных предметной области (информационно-логические модели «сущность-связь»);

• SSD (System Structure Diagram) – диаграмма структуры программного приложения.

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

• Функция – некоторое действие информационной системы, необходимое для решения экономической задачи;

• Декомпозиция функции – разбиение функции на множество подфункций.

Изображение объектов диаграммы иерархии функций представлено в табл. 7.1 в нотациях:

Изображение объектов диаграммы иерархии функций • Йодана (Yourdon);

• Гейна – Сарсона (Gane – Sarson);

• SADT (Structured Analysis and Design Technique);

• SAG (Software AG).

В качестве примера рассмотрим фрагмент диаграммы иерархии функций в нотации SAG (рис. 7.2) для задачи аналитического учета товаров на складе.

Как видно из рис. 7.2, одной из функций аналитического учета товаров на складе является организация товародвижения. Далее эта функция декомпозируется на следующие подфункции: приемка товара; отпуск товара; ведение БД «Движение товаров»; инвентарный контроль.

Рис. 7.2. Фрагмент диаграммы иерархии функций для задачи аналитического учета товаров на складе Диаграммы потоков данных (ДПД), как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отражаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками задаются имена передаваемых/используемых единиц информации – документов, экранных форм, файлов).

Рассмотрим основные понятия диаграммы потоков данных.

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

Определим основные объекты ДПД и их графические изображения в различных нотациях (табл. 7.2).

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

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

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

Имя хранилища должно идентифицировать его, а также его содержимое, выражается существительным.

Внешняя сущность (источник/приемник данных) – представляет некоторый объект вне системы, являющийся внешним объектом.

Контекстная диаграмма – самый верхний процесс (ТОР-уровень) декомпозиции системы, который отражает общие представления о системе.

В контекстной диаграмме есть один процесс, с которым связаны внешние сущности.

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

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

• на каждом уровне представлять 3–6 процессов и не более;

• не загромождать диаграмму несущественными моментами на данном уровне детализации;

• декомпозицию процессов и потоков вести параллельно;

• выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД;

• однократно определять функционально идентичные процессы (в других местах просто ссылаться на этот процесс);

• использовать ДПД для процессов, которые можно с помощью них описать.

Пример контекстной диаграммы и диаграмм 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе приведен на рис. 7.3.

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

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

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

Рис. 7.3. Контекстная диаграмма и диаграмма 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе Для перехода в состояние нужно какое-либо особое условие – условие перехода. Оно может быть информационным (условие появления информации) или временным. В табл. 7.3 представлены символы ДПС в различных нотациях. Определим основные объекты ДПС.

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

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

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

Триггер – логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.

Условие перехода – событие, вызывающее переход и идентифицируемое именем перехода.

Фрагмент диаграммы переходов состояний для задачи аналитического учета товаров на складе в нотации SAG приведен на рис. 7.4.

Как видно из рисунка, текущее состояние системы представлено ожиданием выбора того или иного пункта меню. Выбрали пункт меню – это информационное событие, а сам выбор – действие перехода в следующее состояние системы. Переход в состояние системы «Ведение БД «Движение товаров» выполняется по логическому условию ИЛИ, что отражено в триггере. Одно из событий этого перехода является временным (дата закрытия периода).

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

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

Рис 7.4. Фрагмент диаграммы переходов состояний для задачи аналитического учета товаров на складе в нотации SAG Объекты ERD в различных методологиях Продолжение табл. 7. Рис. 7.5. Фрагмент диаграммы «сущность-связь» для задачи труда и ЗП Сущность – представляет собой множество экземпляров реальных или абстрактных объектов, которые обладают общими свойствами (атрибутами).

Отношение – связь между 2 и более сущностями (должны иметь имя в виде глагола).

Независимая сущность – представляет независимые данные, которые всегда присутствуют в системе.

Зависимая сущность – представляет данные, которые зависят от других сущностей.

Объекты ERD в различных методологиях представлены в табл.

7.4.

Фрагмент диаграммы «сущность-связь» для задачи учета труда и ЗП представлен на рис. 7.5.

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

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

Объекты SSD в различных методологиях представлены в табл. 7.5.

В качестве примера рассмотрим фрагмент системной структурной диаграммы в нотации SAG (рис. 7.6) для задачи аналитического учета товаров на складе. Технологическая сеть проектирования ЭИС на основе использования функционально-ориентированной CASE-технологии представлена на рис. 7.7.

Технологические операции с преобразователями П1, П2, П3, П4, П5, П6, П7 выполняются на стадии технического проектирования.

Преобразователь П1 «Инициализация проекта» используется для инициализации нового проекта ЭИС. На основании документа D «Материалы обследования» создается новый репозиторий G1 для проектируемой системы.

Преобразователем П2 «Задание начальных параметров проекта» из универсума методологий проектирования U1 выбирается CASEметодология проектирования и в рамках выбранной методологии определяется нотация на основе универсума U2. Перечень проектировщиков и их прав доступа к проекту D2 служит для описания коллектива разработчиков проекта. Результатом выполнения операции является описание начальных параметров проекта в репозитории D3.

Основные объекты SSD и их отображение в различных нотациях Технологические операции с преобразователями П3, П4, П5 и П выполняются последовательно-параллельно и взаимно уточняются в ходе выполнения.

На основе «Материалов обследования» D1 и универсума конструктивных элементов диаграмм иерархии функций U3 выполняется технологическая операция с преобразователем П3 «Построение диаграммы иерархии функций».

Выполнение преобразователя П3 сводится к выполнению следующих работ:

• отображению основной функции;

• декомпозиции основной функции на подфункции;

• дальнейшей декомпозиции подфункций до необходимой степени детализации;

• контролю правильности построенной диаграммы.

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

Входом технологической операции с преобразователем П4 «Построение диаграммы потоков данных» являются:

• материалы обследования (D1);

• диаграмма иерархии функций (D4);

• диаграмма «сущность-связь» (D6);

• универсум конструктивных элементов диаграмм потоков данных U4.

Рис. 7.6. Фрагмент SSD-диаграммы в нотации SAG для задачи Построение ДПД можно свести к следующим шагам:

1. Расчленение множества требований на функциональные группы.

2. Идентификация внешних объектов (по отношению к системе).

3. Идентификация информации, которая передается между процессами.

4. Разработка контекстной диаграммы.

5. Контроль контекстной диаграммы и уточнение, если это нужно.

Рис. 7.7. Технологическая сеть проектирования ЭИС на основе использования функциональнооринентированной CASE-технологии: D1 – материалы обследования; D2 – перечень проектировщиков и прав доступа; D3 – описание начальных параметров проекта; D4 – диаграмма функций проекта;

D5 – диаграмма потоков данных; D6 – диаграмма сущность-связь; D7 – диаграмма переходов состояний;

D8 – системная структурная диаграмма; D9 – схема БД; D10 – модуль описания данных; D11 – модули программного приложения; U1- универсум CASE-методологий проектирования; U2 – универсум нотаций;

U3 – конструктивные элементы диаграмм иерархии функций; U4 – контсруктивные элементы диаграмм потоков данных; U5 - контсруктивные элементы диаграмм «сущность-связь»; U6 – контсруктивные элементы диаграмм переходов состояний; U7 – контсруктивные элементы программного приложения;

U8 – универсум целевых СУБД; U9 – универсум языков определенных данных; U10 – универсум языков определения модулей; G1 – новый репозиторий; G2 – программное приложение 6. Формирование ДПД первого уровня, где отражены основные функции системы.

7. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде некоторой спецификации (алгоритма).

8. Ревизия всех уровней с целью выяснения некорректности, а при ее обнаружении – устранение.

Выходом данной операции является описание в репозитории диаграммы потоков данных D5.

Преобразователь технологической операции П5 «Построение диаграммы переходов состояний» описывает возможные состояния проектируемой системы и переходы между ними.

При построении ДПС рекомендуется следовать перечисленным ниже правилам:

1) начинать построение ДПС на высоком уровне детализации ДПД;

2) строить наиболее простые диаграммы, содержащие 4–6 состояний;

3) по возможности включать детализацию в виде подчиненных шагов состояния (детализация на другом уровне);

4) использовать те же приемы наименования состояний, событий и действий, что и при наименовании процессов и потоков.

Применяются 2 способа построения ДПС:

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

• при втором способе сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д. (последовательный переход).

В результате получаем предварительную ДПС. Затем она проверяется на корректность ее построения. Когда число состояний и переходов достаточно велико, эта диаграмма может быть представлена в табличной форме «Матрица переходов состояний» (рис. 7.8).

Входом преобразователя являются:

• материалы обследования (D1);

• диаграмма иерархии функций (D4);

• диаграмма потоков данных (D5);

• диаграмма «сущность-связь» (D6);

• универсум конструктивных элементов диаграмм переходов состояний (U6).

Выход дайной операции представлен интегрированным описанием в репозитории функций, потоков данных и состояний проектируемой системы (D7).

Рис. 7.8. Графы матрицы переходов состояний Технологическая операция с преобразователем П6 «Построение диаграммы «Сущность-связь» моделирует структуры данных, которые будут храниться в БД. Для ее выполнения необходима следующая входная информация:

• материалы обследования (D1);

• диаграмма потоков данных (D5);

• универсум конструктивных элементов диаграмм «сущностьсвязь» (U5).

Построение ER-диаграмм сводится к следующим этапам.

1. Идентифицируются все сущности, их атрибуты, а также первичные ключи.

2. Идентифицируются отношения между сущностями, и указывается мощность этих отношений.

3. Если на втором этапе были выявлены отношения N:N, такие отношения являются неспецифическими для реляционных, и их нужно преобразовать либо в 1:N, либо в 1:1. Как правило, это делается с помощью добавления новой сущности.

Выход данной операции представлен описанием в репозитории диаграммы «сущность-связь» (D6).

Технологическая операция с преобразователем П7 «Построение системной структурной диаграммы» используется для построения структуры программного приложения ЭИС (D8).

На вход преобразователя подаются:

• диаграмма иерархии функций (D4);

• диаграмма потоков данных (D5);

• диаграмма «сущность-связь» (D6);

• диаграмма переходов состояний (D7);

• универсум конструктивных элементов программного приложения (U7).

Выходом преобразователя служит описание в репозитории структуры программного приложения (D8).

Этапы построения системной структурной диаграммы.

1. В диаграмме бизнес-функций необходимо выделить функции, которые будут реализованы в программном виде.

2. Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных.

3. Определить структуру потоков данных, задав список атрибутов сущностей из ER-диаграммы.

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

5. Задать программную реализацию каждого состояния в виде библиотечного модуля CASE-системы или модуля, написанного на другом языке.

6. Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции.

7. Объединить построенные системные структурные диаграммы в одну исходя из диаграммы бизнес-функции.

8. Проконтролировать, если позволяют CASE-средства, построенную системную структурную диаграмму.

9. Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы.

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

Таким образом, перед генерацией все элементы системной структурной диаграммы должны быть определены с учетом интерфейса и связи с таблицами ER-модели.

Технологические операции с преобразователями П8–П11 отражают процесс кодогенерации проекта.

Преобразователь П8 «Генерация описания схемы БД». На основе диаграммы «сущность-связь» (D6) и системной структурной диаграммы (D8), а также универсума целевых СУБД (U8) происходит выбор СУБД и генерация для нее описания схемы БД (D9).

Преобразователь П9 «Генерация модуля описания системы БД (DDL)». Входом для технологической операции с преобразователем П служат:

• описание схемы БД (D9);

• структура программного приложения (D8);

• универсум языков определения данных (DDL) (U9).

В результате процесса генерации получаем исходные тексты программ на языке выбранной среды (D9). Генерация может быть двух видов:

1. Неполная генерация заключается в том, что на основе диаграммы «сущность-связь» и выбранной целевой СУБД генерируются модули описания данных DDL на языке описания данных. В результате выполнения неполной генерации на выбранном языке определения данных (SQL и т. п.) создается модуль описания данных (D10).

2. Полная генерация включает в себя:

• генерацию DDL на языке описания данных;

• выбор среды, в которой будет приведен исходный код, полученный во время генерации;

• запуск процесса генерации.

Преобразователь П10 «Генерация приложения (DDM)». На основе системной структурной диаграммы (D8) и универсума языков определения модулей DDM (U10) происходит генерация модулей программного приложения П10. Результатом генерации являются модули программного приложения, реализующего ЭИС (D11).

Преобразователь П11 «Интеграция модулей приложения». В результате выполнения технологической операции с преобразователем П11 происходит интеграция полученных ранее модулей D10 и D11, что приводит к получению готового программного приложения, реализующего ЭИС (G2).

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

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

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) [89] и фактически является стандартом по объектноориентированным технологиям. Язык UML реализован многими фирмами-производителями программного обеспечения в рамках CASEтехнологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др.

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1) диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций;

2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;

3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;

4) диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);

6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);

7) диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;

8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

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

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

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

В реализации прецедента использования возможно выделение нескольких потоков событий:

• основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек;

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

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

Несколько прецедентов использования может иметь общую часть, выделяемую в самостоятельный прецедент использования, с которым устанавливаются отношения использования (uses). С другой стороны, некоторые прецеденты использования могут быть расширены деталями.

В таком случае создается дополнительный прецедент использования, с которым устанавливаются отношения расширения (extends). Пример применения такого рода отношений показан на рис. 7.10.

Рис. 7.9. Диаграмма прецедентов использования Рис. 7.10. Пример применения отношений использования и расширения Диаграммы классов объектов (Class diagram) Диаграммы классов объектов (Class diagram) отображают статическую структуру классов объектов. Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов.

Классы объектов могут иметь различные стереотипы поведения:

объекты-сущности, управляющие объекты, интерфейсные объекты:

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

К статическим отношениям относятся обобщение, агрегация, ассоциация объектов:

Пример использования статических отношений представлен на рис.7.11.

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

Диаграммы состояний (Statechart diagram) Диаграмма состояний отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и определяет:

• какие типичные состояния проходит объект;

• какие события ведут к изменению состояния объекта;

• какие действия объект выполняет, когда он получает сообщение об изменении состояния;

• как объекты создаются и уничтожаются (входные и выходные точки диаграммы).

Ниже представлены используемые в диаграмме состояний понятия и их графическое обозначение:

Рис. 7.11. Фрагмент диаграммы классов объектов Входная точка определяет событие, которое образует начальное состояние объекта. В точку входа нельзя перейти из состояния объекта.

Выходная точка определяет завершение существования объекта.

Из точки выхода нет перехода состояния.

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

С каждым состоянием связано одно событие или более, которые могут его изменить. Для состояния задаются имена всех связанных с ним переходов в другие состояния.

Рис. 7.12. Пример диаграммы состояния для объекта «строка заказа»

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

Переход состояний описывается следующими атрибутами:

Назначение – состояние объекта, в которое перейдет объект после перехода состояния.

Вызов – имя события, которое вызывает переход состояний. Имена событий должны быть идентичными в определении класса и состояния.

Вызываемые события могут быть либо внешними, осуществляемыми актерами, либо внутренними, связанными с поведением других объектов, либо временными, связанными с истечением заданного интервала времени.

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

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

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

Пример модели перехода состояний представлен на рис. 7.12.

Диаграмма взаимодействия объектов (interaction diagram) Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:

• в форме диаграммы последовательностей (sequence diagram), показывающей последовательность взаимодействий на графе;

• в форме кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме.

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

Диаграмма кооперативного поведения представляется в табличном виде по следующим правилам.

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

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

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

Пример кооперативной диаграммы представлен на рис. 7.14.

Рис. 7.13. Диаграмма последовательностей для прецедента Диаграммы взаимодействий не отражают детально порядок выполнения операций в части разветвлений, циклических повторений, параллельности/произвольности действий. Диаграмма деятельностей исправляет данные недостатки. Под деятельностью будем понимать некоторую работу, которая может быть декомпозирована на совокупность действий.

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

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

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

Пример диаграммы деятельностей представлен на рис. 7.15.

Рис. 7.14. Диаграмма кооперативного поведения для основного потока событий прецедента использования «Выполнить заказ»

Рис. 7.15. Диаграмма деятельности процесса выполнения заказа В объектно-ориентированном подходе пакет содержит множество взаимосвязанных классов объектов и соответствует понятию «подсистема функционально-ориентированного подхода». Один прецедент использования может требовать классы объектов из разных пакетов. Класс объектов обычно назначается одному пакету, но с позиции достижения разных подцелей может входить в состав разных пакетов.

Пакетная технология группирования классов объектов позволяет упростить:

• разработку и эксплуатацию ЭИС;

• гибкую адаптацию типовых компонентов с позиции их повторного использования;

• оптимизацию клиент-серверной архитектуры ЭИС.

Обычно ЭИС разбивается на функциональные и обеспечивающие пакеты (рис. 7.16). Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет «Проблемная область». Каждый пакет, в свою очередь, может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов.

Обычно пакеты проблемной области содержат иерархии обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемах, выделяются в самостоятельные пакеты. В одном пакете, как правило, определяется не более 20 компонентов, обычно 5–15.

С обеспечивающей точки зрения ЭИС разбивают на пять основных пакетов:

• «Интерфейс», объекты которого реализуют функции взаимодействия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между подсистемами;

• «База данных», объекты которого выполняют доступ к данным во внешней памяти;

• «Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например, в системе управления рабочими потоками;

• «Утилиты», объекты которого осуществляют вспомогательные функции, например преобразование форматов данных;

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

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

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

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

В модели размещения отображается топология расположения компонентов по узлам вычислительной сети. Отдельный компонент всегда располагается на одном компьютере-сервере. На одном компьютересервере может располагаться несколько компонентов (рис. 7.17).

Рис. 7.17. Пример диаграммы компонентов размещения Рассмотрим технологическую сеть проектирования ЭИС на основе использования объектно-ориентированной CASE-технологии, для которой характерны последовательное расширение и уточнение моделей на различных стадиях жизненного цикла ЭИС: анализа системных требований, логического и физического проектирования, реализации. Технологическая сеть объектно-ориентированного проектирования ЭИС (рис. 7.18) представляет собой обобщение методологий Objectory [89] и Natural Engineering Workbench [110].

Рис. 7.18. Технологическая сеть объектно-ориентированного проектирования ЭИС: Dобсл – описание организационно-экономической системы; D`пн, D``пн – диаграммы прецедентов использования ЭИС;

D`o, D``o, D```o – диаграммы классов объектов; D`с, D``с, D```с – диаграммы состояний объектов; D`пк, D``пк, D```пк – диаграммы пакетов;

D``в – диаграммы взаимодействий; D``д, D```д, - диаграммы деятельностей;

D```д – диаграммы компонентов; Uоояп – универсум объектно-ориентированнных языков программирования; Gо – классы объектов; Gм – процедуры методов Технологическая сеть анализа системных требований к ЭИС представлена на рис. 7.19. На входе этапа анализа системных требований используется описание организационно-экономической системы (Dобсл), полученное в ходе работ по анализу и проектированию бизнеспроцессов. Эти материалы содержат описание организационной структуры, структуры материальных, финансовых и информационных потоков, которое может быть выполнено либо с помощью традиционных средств графического отображения, либо с помощью определенных методологий бизнес-реинжиниринга, например, с помощью той же объектно-ориентированной методологии.

Рис. 7.19. Технологическая сеть системного анализа требований:

Dобсл – описание организационно-экономической системы; D`пи – диаграмма прецедентов использования ЭИС; D`о – диаграмма классов объектов; D`c – диаграммы состояний объектов; D` пк – диаграмма пакетов Так, в объектно-ориентированной методологии анализа и проектирования бизнес-процессов предусматриваются [107]:

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

2. Задание порядка разработки и автоматизации бизнес-процессов в соответствии с определенными критериями, например наибольшим эффектом для заказчика, простотой и быстротой разработки и т. д.

3. Неформальное словесное описание бизнес-процессов.

Структура основных бизнес-объектов и их взаимодействий описывается в соответствии с требованиями модели классов объектов.

Анализ системных требований начинается с идентификации основных прецедентов использования (D’пи) и объектов-сущностей (D’о), которые будут применяться в информационной системе. Работы по идентификации прецедентов использования и классов объектовсущностей, как правило, выполняются параллельно. В случае объектноориентированного оформления результатов предпроектного обследования данная работа упрощается в силу однозначности соответствия бизнес-процессов и прецедентов использования ЭИС, бизнес-объектов и объектов-сущностей.

Разработка D’пи – диаграммы прецедентов использования ЭИС (преобразователь П11) предполагает выделение тех последовательностей транзакций, которые будут автоматизировать требуемые бизнеспроцессы. При этом определяются основные пользователи-актеры, взаимодействующие с прецедентами использования.

Разработка D’o – диаграммы классов объектов (преобразователь П12) предполагает задание состава основных атрибутов и определение характера взаимосвязей классов объектов.

Разработка D’c – диаграммы состояний объектов (преобразователь П13) осуществляется только для классов объектов со сложным поведением. При этом рассматриваются все прецеденты использования, в которых объекты данного класса используются и меняют свои состояния.

Разработка D’пк – диаграммы пакетов (преобразователь П14) осуществляется путем группировки классов объектов по подсистемам. На этапе анализа системных требований определяется состав пакетов, относящихся к пакету «Проблемная область». При этом выделяются функциональные пакеты, которые объединяют классы объектов, реализующие функции управления, и базовые пакеты с нормативносправочной информацией, общие для функциональных пакетов.

На этапе логического проектирования ЭИС осуществляются детализация моделей прецедентов использования, классов объектов, состояний, пакетов и разработка моделей взаимодействия объектов и деятельностей, которые определяют характер методов (процедур) обработки объектов (рис. 7.20).

Детализация D”пи – диаграммы прецедентов использования (преобразователь П21) предполагает разработку основных и альтернативных потоков событий, которые могут быть представлены самостоятельными диаграммами прецедентов использования. Кроме того, могут быть выделены прецеденты использования, расширяющие набор функций основных прецедентов, или из нескольких прецедентов использования могут быть выделены общие функции в самостоятельные прецеденты. При этом соответственно задаются отношения расширения и использования.

Детализация D”о – диаграммы классов объектов (преобразователь П22) выполняется путем уточнения классов объектов-сущностей и введения интерфейсных и управляющих классов объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов – координирующим функциям обработки объектов-сущностей.

Рис. 7.20. Технологическая чепь логического проектирования: D`пи, D`` пи – диаграммы прецедентов использования ЭИС; D`о, D``о – диаграммы классов объектов; D`с, D``с – диаграммы состояний объектов;

D`пк, D``пк – диаграммы пакетов; D``в – диаграммы взаимодействий; D`` д – диаграммы деятельностей Уточнение D"с – диаграммы состояний объектов (преобразователь П23) выполняется в связи с детализацией диаграммы прецедентов использования D”пи и диаграммы классов объектов D”о.

Разработка D"в – диаграммы взаимодействий (преобразователь П24) выполняется для каждого прецедента использования с учетом построенных диаграмм классов объектов и состояний. В частности, сообщение от одного объекта к другому в диаграмме взаимодействия должно соответствовать событию, вызывающему переход состояния объекта получателя сообщения в диаграмме состояний. Аналогично внешнее событие в диаграмме взаимодействий, вызываемое актером, соответствует событию, осуществляющему переход состояния объекта в диаграмме состояний.

Разработка D"д – диаграммы деятельностей (преобразователь П25) уточняет характер взаимодействия объектов не в одном, а в нескольких прецедентах использования. Если диаграммы взаимодействий объектов формируют набор методов обработки объектов, то диаграммы деятельностей дают спецификацию алгоритмов для последующего программирования процедур этих методов.

Детализация D"пк – диаграммы пакетов (преобразователь П26) связана с уточнением состава классов объектов-сущностей и появлением интерфейсных и управляющих классов объектов. Например, интерфейсные и управляющие классы объектов могут быть выделены в самостоятельные обеспечивающие пакеты.

На этапе физического проектирования происходит детализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде (рис. 7.21).

Спецификация физической реализации D’’’o – диаграммы классов объектов (преобразователь П31) предусматривает определение форматов данных для атрибутов и методов реализации отношений (ключей, указателей, процедур) классов объектов.

Детализация D’’’пк – диаграммы пакетов (преобразователь П32) предполагает разработку обеспечивающих компонентов: базы данных, управления задачами, вспомогательных функций.

Разработка D’’’к – диаграммы компонентов (преобразователь П33) и D'''p – диаграммы размещения компонентов (преобразователь П34) реализует клиент-серверную технологию и определяет схему размещения компонентов по узлам вычислительной сети.

Рис. 7.21. Технологическая сеть физического проектирования:

D``о, D```о –диаграммы классов объектов; D``с, D```с – диаграммы состояний объектов; D``пк, D```пк – диаграммы пакетов; D```к – диаграмма компонентов;

D```р – диаграмма размещения компонентов На этапе реализации ЭИС осуществляются кодогенерация классов объектов, программирование процедур методов классов объектов, наполнение баз данных и размещение компонентов по узлам вычислительной сети (рис. 7.22).

Генерация Go – классов объектов (преобразователь П41) в конкретной объектно-ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из Uооя – универсума объектноориентированных языков программирования, осуществляется на основе диаграммы классов объектов D"'о.

Генерация Gш – шаблонов процедур методов класса объектов (преобразователь П42) в конкретной объектно-ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из универсума объектно-ориентированных языков программирования, производится на основе диаграммы взаимодействий объектов D’’в.

Программирование Gм процедур методов класса объектов (преобразователь П43) с помощью объектно-ориентированного языка программирования выполняется на основе Gш – шаблонов процедур методов классов объектов по спецификациям D’’’д – диаграмм деятельностей и Dc" – состояний объектов.

Рис 7.22. Технологическая есть реализации ЭИС: Uоояп – универсум объектноориентированных языков программирования; D```о – диаграммы классов объектов;

D```с – диаграммы состояний объектов; D```пк – диаграмма пакетов;

D``в – диаграммы взаимодействий; D```д – диаграмма активностей;

D```к – диаграмма компонентов; D```р – диаграмма размещения копмонентов;

Gо – классы объектов; Gш – шаблоны процедур методов класса объектов;

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

Основное желание заказчика ЭИС – получить готовое приложение высокого качества быстро при минимальных затратах на его разработку.

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

Одним из условий обеспечения высокого качества создаваемых ЭИС является активное вовлечение конечных пользователей в процесс разработки предназначенных для них интерактивных систем, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD (Rapid Application Development).

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

При создании более сложных корпоративных ЭИС пользователям необходимо работать совместно с проектировщиками на протяжении всего периода разработки. Одним из путей повышения качества и эффективности создаваемых таким образом систем является применение технологии прототипного проектирования.

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

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

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

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

Рассмотрим основные возможности и преимущества быстрой разработки прототипа ЭИС (рис. 7.23).

Все приемы для быстрой разработки приложений RAD служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:

1) разработка приложения итерациями;

2) необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем;

3) обязательное вовлечение пользователей в процесс проектирования и построения системы;

4) высокая параллельность работ;

5) повторное использование частей проекта;

6) необходимое применение CASE-средств, обеспечивающих техническую целостность на этапах анализа и проектирования;

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

8) использование автоматических генераторов (мастеров);

9) использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;

10) тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.

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

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

Основная проблема процесса разработки ЭИС по RADтехнологии заключается в определении момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков с использованием инструментов автоматизации процесса планирования. Средства автоматизации планирования являются важным элементом при разработке приложений по методологии RAD. Они применяются для определения состава и объема работ, необходимого числа разработчиков, распределения работ между участниками проекта, контроля за ходом выполнения работ и динамической корректировкой плана.

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

Такие инструментальные средства можно условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД – класс DEVELOPER и интегрированные инструменты быстрой разработки приложений – класс BUILDER.

К инструментам этих классов можно отнести средства 4GL (генераторы компонентов приложений):

• генераторы таблиц базы данных;

• генераторы форм ввода-вывода;

• генераторы запросов;

• генераторы отчетов;

• генераторы меню.

Такие генераторы существуют почти во всех СУБД, как персональных Access, FoxPro, Paradox, так и в окружении промышленных серверов БД (Oracle, Informix, Adabas D и др.).

Отличительной чертой класса BUILDER является то, что инструменты данного класса легко интегрируются с CASE-средствами и представляют собой единую среду быстрой разработки приложения. К интегрированным инструментам класса BUILDER можно отнести такие, как Power Builder Enterprise (Power Soft), Delphi (Borland), Builder Си ++ и др.

Рассмотрим инструментальную среду быстрой разработки приложений СУБД Access, которая включает ряд мастеров (конструкторов).

• Мастер (конструктор) таблиц предназначен для быстрого создания структуры/таблиц БД и их взаимосвязей.

• Мастер (конструктор) форм ввода-вывода позволяет быстро создать экраны ввода информации в БД различного типа (ленточные, в столбец, табличные).

• Мастер (конструктор) запросов позволяет создавать запросы различной сложности.

Рис. 7.23. Основные возможности и преимущества протоитпа ЭИС • Мастер (конструктор) отчетов позволяет создавать отчеты на базе нескольких таблиц или запросов.

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

Работа с мастером заключается в пошаговом выполнении настройки мастера.

Работа с конструктором заключается в детальном определении конструктивных элементов содержания проектируемой компоненты ЭИС.

Жизненный цикл создания ЭИС на основе RAD-технологии предполагает после формирования технического задания и декомпозиции системы независимую разработку подсистем с последующей сборкой, тестированием и внедрением комплексной ЭИС (рис. 7.24).

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

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

Технологическая сеть проектирования (ТСП) данного варианта на стадии техно-рабочего проектирования ЭИС представлена на рис. 7.25.

В соответствии с технологической сетью проектирования (рис.

7.25) на основе технического задания (Д1) и описания предметной области (Д2) выполняется преобразователь П1, предназначенный для разработки постановки задачи (Д3). Технологическая операция с преобразователем П2 служит для разработки системы-прототипа на основе спецификаций постановки задачи (Д3) и выбранного средства из универсума средств быстрой разработки приложений (U1). Выходом операции является готовое приложение-прототип (G1). Результаты работы приложения-прототипа (Д4) демонстрируются заказчику (преобразователь ПЗ), после чего формируются замечания и уточненные требования к ЭИС (Д5) и происходит доработка прототипа (преобразователь П4). На основании результатов доработки прототипа (G2) формируется (преобразователь П5) новая постановка задачи (Д6). Технологическая операция с преобразователем П6 предназначена для разработки действующего программного приложения (G3).

Рис. 7.24. Жизненный цикл создания ЭИС на основе RAD - технологии Основным недостатком первого варианта использования прототипирования является неэффективное использование системыпрототипа, а именно: прототипы не используются в дальнейшей разработке ЭИС после того, как выполнили свою первую задачу – устранили неясности в проекте.

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

В соответствии с технологической сетью проектирования на основе технического задания (Д1), описания предметной области (Д2), выбранного средства из универсума средств быстрой разработки приложений (RAD-средств U1) выполняется преобразователь П1, предназначенный для разработки системы-прототипа. Выходом операции является готовое приложение-прототип (G1).

Рис. 7.25. Технологическая сеть проектирования традиционного использования прототипа ЭИС: Д1 – техническое задание на разработку;

Д2 – описание предметной области; Д3 – постановка задачи;

U1 – универсум средств быстрой разработки приложений;

G1 – приложение-прототип; Д4 – результаты работы приложения-прототипа;

Д5 – замечания и уточненные требования к ЭИС; G2 – доработанный прототип;

Д6 – новая постановка задачи; U2 – универсум средств разработки приложений;

G3 – готовое приложение Результаты работы приложения-прототипа (Д4) демонстрируются заказчику (преобразователь П2), после чего либо формируются замечания и уточненные требования к ЭИС (Д5) и происходят доработка прототипа (преобразователь ПЗ) и разработка новых спецификацийтребований (Д6) (преобразователь П4) либо система-прототип полностью удовлетворяет требованиям заказчика, и она документируется (преобразователь П5) и сдается в виде готового программного приложения (G3) с соответствующей документацией (Д7).

Рис. 7.26. Технологическая сеть проектирования итерационного использования прототипа ЭИС: Д1 – техническое задание на разработку;

Д2 – описание предметной области; U1 – универсум средств быстрой разработки приложений; G1 – приложение-прототип; Д4 – результаты работы приложения прототипа; Д5 – замечания и уточненные требования к ЭИС; G2 – доработанный прототип; Д6 – новые спецификации требования; G3 – готовое приложение Итерационное использование прототипного подхода к разработке ЭИС обеспечивает экономию ресурсов на проектирование, а самое главное, – резкое сокращение времени на разработку и внедрение готовой к эксплуатации системы. При этом основным достоинством прототипной технологии является значительное снижение объема доработок ЭИС при ее внедрении, который для традиционных методов проектирования, как показывает опыт, соразмерен с затратами на первоначальную реализацию.

1. Дайте определение CASE-технологии проектирования ЭИС.

2. Какова структура CASE-средства?

3. Какие классы CASE-средств существуют?

4. Как можно определить стратегию выбора CASE-средства?

5. Как можно определить функционально-ориентированную CASE-технологию?

6. Какие диаграммы выступают в качестве инструментальных средств функционально-ориентированного анализа и проектирования?

7. Зачем создаются диаграммы функциональных спецификаций?

8. Определите основные понятия и конструктивные элементы диаграммы функциональных спецификаций.

9. Зачем создаются диаграммы потоков данных?

10. Определите основные понятия и конструктивные элементы диаграммы потоков данных.

11. Зачем создаются диаграммы переходов состояний?

12. Определите основные понятия и конструктивные элементы диаграммы переходов состояний.

13. Зачем создаются диаграммы «сущность-связь»?

14. Определите основные понятия и конструктивные элементы диаграммы «сущность-связь».

15. Зачем создаются системные структурные диаграммы?

16. Определите основные понятия и конструктивные элементы системной структурной диаграммы.

17. Определите технологическую сеть проектирования ЭИС при использовании функционально-ориентированного CASE-средства.

18. Определите технологическую сеть проектирования ЭИС при использовании функционально-ориентированного CASE-средства.

19. Какие диаграммы выступают в качестве инструментальных средств объектно-ориентированного анализа и проектирования?

20. Зачем создаются диаграммы прецедентов использования?

21. Определите основные понятия и конструктивные элементы прецедентов использования.

22. Зачем создаются диаграммы классов объектов?

23. Определите основные понятия и конструктивные элементы диаграммы классов объектов.

24. Зачем создаются диаграммы состояний?

25. Определите основные понятия и конструктивные элементы диаграммы состояний.

26. Зачем создаются диаграммы взаимодействия объектов?

27. Определите основные понятия и конструктивные элементы диаграммы взаимодействия объектов.

28. Какие существуют виды диаграмм взаимодействия объектов?

29. Зачем создаются диаграммы деятельностей?

30. Определите основные понятия и конструктивные элементы диаграммы деятельностей.

31. Зачем создаются диаграммы пакетов?

32. Определите основные понятия и конструктивные элементы диаграммы пакетов.

33. Зачем создаются диаграммы компонентов и размещения?

34. Определите основные понятия и конструктивные элементы диаграмм компонентов и размещения.

35. Определите технологическую сеть проектирования ЭИС при использовании объектно-ориентированного CASE-средства.

36. В чем заключается процесс генерации программного приложения ЭИС?

37. В чем заключается сущность прототипной (RAD) технологии?

38. Каковы основные возможности и преимущества быстрой разработки прототипа ЭИС?

39. Как классифицируются инструментальные средства быстрого прототипирования ЭИС?

40. Чем отличаются технологии традиционного и итерационного прототипирования ЭИС?

СПИСОК ЛИТЕРАТУРЫ

1. Автоматизация управления предприятием / В.В. Баронов, Г.Н.

Калянов, Ю.Н. Попов и др. – М.: Инфра-М, 2000.

2. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г.А. Титоренко. – М.: Компьютер, ЮНИТИ, 1998.

3. Автоматизированные системы управления предприятиями / Под ред. Г.А. Титоренко. – М.: Финансы и статистика, 1983.

4. Алан Р. Саймон. Стратегические технологии баз данных: менеджмент на 2000 год / Пер. с англ. и предисл. М.Р. Когаловского. – М.:Финансы и статистика, 1999.

5. Араксян В.В., Хорхамелидзе Т.Г. Автоматизация построения структур диалога пользователя – ЭВМ на основе графотопологических представлений. Автоматизация проектирования АСУ. – М.: ИПУ АН СССР, 1982.

6. Берновский Ю.Н., Максимовский М.Ю. Применение штриховых кодов в торговле // Стандарты и качество. – 1994. – № 3.

7. Экономика, разработка и использование программного обеспечения ЭВМ / В.А. Благодатских, М.А. Енгибарян, Е.В. Ковалевская и др. – М.: Финансы и статистика, 1995.

8. Буч Г. Объектно-ориентированное проектирование с примерами применения: Пер. с англ. – М.: Конкорд, 1992.

9. Введение в информационный бизнес / Под ред. В.П. Тихомирова, А.В. Хорошилова. – М.: Финансы и статистика, 1996. – 246 с.

10. Ведев Д., Любимов А. Российский рынок системной интеграции в 1996 г. // Компьютер Пресс. – 1997. – № 4.

11. Вендров A.M. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000.

12. Гайкович В., Першин А. Безопасность электронных банковских систем. – М.: Единая Европа, 1994.

13. Гост 19.001-77. Единая система программной документации:

Общие положения. – М.: Изд-во стандартов, 1994.

14. Гост 19.101-77. Единая система программной документации:

Виды программ и программных документов. – М.: Изд-во стандартов, 1994.

15. Гост 19.102-77. Единая система программной документации:

Стадии разработки. – М.: Изд-во стандартов, 1994.

16. Гост 19.105-78. Единая система программной документации:

Общие требования к программным документам. – М.: Изд-во стандартов, 1994.

17. Гост 19.201-78. Единая система программной документации:

Техническое задание. Требования к содержанию и оформлению. – М.:

Изд-во стандартов, 1994.

18. Гост 19.202-78. Единая система программной документации:

Спецификация. Требования к содержанию и оформлению. – М.: Изд-во стандартов, 1994.

19. Гост 19.502-78. Единая система программной документации:

Описание применения. Требования к содержанию и оформлению. – М.:

Изд-во стандартов, 1994.

20. Гост 19.404-79. Единая система программной документации:

Пояснительная записка: Требования к содержанию и оформлению. – М.:

Изд-во стандартов, 1994.

21. Гост 19.503-79. Единая система программной документации:

Руководство системного программиста. Требования к содержанию и оформлению. – М.: Изд-во стандартов, 1994.

22. Гост 19.504-79. Единая система программной документации:

Руководство программиста. Требования к содержанию и оформлению. – М.: Изд-во стандартов, 1994.

23. Гост 19.505-79. Единая система программной документации:

Руководство оператора. Требования к содержанию и оформлению. – М.:

Изд-во стандартов, 1994.

24. Гост 19.507-79. Единая система программной документации:

Ведомость эксплуатационных документов. – М.: Изд-во стандартов, 1994.

25. Гост 3.11.09-82. Система технологической документации: Термины и определения основных понятий. – М.: Изд-во стандартов, 1994.

26. Гост 20.886-85. Организация данных в системах обработки данных: Термины и определения. – М.: Изд-во стандартов, 1994.

27. Гост 6.61.1-87. Единая система классификации и кодирования технико-экономической информации. Основные положения. – М.: Издво стандартов, 1994.

28. Гост 6.10.1-88. УСД. Основные положения. – М.: Изд-во стандартов, 1994.

29. Гост 24.402-88. Организация данных в системах обработки данных: Термины и определения. – М.: Изд-во стандартов, 1994.

30. Гост 28.147-89. Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. – М.: Изд-во стандартов, 1991.

31. Гост 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем. – М.: Изд-во стандартов, 1991.

32. Гост 34.602-89. Техническое задание на создание автоматизированной системы. – М.: Изд-во стандартов, 1991.

33. Гост 15.971-90. Системы обработки информации: Термины и определения. – М.: Изд-во стандартов, 1994.

34. Гост 19.701-90. Единая система программной документации:

Схемы алгоритмов, программ данных и систем. Условные обозначения и правила выполнения. – М.: Изд-во стандартов, 1994.

35. Гост 19.781-90. Обеспечение систем обработки информации программное: Термины и определения. – М.: Изд-во стандартов, 1994.

36. Гост 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы: Автоматизированные системы:

Термины и определения. – М.: Изд-во стандартов, 1991.

37. Гост 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы.

Стадии создания. – М.: Изд-во стандартов, 1991.

38. Гостехкомиссия России. Руководящий документ. Концепция защиты СВТ и АС от НСД к информации. – М.: Воениздат, 1992.

39. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации. – М., 1992.

40. Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. – М., 1992.

41. Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в автоматизированных системах и средствах вычислительной техники. – М., 1992.

42. Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации: Термины и определения.

– М., 1992.

43. Диго С.М. Проектирование и эксплуатация баз данных. – М.:

Финансы и статистика, 1995.

44. Дейт К. Дж. Введение в системы баз данных. – 6-е изд. – М., СПб., Киев, Изд. дом Вильямc, 2000.

45. Демидов Н.Н. Проектирование диалога в интерактивных системах на основе конечных автоматов // Труды ЦНИПИАСС. – М., 1973.

– Вып. 23. – С. 44–53.

46. Ефимова О.А. Технология проектирования и внедрения информационных систем – интегрированная технология ARIS // Реинжиниринг бизнес-процессов предприятий на основе современных информационных технологий: Сб. научных трудов 3-й Российской научнопрактической конференции. – М.: МЭСИ, 1999. – С. 215–218.

47. Жельников Л. Криптография от папируса до компьютера. – М.:

ABF, 1996.

48. Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг // СУБД. – 1995. – № 4.

49. Иванов А.П. Вычислительные параметры экономических задач. – М.: Статистика, 1976. – 168 с.

50. Информационные системы в экономике: Учебник / Под ред.

проф. В.В. Дика. – М.: Финансы и статистика, 1996.

51. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 1999.

52. Калянов Г.Н. Консалтинг при автоматизации предприятий:

Научно-практическое издание. – М.: СИНТЕГ, 1997 (Серия «Информатизация России на пороге XXI века»).

53. Китова О.В. Продукты Software AG для электронного бизнеса // Реинжиниринг бизнес-процессов предприятий на основе современных информационных технологий: Сб. научных трудов 3-й Российской научно-практической конференции. – М.: МЭСИ, 1999.

54. Козлов В.А. Открытые информационные системы. – М: Финансы и статистика, 1999.

55. Комплекс общеотраслевых руководящих методических материалов по созданию АСУ И САПР. – М.: Статистика, 1980.

56. Козье Д. Электронная коммерция: Пер. с англ. – М.: Изд-во торговый дом «Русская редакция», 1999.

57. Коуд П. Объектные модели. Стратегии, шаблоны и приложения. – М.: Лори, 1999.

58. Кречмер Р., Иуйс В. Разработка приложений SAP R/3 на языке АВАР/4. – М.: Лори, 1998.

59. Левин В.К. Защита информации в информационновычислительных системах и сетях // Программирование. – 1994. – № 5.

60. Леонг-Хонг Б., Плагман Б. Системы словарей-справочников данных. – М.: Финансы и статистика, 1986.