Информационные технологии в производственно-хозяйственной деятельности предприятия

Большое внимание уделяется методам обеспечения достоверности и надежности информации и т.д.

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

Другим важнейшим показателем качества информационных технологий является функциональная полнота (F) - отношение областей автоматизированной обработки информации (Qa) к области обработки информации (Qи) для функционирования всей системы управления:

F = Qа / Qи

Показатель своевременности переработки информации (Ксв) определяется числом значений показателей, разработанных в рамках информационной технологии в течение определенного времени (t), и значений показателей, полученных за пределами планового срока их представления (t):

Kсв =(t - t)/ t

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

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

Адаптивная - свойство информационной технологии реализовывать свои функции при их изменении в пределах установленных при проектировании границ:

Kад = to / (to+tв),

tо - cреднее время между отказами, обратно пропорционально величине интенсивности потока отказов;

tв - среднее время восстановления, обратно пропорционально интенсивности потока восстановлений.

16. Критерии оптимизации информационных технологий

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

Для экономических задач, реализуемых в диалоговом (интерактивном) режиме характерны следующие факторы:

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

2. Наличие критерия оптимальности.

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

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

Многовариантность и многокритериальность экономических задач предполагает их реализацию как человеко-машинные процедуры.

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

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

17. Средства проектирования технологических процессов

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

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

1. диалог "да - нет" (не нашел широкого распространения из-за пассивной роли пользователя);

программированный вопросник;

3. "свободный диалог" (пользователь формирует запрос в произвольной форме на естественном языке. Система, оперирующая с БД, извлекает из этого запроса понятные ей элементы и строит на их основе новый запрос, который предъявляет пользователю. При утвердительном ответе со стороны пользователя, он получает требуемые данные. В противном случае система организует уточняющий диалог). Этот метод эффективен и позволяет снять психологический барьер.

Недостатки всех трех методов:

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

2. отсутствие гарантии быстрого ответа на вопрос, требующий принятия оперативного решения в критических ситуациях.

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

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

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

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

- сокращение числа массивов на МН, что способствует уменьшению времени счета;

- увеличение кол-ва параллельно обрабатываемых в одном модуле массивов;

- сортировки и эффективные методы поиска в оперативной памяти;

- сокращение времени ответа пользователя на запросы ЭВМ;

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

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

Другим критерием оптимизации технологии ОД является использование различных СУБД (тип и параметры СУБД влияют на эффективность эксплуатации системы). Следующим критерием является выбор необходимого и достаточного количества запросов для реализации задачи и получения необходимой информации.

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

- возможность перебора различных комбинаций поисковых признаков в запросе;

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

- возможность расширения, сужения или изменения направления поиска сразу после получения результатов;

- многоплановость точек доступа;

- быстрый доступ к редко используемой информации;

- оперативный анализ выходной информации;

Для диалогового режима характерны три показателя:

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

2."гибкость"- показатель гибкости определяет диапазон различных процедур при работе пользователя с терминалом;

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

В процессе диалога пользователь реализует следующие основные функции:

- функцию ввода (оперативность исправления текста, визуальный контроль, ...);

- функцию просмотра (редактирование текста с включением, исключением, заменой, сдвигом, перестановкой, разъединением, слиянием данных);

- функцию обработки (смысловая ОД, новое размещение страниц, составление оглавления, организация ввода данных из других программ);

- функцию воспроизведения текста, которая управляет выводом текста и фиксирует параметры печати.

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

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

Можно выделить три обобщенных механизма управления доступа к данным:

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

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

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

Графическое представление диалога

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

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

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

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

При этом необходимо учитывать следующее:

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

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

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

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

1. ввод исходной информации;

2. корректировка информационной базы;

3. корректировка классификаторов-ценников;

4. выдача информации по регламентированным и нерегламентированным запросам;

5. конец работы.

При выходе на режим 1 (п.3) пользователю предлагается выбор форм ввода исходной информации:

Рис. 13 Схема диалоговой системы учета материальных ценностей на складе

1.ввод остатков материалов с карточек складского учета (п.6);

2.ввод информации с "приходных ордеров" (п.7);

3.ввод информации с "материальных требований" (п.8);

4.ввод информации с "лимитно-заборных карт" (п.9);

5.ввод информации с "накладных на внутреннее перемещение" (п.10);

6.конец работы.

При выборе режима 6 диалог возвращается в п.2. Затем (п.19-23) осуществляется ввод показателей по форме соответствующего документа. Если требуется закончить ввод, то диалог переводится в п.2.

При выходе на режим корректировки информации (п.5) ЭВМ запрашивает пользователя, какую информацию необходимо откорректировать и настраивается на корректировку файла остатков материалов (п.13), приходных ордеров (п.14), накладных на внутреннее перемещение (п.15), требований (п.16), лимитно-заборных карт (п.17).

При выходе на режим 3 корректировки классификаторов (п.4) пользователю предоставляются следующие альтернативы:

1.создать новый классификатор (п.11);

2.корректировать классификатор (п.12);

3.печатать классификатор (п.18).

При выборе режима 4 (п.24) пользователю предоставляется возможность выдать информацию по регламентированным запросам (п.25-29), т.е. рассчитать и выдать на экран или печать следующие ведомости:

25 - "опись остатков материалов на складах";

26 - "поступление материалов в разрезе поставщиков";

27 - "расход материалов со складов по потребителям";

28 - "движение материальных ценностей по складу";

29 - "расход материалов на основное производство по направлениям производственных затрат".

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

Недостаток модели - слишком большое количество положений при описании сложного диалога.

18. CASE-технологии проектирования автоматизированных информационных систем

В основе модели лежат понятия SADT (Structured Analysis and Design Technique) - методология структурного анализа и проектирования. Основоположником методологии является Дуглас Росс. Она была создана и опробована на практике с 1969 по 1973 годы. Влияние на формирование SADT оказали общая теория систем, теория описания систем, технология программирования. Наиболее широкое распространение идеи SADT получили под названием IDEF0. Стандарт использовался для проектирования телефонных коммуникаций, автоматизации производства и создания программного обеспечения командных и управляющих систем поддержки боеготовности вооруженных сил США.

Модель процессов предметной области - набор взаимосвязанных описаний, начиная с описания самого верхнего уровня системы и кончая подробным описанием деталей. Каждое из описаний называется диаграммой. Модель процессов предметной области объединяет диаграммы в иерархические структуры, в вершине которых лежит контекстная диаграмма, отражающая связь системы с внешним миром. Она состоит из одного блока и множества дуг. Остальные уровни иерархической структуры получаются путем декомпозиции контекстной диаграммы. Диаграммы нумеруются таким образом, контекстная диаграмма имеет номер А-0, ее декомпозиция - А0, а остальные диаграммы получают номера путем добавления к номеру родительской диаграммы номера декомпозируемого блока. Первый номер 0 опускается. Любая модель процессов предметной области имеет цель, точку зрения и границы. Цель (purpose) - это совокупность вопросов, на которые должна отвечать модель с заданной точностью, т.е. при исследовании предметной области сначала выявляют всю совокупность вопросов моделирования, а потом в одной, двух фразах выражают цель модели. Точка зрения (viewpoint) - это место, позиция или роль человека или объекта, которую надо занять, чтобы увидеть систему в действии. Рассмотрим пример механического цеха, где модно выделить точки зрения рабочего, мастера, контролера, начальника цеха и директора завода. Точки зрения рабочего и мастера не подходят, так как каждый из них акцентирован на своем участке работы и не охватывает другие участки. Точка зрения директора завода не может устраивать проектировщика, т.к. для него механический цех - лишь подсистема. Таким образом, для проектирования наиболее подходит точка зрения начальника цеха. Но при окончательном утверждении модели надо убедиться, что все требования, связанные с каждой из точек зрения, учтены или что ими можно пренебречь, не нарушая выбранной точности. Если что-то не может быть описано с помощью выбранной точки зрения, то целесообразно построить новые модели. Граница модели (scope) - это четкое определение того, что является, а что не является объектом моделирования. Обычно говорят о границе модели в ширину и в глубину. Ширина определяет боковые границы модели, она представляет систему как «черный ящик». Главным при этом является определение взаимодействия системы с внешним миром. Отражением ширины модели является контекстная диаграмма. Глубина модели определяется количеством уровней декомпозиции.

Элементы модели процессов предметной области.

Диаграммы любого уровня декомпозиции состоят из блоков (activity) и дуг (arrow). Блоки изображают процессы, функции или другие активные части системы. Каждый блок имеет название, являющееся глаголом или глагольным оборотом (например, составить отчет). Процесс, изображаемый блоком, должен иметь время действия. Каждый блок должен иметь хоть одну выходную дугу. Функции, не производящие выхода должны быть впоследствии удалены из модели. При построении модели процессов предметной области надо стремиться к тому, чтобы на каждой диаграмме было 3 - 6 блоков. Блоки никогда не располагаются случайным образом. Они должны быть размещены на диаграмме по степени важности. Это расположение называется доминированием. Оно понимается как влияние, которое один блок оказывает на другие. Самым доминирующим может быть блок либо первый из требуемой последовательности функций, либо блок управляющей или контролирующей функции. Наиболее доминирующий блок размещается в левом верхнем углу диаграммы. Доминирование обозначается нумерацией, начиная с 1 для наиболее доминирующего. Дуги связывают блоки и отображают взаимосвязи и взаимодействие между ними. Дуги представляют множество объектов, а, следовательно, их названия должны быть именами существительными. Между объектами и функциями возможны четыре вида отношений: вход, управление, выход и механизм. Каждое из отношений отражается на диаграммах дугой, связанной с определенной стороной блока. Входные дуги (input) изображают объекты, используемые и преобразуемые функцией. Они подходят к блоку слева. Управляющие дуги (control) несут информацию о том, когда и при каких условиях или каким образом выполняется функция, соответствующая блоку. Для этих дуг предназначена верхняя сторона блока. Это могут быть правила, нормативы, стандарты. Выходные дуги (output) изображают объекты, в которые преобразовывается вход. Они касаются блока с правой стороны.

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

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

В методологии SADT выделяется 5 видов взаимодействия между функциями:

1. отношение управления возникает между функциями, если выход одной функции является управлением для другой;

2. отношение входа возникает между функциями, если выход одной функции является входом для другой;

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

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

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

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

Блок, не имеющий детализирующей диаграммы, отмечается косой чертой в левом верхнем углу.

Построение модели сущность-связь является неформальным подходом к построению структуры данных информационной системы. Эта модель должна являться основой для проектирования структуры с использованием формальных методов. Основные элементы модели сущность-связь: сущность - это типы различных объектов; свойство или атрибут (attribute) - это информация, описывающая объект; отношение или связь (relationship) - это объект, который служит для реализации взаимосвязи двух или более объектов; подтип или категория (category). Тип объекта Y является категорией типа X тогда и только тогда, когда каждый объект типа Y обязательно является объектом типа X. При построении модели сущность-связь в предметной области выделяют значимые и семантические конструкции, т.е. звуковые. Их описывают в виде сущностей, а потом определяют свойства выделенных сущностей. Из свойств выделяют ключевые. При необходимости выделяют категории. Затем определяют взаимосвязи между сущностями и описывают их в виде связей. Любой факт предметной области может быть описан проектировщиком как в виде сущности, так и в виде связи. Сущность в стандарте IDEF(X) изображается так:

Студент

Номер зачетки
Фамилия
Имя

Имя сущности должно быть именем существительным в единственном числе. Над чертой расположены ключевые атрибуты, а под ней - не ключевые атрибуты.

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

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



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

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

Если связь не допускает null-значения, то нет сотрудников, не принадлежащих никакому отделу.

Стандарт IDEF(X) включает связи следующих кардинальностей: 1 к нулю или к бесконечности (); 1 к 1 и до бесконечности (не может быть ноль студентов в группе) (_Р); 1 к 0 или 1 (_Z); 1 к N, где N - конкретное число (_N). Иногда для более понятного описания предметной области необходимо введение понятия роли атрибута для внешнего ключа. Роль - значение, которое атрибут несет в сущности. Есть ситуации, когда введение роли внешнего ключа обязательно: когда между двумя сущностями есть две или более связи; в случаях рекурсивной связи, когда родитель и потомок связи совпадают. Это может быть если один из экземпляров сущности ссылается на экземпляр той же сущности.

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

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

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

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

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

Разбиение на категории неполное, если экземпляр сущности может принадлежать одной из категорий, а может не принадлежать ни одной из них.

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

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

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

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

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

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства

19. CASE-средства. Общая характеристика и классификация

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

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

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

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

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

· использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

· средства разработки приложений, включая языки 4GL и генераторы кодов;

· средства конфигурационного управления;

· средства документирования;

· средства тестирования;

· средства управления проектом;

· средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям:

· локальные средства, решающие небольшие автономные задачи (tools),

· набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit)

· полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

применяемым методологиям и моделям систем и БД;

степени интегрированностию с СУБД;

доступным платформам.

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

· средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

· средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

· средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

· средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

· средства конфигурационного управления (PVCS (Intersolv));

· средства тестирования (Quality Works (Segue Software));

· средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

· Vantage Team Builder (Westmount I-CASE);

· Designer/2000;

· Silverrun;

· ERwin+BPwin;

· S-Designor;

· CASE.Аналитик.

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

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

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

Объектно-ориентированный подход в проектировании имеет ряд преимуществ перед структурным:

объектно - ориентированные системы более гибкие и проще эволюционируют во времени.

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

20. Технологии баз данных

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

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

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

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

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

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

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

История создания и развития СУБД насчитывает около сорока лет. За этот период были разработаны многочисленные модели данных, прежде всего это сетевые, иерархические, реляционные и объектные модели данных. Сетевые и иерархические модели в настоящее время считаются устаревшими, но существует множество баз данных созданных на их основе и требующих поддержания их работы.

Одним из крупнейших достижений в этой области является создание реляционной модели данных и базирующейся на ней теории реляционных баз данных, которая позволила получить важные результаты для развития теории баз данных. Как отмечают многие исследователи, своим успехом реляционная модель данных во многом обязана, в первую очередь тому, что опиралась на строгий математический аппарат теории множеств, отношений и логики первого порядка. Разработчики любой конкретной реляционной системы считали своим долгом показать соответствие своей конкретной модели данных общей реляционной модели, которая выступала в качестве меры "реляционности" системы. Существует широкий спектр реляционных СУБД для приложений различного масштаба. Разработан международный стандарт языка запросов SQL, ставший универсальным интерфейсом коммерческих реляционных СУБД. По оценкам специалистов, примерно 99% мирового рынка баз данных занимают в настоящий момент реляционные СУБД. Несмотря на то, что подавляющее большинство приложений базируется на реляционной технологии, их роль начинает ослабевать.

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

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

Преимуществами объектных СУБД модно считать:

· объектные СУБД - открытые системы. Несложно добавить новый тип данных;

· Большинство производителей ООБД предоставляют визуальные средства создания прикладных программ ОСУБД. Если раньше созданием прикладных программ для ОСУБД занимались специалисты в C++, Smaltalk, то теперь использовать ООБД стало намного проще

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

· Традиционные области применения ОСУБД - САПР, моделирование, мультимедиа. ОСУБД широко используются в телекоммуникациях, различных аспектах автоматизации предприятия, издательском деле, геоинформационных проектах.

21. Интеграция неоднородных информационных ресурсов.

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

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

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

Для поддержки принятия решений нужны другие технологии. Необходимо объединять данные из различных источников (как из корпоративной информационной системы, так и из внешней среды), накапливать данные, делая их срезы во времени. Анализ таких данных позволяет оценивать состояние и динамику развития организации, делать обоснованные прогнозы и принимать обоснованные решения. Программные продукты, необходимые для обеспечения управленческих решений, должны обеспечивать хранение больших объемов данных, эффективный доступ к ним, а так же располагать развитыми средствами анализа данных и представления результатов в удобной для специалистов и руководства форме. Информационная технология, которая предоставляет руководителям различного уровня возможность получения необходимой информации для принятия управленческих, финансовых и кадровых решений называется OLAP (On-Line Analytical Processing- оперативной аналитической обработкой) -технологией.

OLAP -технологии базируются на технологиях хранилищ данных (Data warehouses). Хранилище данных обеспечивает накопление с течением времени данные для содействия в принятии решений. Хранилище это данных репозиторий (склад) информации содержащий объединенные, проверенные данные, отражающие работа организации за длительный период. Объемы данных в хранилищах данных в несколько раз превосходят объемы данных в OLTP-системах.

Хранилища данных отличаются от баз данных или систем оперативной обработки транзакций (OLTP-систем) своим назначением и устройством:

· хранилище содержит данные, позволяющие проводить анализ деловых операций;

· хранилища обычно представляют собой системы, доступные только для чтения;

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

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

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

22. CALS-технологии

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

Зародились CALS-технологии в министерстве обороны США в середине 80-х годов. Тогда эта аббревиатура расшифровывалась как (Computer-Aided of Logistics Support) «Компьютерная поддержка логистических систем». Вначале CALS-технологии были связаны только с масштабными проектами американского военно-промышленного комплекса, позднее, в целях повышения производительности труда, принципы CALS-технологий стали применяться и в гражданской промышленности.

В 1988 году в смысловом содержании CALS-технологий были сняты типично военные ограничения, и они стали называться (Computer-Aided Acquisition and Support) «Компьютеризированные поставки и поддержка». В этом варианте была усилена организационная направленность CALS.

В 1993 году сокращением CALS стала называться (Computer-Aided Acquisition and Lifecycle Support) «Поддержка непрерывных поставок и жизненного цикла». В новом названии учитывалась методология параллельного проектирования, интегрированной логистической поддержки, управления конфигурацией и управления документооборотом. Это позволило интегрировать процессы на всем протяжении жизненного цикла изделия, от выражения потребности в нем до его утилизации. В 1995 году CALS стали расшифровывать как (Commerce At Ligth Speed) «Бизнес в высоком темпе», чем подчеркивалась переориентация этих технологий в направлении информационных магистралей и электронной коммерции.

В настоящее время принято название (Computer Acquisition and Life-cycle Support) «Непрерывная информационная поддержка жизненного цикла продукции»

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

...