ответы2

55. Проектирование подсистемы  лингвистического обеспечения

Лингвистическое обеспечение  предусматривает выбор и (или)  создание лингвистических средств, обеспечивающих рациональное представление и поиск данных в АИС. 

Лингвистическое  обеспечение АИС включает в себя  комплекс  информационно-поисковых языков (ИПЯ), а также средств и методов их создания, ведения, использования и контроля. 

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

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

1.  Информационно-поисковые языки:

1.1.  Классификационные ИПЯ

1.2.  Дескрипторные ИПЯ

1.3.  Объектно-признаковый язык (в т. ч. язык библиографического описания)

2. Элементы информационно-поисковых языков:

2.1. Международные стандартные номера (ISBN, ISSN)

2.2. Коды названий (языков, стран, физических единиц и т. п.)

3. Языки взаимодействия с системой:

3.1. Семантические языки разметки текста ((HTML и т. п.)

3.2. Языки диалога (элементы интерфейса и т. п.)

4. Форматы представления данных в машиночитаемой форме (коммуникативные форматы RUSMARC, UNIMARC и т. п.)

5. Нормативно-справочная база:

5.1.  Нормативные документы

5.2.  Инструктивно-методические документы

5.3.  Справочники

5.4. Файлы авторитетных записей (предметных рубрик, авторов и т. п.).

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

Процесс проектирования лингвистического обеспечения АИС включает следующие этапы:

1.          Выявление лингвистических средств на основе анализа задач, решаемых в конкретной АИС.

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

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

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

5. Разработка логических структур проектируемых справочников.

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

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

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

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

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

56. Проектирование подсистемы математического обеспечения

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

В со­став МО входят:

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

2.   техническая документация (описание задач, алгоритмы ре­шения задач, экономико-математические модели);

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

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

Назначение, состав и структура математического обеспечения (МО)

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

Состав МО:

1.   Математическое описание (формализация) задач.

2.   Математические модели и их оптимизация.

3.   Данные, подготовленные для описания исследуемых про­цессов.

4.   Алгоритмы решения задач.

5. Анализ моделей и алгоритмов по результатам выполнен­ных работ на ЭВМ.

Система математического обеспечения АС должна выпол­нять следующие функции:

•    реализацию любых процедур обработки данных;

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

•    организацию управления процессом решения задач и их комплексов;

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

В МО по последовательности проектирования АСУ рассмат­ривают три уровня:

1)   математическое обеспечение конкретной АС, которой оп­ределяется мощность АС;

2)   автоматизацию проектирования АС;

3)   автоматизацию программирования и организацию работ на ЭВМ.

Разработка МО предполагает выполнение следующих этапов:

•    создание модели системы;

•    разработку укрупненного алгоритма;

•    разработку алгоритмов отдельных элементов МО;

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

Прежде всего выполняют постановку задачи моделирования:

•    определение требований к исходной информации, ее сбор;

•    выдвижение гипотез и предположений;

•    определение параметров и переменных модели;

•    обоснование выбора показателей и критериев эффективно­сти системы;

•    определение содержания и описание модели (основной документ).

Модели и алгоритмы обработки информации

Существующие математические модели экономических систем можно предста­вить тремя группами:

1.   Алгебраические уравнения 2-й или 3-й степени (алгебраи­ческие).

2.   Модели систем массового обслуживания (статистические).

3.   Модели больших и очень больших систем.

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

Статистические модели строятся методом статистических испытаний случайных чисел.

Документ "Описание алгоритма (проектной процедуры)" в зависимости от специфики АС допускается разрабатывать как документ "Описание алгоритма" или как документ "Описание проектной процедуры (операции)".

Документ "Описание алгоритма" содержит разделы:

1) назначение и характеристика;

2) используемая информация;

3) результаты решения;

4) математическое описание;

5) алгоритм решения.

В разделе "Алгоритм решения" следует приводить:

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

2) указания о точности вычисления (при необходимости);

3) соотношения, необходимые для контроля достоверности вычислений;

4) описание связей между частями и операциями алгоритма;

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

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

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

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

Алгоритм представляют одним из следующих способов:

1) графический (в виде схемы); 2) табличный; 3) текстовой; 4) смешанный

Алгоритм в виде схемы выполняют по правилам, установленным ГОСТ 19.002 или ГОСТ 19.005.

Алгоритм в виде таблиц выполняют по правилам, установленным ГОСТ 2.105.

Алгоритм в виде текстового описания выполняют по правилам, установленным ГОСТ 24.301.

57. Проектирование подсистемы программного обеспечения

Подсистема «Программное обеспечение» {ПО) включает сово­купность компьютерных программ, описаний и инструкций по их применению на ЭВМ.

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

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

1) к независимости программных средств от используемых СВТ и операционной среды;

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

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

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

Среди факторов, влияющих на выбор программного обеспечения, определяющее значение имеют:

  -  достигнутый к моменту проектирования уровень автоматизации предприятия (организации и т.п.) и учет принятых при этом проектных решений;

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

  -   состав задач, решаемых проектируемой АИС  или ее подсистемой.

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

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

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

Особое место при описании проектных решений по программному обеспечению занимает характеристика интерфейса прикладного программного обеспечения системы (подсистемы).

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

Текстовый способ  описания алгоритма входит в состав параграфа, описывающего решения по программному обеспечению. Графический  способ  описания алгоритма, представленный в виде блок-схем алгоритмов решения трех наиболее важных задач, решаемых проектируемой АИС, должен быть приведен в приложении к дипломному проекту. Требования к представлению схем алгоритмов регламентируются ГОСТ 19.701-90 «ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения». 

При проектировании программного обеспечения также должно быть разработано и приведено в составе приложений к дипломному проекту   руководство пользователя. При создании данного документа следует ориентироваться на такие нормативные документы, как  ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов» и РД 50-34.698-90 «Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Требования к содержанию документов». В соответствии с данными документами структура руководства пользователя должна включать следующие разделы: введение; назначение и условия применения; подготовка   к работе; описание операций; аварийные ситуации; рекомендации по освоению.

58. Проектирование  подсистемы технического обеспечения

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

Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.

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

Комплекс технических средств составляют:

 -    персональные компьютеры;

 -    периферийные устройства: устройства ввода-вывода,  накопления и хранения информации;

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

 -    оргтехника;

 -    эксплуатационные материалы.

Среди факторов, влияющих на выбор технического  обеспечения, определяющее значение имеют:

 - мировой и отечественный уровень достижений  в сфере разработки технических средств;

 -  состав технических средств, имеющихся на предприятии (в организации и т.п.) к моменту проектирования АИС; 

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

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

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

Ведомость оборудования и материалов

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

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

 - фирма-производитель микропроцессора; - тип микропроцессора; - тактовая частота микропроцессора; - емкость оперативной памяти - тип и емкость накопителей на машинных носителях; - виды и емкость КЭШ-памяти.

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

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

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

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

При описании манипулятора «мышь» приводятся данные о фирме-производителе,  типе.

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

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

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

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

Кроме обоснования состава необходимого  оборудования, должна быть определена и потребность в приобретении расходных материалов (бумаги, картриджей, тонеров, дискет, CD и т. п.).

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

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

59. Индустриальное типовое проектирование информационных систем

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

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

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

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

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

Сущность применения ТПР при элементном методе заключа­ется в комплектации ИС из множества ТПР по отдельным раз­розненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули до­рабатываются вручную. Достоинство элементного метода типо­вого проектирования ИС связано с применением модульного подхода к проектированию и документированию ИС.

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

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

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

Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), кото­рые позволяют осуществлять:

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

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

·            сокращение затрат на проектирование и программирование взаимосвязанных компонентов;

·            хорошее документирование отображаемых процессов обра­ботки информации.

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

В качестве примеров широкораспространенных функцио­нальных ППП можно назвать; 1С «Предприятие» (автоматиза­ция бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый ана­лиз) и др.

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

·            открытостью архитектуры, позволяющей устанавливать про­екты на разных программно-технических платформах;

·            масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест;

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

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

Адаптивность объектного метода проектирования зависит от используемого подхода. При параметрической настройке типо­вых информационных систем, таких, например, как ППП «Га­лактика», «Парус», «БОСС» и другие, возникают проблемы при­вязки типового проекта к конкретному объекту управления так же, как и при подсистемном подходе. Обычным способом реше­ния проблемы адаптации является изменение структуры органи­зационно-экономической системы объекта внедрения в соответ­ствии с требованиями типового проекта либо существенная доработка типового проекта с помощью специальных инструмен­тальных средств типовой системы.

Параметрически-ориентированное проектирование ИС

При проектировании ИС на основе параметрической на­стройки пакета прикладных программ (ППП) последний рассмат­ривается как «черный ящик».

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

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

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

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

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

Параметрическая информация предоставляется:

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

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

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

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

В качестве таких инструментов, доступных квалифицирован­ному пользователю (непрограммисту), используются:

·            генераторы программ ЭИС на основе языковых средств RAD-технологии (4GL);

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

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

Параметрически-ориентированное проекти­рование ИС на основе использования ППП по сравнению с ори­гинальным проектированием дает возможность более быстрого и гибкого внедрения информационной системы.

Однако существует ряд проблем, сдерживающих распростра­нение данной технологии. К ним можно отнести следующее:

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

·            достаточно высокую стоимость приобретения ППП и обуче­ния персонала;

·            отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках корпоратив­ной ЭИС.

Модельно-ориентированное проектирование ЭИС

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

Ядром типовой ИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специаль­ной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ИС сводятся прежде все­го к построению модели проблемной области и ее периодичес­кой корректировке.

60. Индустриальное автоматизированное проектирование информационных систем

Основные понятия и классификация CASE-технологий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) по поддерживаемым методологиям проектирования: функ­ционально

2)   по поддерживаемым графическим нотациям построения ди­аграмм

3)   по степени интегрированности: 

4)   по типу и архитектуре вычислительной техники: 

5)   по режиму коллективной разработки проекта: ;

6)   по типу операционной системы (ОС): 

Функционально-ориентированное проектирование ЭИС

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированное проектирование ЭИС

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

В настоящее время для объектно-ориентированного модели­рования проблемной области широко используется унифициро­ванный язык моделирования UML (Unified Modeling Language), Система объектно-ориентированных моделей в соответствии с нотациями 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), которая ото­бражает распределение объектов по узлам вычислительной сети.

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

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

61. Информационное обеспечение автоматизированных информационных систем

Основной принцип создания информационного обеспечения (ИО) — решение задачи удовлетворения информационных по­требностей пользователя и (или) системы управления объектом (производством.)

При решении этих задач осуществляется:

•    накопление информации;

•    обмен информацией;

•    обработка информации;

•    управление данными;

•    формализация данных и знаний. Создание ИО проходит следующие этапы:

•    исследование информационных потоков;

•    разработка системы классификации и кодирования;

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

•    накопление массивов данных и работа с ними.

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

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

ИО реализуется как:

I.        Внешнее (немашинное) ИО, которое, однако, должно учитывать принципы автоматизации информационных процессов. Его состав:

•    система классификации и кодирования;

•    нормативно-справочные документы;

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

•    методические и инструктивные материалы. Движение этих документов реализуется в соответствии с ор­ганизационной структурой управления.

II.       Внутримашинное ИО включает:

•    информационные массивы, составляющие информа­ционную базу системы;

•    пакеты программ.

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

Традиционно, в соответствии с ГОСТ 34.03-90, информа­ционное обеспечение рассматривалось как «совокупность форм документов, классификаторов, нормативной базы и реа­лизованных решений по объемам, размещению и формам су­ществования информации, применяемой в АС при ее функционировании».

Таким образом, информационное обеспечение АИС включа­ло три составляющих: единую систему классификации и кодиро­вания информации, унифицированные системы документации и массивы информации.

Лингвистическое обеспечение рассматривалось как «совокуп­ность средств и правил для формализации естественного языка, ис­пользуемых при общении пользователей и эксплуатационного пер­сонала АС с комплексом средств автоматизации при функциониро­вании АС». Лингвистическое обеспечение АИС включало две составляющих: лексическую (словарную) базу и языковые средства.

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

Поэтому можно сформулировать:

Информационное обеспечение АИС — это совокупность баз данных и файлов операционной системы, форматной и лекси­ческой баз, а также языковых средств, предназначенных для вво­да, обработки, поиска и представления информации в форме, не­обходимой потребителю.

Информационное обеспечение делят на немашинное и ма­шинное. К первому относят классификаторы технико-экономи­ческой информации, нормативно-справочную информацию. Ко второму относят БД, СУБД. Это деление довольно условное, так как первый вид обеспечения можно вести и на ЭВМ.