авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 3 | 4 ||

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования «ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» ЮРГИНСКИЙ ...»

-- [ Страница 5 ] --

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.16. Пример диаграммы пакетов Компонент в своем составе имеет интерфейсный класс объектов, через который осуществляется доступ к остальным классам объектов компонента. На рис. 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 Ap plication 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.

61. Липаев В.В. Системное проектирование сложных программ ных средств для информационных систем. – М.: Синтег, 1999.

62. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. – М.: Научная книга, 1997.

63. Львов В. Создание систем поддержки принятия решений на основе хранилищ данных // Системы управления базами данных. – 1997.

– №3.

64. Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2000.

65. Многопользовательский сетевой комплекс полной автоматиза ции фирмы (корпорации) Галактика. – М.: АО «Новый атлант»;

НТО «ТОП СОФТ», 1998.

66. Мартин Дж. Планирование развития автоматизированных сис тем. – М.: Финансы и статистика, 1984.

67. Марка Д.А., МакГоун К. Методология структурного системно го анализа и проектирования SADT: Пер. с англ. – М.: Метатехнология, 1993.

68. Мельников В.В. Защита информации в компьютерных систе мах. – М.: Финансы и статистика;

Электроинформ, 1997.

69. Новая технология и организационные структуры / Под ред. Й.

Пиннингса, А. Бьютандама (Сокр. пер. с англ.). – М.: Экономика, 1990.

70. Одинцов А.В., Норенков Ю.И., Горин А.Д. Динамическое мо делирование предприятия // Информационные технологии. – 1997. – № 2.

71. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжини ринг организаций и информационные технологии. – М.: Финансы и ста тистика, 1997.

72. Орфали Р., Харки Д., Эдвардс Д. Основы CORBA: Пер. с англ.

– М.: МАЛИП, Горячая Линия-Телеком, 1999.

73. Першиков В.И., Савинков В.М. Толковый словарь по инфор матике. – М.: Финансы и статистика, 1996.

74. Позин Б.А. CASE: автоматизация проектирования программ ных средств // Человек и компьютер. – 1993. – № 5(43).

75. Полковников А.В. Корпоративная система управления проек тами // Электронный офис. – 1997. – Октябрь.

76. Полковников А.В. Управление проектами – выбор, внедрение и использование ПО в России // PC WEEK/RU. – 1996. – № 34–35.

77. Росс Д.Т. Структурный анализ (SA): язык для передачи пони мания: Требования и спецификации в разработке программ. – М.: Мир, 1984.

78. Спесивцев А.В. и др. Защита информации в персональных ЭВМ – М.: Радио и связь, 1992.

79. Системная интеграция: взгляд изнутри // Компьютер Пресс. – 1997. –№4.

80. Сорокин А.А., Романова Е.В. Вопросы применения CASE технологии проектирования информационных систем в среде Natural LightStorm // Реинжиниринг бизнес-процессов предприятий на основе современных информационных технологий: Сб. научных трудов 3-й Российской научно-практической конференции. – М.: МЭСИ, 1999.

81. Тельнов Ю.Ф. Интеллектуальные информационные системы в экономике: Учеб. пособие. – М.: СИНТЕГ, 1999. (Серия «Информатиза ция России на пороге XXI века»).

82. Тельнов Ю.Ф. Влияние реинжиниринга бизнес-процессов на архитектуру корпоративной экономической информационной системы // Экономические информационные системы на пороге XXI века. – М.:

МЭСИ, 1999.

83. Тельнов Ю.Ф. Компонентная технология реинжиниринга биз нес-процессов // Реинжиниринг бизнес-процессов предприятий на осно ве современных информационных технологий: Сб. научных трудов 4-й Российской научно-практической конференции. – М.: МЭСИ, 2000.

84. Тельнов Ю.Ф. Реинжиниринг бизнес-процессов и проектиро вание информационных систем // Реинжиниринг бизнес-процессов предприятий на основе современных информационных технологий: Сб.

научных трудов 2-й Российской научно-практической конференции. – М.: МЭСИ, 1998.

85. Тиори Т., Фрай Д. Проектирование структур баз данных. – М.:

Мир, 1984.

86. Ускова О. Проектная интеграция // Компьютер Пресс. – 1997. – № 4.

87. Федеральный закон «Об информации, информатизации и за щите информации» // Российская газета. – 1995. – 22 февр.

88. Фокс Дж. Программное обеспечение и его разработка. – М.:

Мир, 1985.

89. Фаулер М., Скотт К. UML в кратком изложении: Применение стандартного языка объектного моделирования: Пер. с англ. – М.: Мир, 1999.

90. Хаббард Дж. Автоматизированное проектирование структур баз данных. – М.: Мир, 1984.

91. Хаммер М., Чампи Дж. Реинжиниринг корпорации: Манифест революции в бизнесе: Пер. с англ. – СПб.: Изд-во С.-Петербургского университета, 1997.

92. Хан Д. Планирование и контроль: концепция контроллинга:

Пер. с нем. – М.: Финансы и статистика, 1997.

93. Хотяшов Э.Н. Основы проектирования систем машинной об работки данных. – М.: Финансы и статистика, 1981.

94. Шлеер С, Меллор С. Объектно-ориентированный анализ: Мо делирование мира в состояниях: Пер. с англ. – Киев: Диалектика, 1993.

95. Юдицкий С.А., Кутанов А.Т. Технология проектирования ар хитектуры информационно-управляющих систем. – М.: Институт про блем управления, 1993. (Препринт).

96. CASE. Аналитик. Версия 1.1. Руководство аналитика. – М.:

НТП ЭЙТЭКС, 1995.

97. CASE-технология. Материалы семинара. – М.: ЦРДЗ, 1992.

98. CASE-технология. Материалы семинара. – М.: ЦРДЗ, 1993.

99. Informix – magazine, русское издание, осень 1998.

100. Andersen E.S., Gruide К. V., Houg T. Goal Directed Project Man agement. – Coopers & Lybrand, 1995.

101. Brassard J. Modern Criptology, 1988.

102. CASE: The Potentials and the Pitfalls. QED Information Science.

– Inc., 1989.

103. Coad P., Yordon E. Object Oriented Analysis. – Prentice-Hall, 1990.

104. Codd E.F., Codd S.B., Salley C.T. Providing OLAP to User Analysts // An IT Mandate, Arbore Software Corp. Papers, 1996.

105. Design/IDEF User's Manual for Microsoft Windows. Version 3.5.

Meta Software Corporation. 1996.

106. Decision support systems. Putting theory into practice / Edited by R.H. Sprague, H. Watson. – Prentice-Hall, 1993.

107. Jacobson L, Ericsson M., Jacobson A. The Object Advantage:

Business Process Reengineering with Object Technology //ACM Press. – Addison-Wesley Publishing, 1995.

108. Lucas H.C. Information Technology for Management. Sixth edi tion. International Editions, 1997.

109. McLeod R. Systems Analysis and Design / An Organizational Approach / The Driden Press, 1994.

110. Natural LightStorm. Concepts and Facilities. – Software AG, 1998.

111. ReThink User's Guide. Version 3.1 Gensym, 1999.

112. Fisher A.S. CASE: Using Software Development Tools. – John Wiley & Sons, Inc., 1988.

113. McClure C. CASE in Software Automation. – Prentice-Hall, 1989.

114. Gone С., Sarson Т. Structured System Analysis. – Prentice-Hall, 1979.

115. Computer-Aided Software Engineering / Elliot J. Chikofsky (ed) // IEEE Computer Society Press, 1989.

116. Designer/2000 Tutorial. – ORACLE Corporation, 1995.

117. Information Technology Security Evaluation Criteria (ITSEC).

Harmonised Criteria of France – Germany – the Netherlands – the United Kingdom. – Department of Trade and Industry, London, 1991.

118. ProKit*WORKBENCH (2.0). Product Description. McDonnel Douglas Corporation, 1990.

119. PRO-IV. Product Description // McDonnel Douglas Information Systems Ltd., 1990.

120. Ross R.G. The Business Rule Book: Classifying, Defining and Modelling Rules. Data Base Research Group, Inc. – 1997.

121. Scheer A-W. Business Process Engineering: Reference Models for Industrial Enterprises, 1995.

122. Security Architecture for Open Systems Interconnection for CCITT Applications. Recommendation X.800 – CCITT. – Geneva, 1991.

123. Towner L. CASE Concepts and Implementation. – McGraw Hill, 1989.

124. Yordon E. Modern Structured Analysis. – Prentice-Hall, 1989.

ОГЛАВЛЕНИЕ Введение ….………………………………………………………….. Часть 1. Теоретические основы проектирования экономических информационных систем (ЭИС) Тема 1. Архитектура экономических информационных систем..... 1.1. Понятие и классификация ЭИС …………………………. 1.2. Функциональные подсистемы ЭИС …..………………… 1.3. Обеспечивающие подсистемы ЭИС ….…..……………... Тема 2. Методологические основы проектирования ЭИС …..….... 2.1. Технология проектирования ЭИС …………………….... 2.2. Жизненный цикл ЭИС …………...…………………….... 2.3. Формализация технологии проектирования ЭИС ……... Часть 2. Каноническое проектирование ЭИС Тема 3. Содержание и методы канонического проектирования ЭИС …………………………………………………………………… 3.1. Состав стадий и этапов канонического проектирования ЭИС …..……………………………………………………………….. 3.2. Состав и содержание работ на предпроектной стадии создания ЭИС ……..……..….…………...…………………………... 3.3. Состав и содержание работ на стадии техно-рабочего проектирования..………..….…………...…….……………………... 3.4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта …..………..……...…........ Тема 4. Проектирование системы экономической документации.. 4.1. Понятие унифицированной системы документации....... 4.2. Проектирование унифицированной системы документации ЭИС …..……………………………………………… 4.2.1. Особенности проектирования форм первичных документов …………………….……………………..………………. 4.2.2. Особенности проектирования форм документов результатной информации …...………………………......…………. Часть 3. Индустриальное проектирование корпоративных экономических информационных систем Тема 5. Реинжиниринг бизнес-процессов и проектирование корпоративной ЭИС ………...……………………………………….. 5.1. Реинжиниринг бизнес-процессов на основе корпоративной ЭИС.………..………………………………………. 5.2. Этапы реинжиниринга бизнес-процессов ………….…... 5.3. Методология моделирования предметной области ….... Тема 6. Проектирование клиент-серверных корпоративных ЭИС. 6.1. Основные понятия и особенности проектирования клиент-серверных экономических информационных систем (КЭИС) ……………………………………………………………….. 6.2. Проектирование систем оперативной обработки транзакций ………………..…………………….……………………. 6.3. Проектирование систем оперативного анализа данных.. Тема 7. Автоматизированное проектирование ЭИС (CASE-технология) ………………………………………………..… 7.1. Основные понятия и классификация CASE-технологий 7.2. Функционально-ориентированное проектирование ЭИС 7.3. Объектно-ориентированное проектирование ЭИС …….. 7.4. Прототипное проектирование ЭИС (RAD-технология).. Список литературы ….……………..…..…………..………………... Маслов Анатолий Викторович ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ В ЭКОНОМИКЕ Учебное пособие Научный редактор кандидат технических наук А.А. Захарова Редактор Т.В. Казанцева Верстка и дизайн обложки А.В. Маслов Подписано к печати 26.06.2008. Формат 60х84/16. Бумага «Классика».

Печать RISO. Усл.печ.л. 12,55. Уч.-изд.л. 11,37.

Заказ. Тираж 100 экз.

Томский политехнический университет Система менеджмента качества Томского политехнического университета сертифицирована NATIONAL QUALITY ASSURANCE по стандарту ISO 9001:. 634050, г. Томск, пр. Ленина, 30.



Pages:     | 1 |   ...   | 3 | 4 ||
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.