<< Пред. стр. 4 (из 6) След. >>
Список литературы по разделу
Структура основных БП и их взаимодействий описывается в соответствии с требованиями модели классов объектов.
Анализ системных требований начинается с идентификации основных прецедентов использования и объектов-сущностей, которые будут применяться в ИС. Работы по идентификации прецедентов использования классов объектов-сущностей, как правило, выполняются параллельно. В случае ОО оформления результатов предпроектного обследования данная работа упрощается в силу однозначности соответствия БП и прецедентов использования ЭИС, бизнес-объектов и объектов сущностей.
Разработка диаграммы прецедентов использования ЭИС предполагает выделение тех последовательностей транзакций, которые будут автоматизировать БП. При этом определяются основные пользователи-актеры, взаимодействующие с прецедентами использования.
Разработка диаграммы классов объектов предполагает задание состава атрибутов и определение характера взаимосвязей классов объектов.
Разработка диаграммы состояний объектов осуществляется только для классов объектов со сложным поведением. При этом рассматриваются все прецеденты использования, в которых объекты данного класса используются и меняют свои состояния.
Разработка диаграммы пакетов осуществляется путем группировки классов объектов по подсистемам. На этапе анализа системных требований определяется состав пакетов, относящихся к пакету "Проблемная область". При этом выделяются функциональные пакеты, которые объединяют классы объектов, реализующие функции управления, и базовые пакеты с нормативно-справочной информацией, общие для функциональных пакетов.
Логическое проектирование ЭИС
На этапе логического проектирования ЭИС осуществляются детализация моделей прецедентов использования, классов объектов, состояний пакетов и разработка моделей взаимодействия объектов и деятельностей, которые определяют характер методов (процедур) обработки пакетов.
Детализация диаграммы прецедентов использования предполагает разработку основных и альтернативных потоков событий, которые могут быть представлены самостоятельными диаграммами прецедентов использования. Кроме того, могут быть выделены прецеденты использования, расширяющие набор функций основных прецедентов, или из нескольких прецедентов использования могут быть выделены общие функции в самостоятельные прецеденты. При этом соответственно задаются отношения расширения и использования.
Рис 7. Технологическая схема логического проектирования
Детализация диаграммы классов объектов выполняется путем уточнения классов-объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов - координирующим функциям обработки объектов-сущностей. Уточнение диаграммы состояний объектов выполняется в связи с детализацией диаграммы прецедентов использования и диаграммы классов объектов.
Разработка диаграммы взаимодействия выполняется для каждого прецедента использования с учетом построенных диаграмм классов объектов и состояний. В частности, сообщение от одного объекта к другому в диаграмме взаимодействия должно соответствовать событию, вызывающему переход состояния объекта получателя сообщения в диаграмме состояний. Аналогично внешнее событие в диаграмме взаимодействий, вызываемое актером, соответствует событию, осуществляющему переход состояния объекта в диаграмме состояний.
Разработка диаграммы деятельностей уточняет характер взаимодействия объектов не в одном, а в нескольких прецедентах использования. Если диаграммы взаимодействий объектов формируют набор методов обработки объектов, то диаграммы деятельностей дают спецификацию алгоритмов для последующего программирования этих методов.
Детализация диаграммы пакетов связана с уточнением состава классов объектов-сущностей и появлением интерфейсных и управляющих классов объектов. Например, интерфейсные и управляющие классы объектов могут быть выделены в самостоятельные обеспечивающие пакеты.
Физическое проектирование
На этапе физического проектирования происходит детализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде.
Рис. 9. Технологическая схема физического проектирования
Спецификация физической реализации диаграммы классов объектов предусматривает определение форматов данных для атрибутов и методов реализации отношений (ключей, указателей, процедур) классов объектов.
Детализация диаграммы пактов предполагает разработку обеспечивающих компонентов: базы данных, управления задачами, вспомогательных функций.
Разработка диаграммы компонентов и диаграммы размещения компонентов реализует клиент-серверную технологию и определяет схему размещения компонентов по узлам ВС.
Реализация ЭИС
На этапе реализации ЭИС осуществляются кодогенерация классов объектов, программирование процедур методов классов объектов, наполнение БД и размещение компонентов по узлам ВС.
Рис. 10. Технологическая схема реализации ЭИС
Генерация классов объектов в конкретной ОО программной среде (С++, VB), выбираемой из универсума ОО ЯП, осуществляется на основе диаграммы классов объектов.
Генерация шаблонов процедур методов класса объектов в конкретной ОО программной среде, выбираемой из универсума ОО ЯП производится на основе диаграммы взаимодействий объектов.
Программирование процедур методов класса объектов с помощью ОО ЯП выполняется на основе шаблонов процедур методов классов объектов по спецификациям диаграмм деятельностей и состояний объектов.
ПРОТОТИПНОЕ ПРОЕКТИРОВАНИЕ ЭИС
(RAD - ТЕХНОЛОГИИ)
С появлением КЭИС, базирующихся на архитектуре "клиент-сервер", появляется возможность ускорения разработки приложений за счет параллельного создания клиентской и серверной частей. Однако реально использовать преимущества такой архитектуры оказалось очень непросто из-за резко возросшей сложности создания приложений в гетерогенной среде. Кроме естественной сложности создания приложений в неоднородной среде существует тенденция к усложнению приложений с течением времени. В этих условиях процесс разработки ИС традиционным каскадным методом может затянуться на длительное время, а соответствие результата потребностям заказчика не гарантируется.
Основное желание заказчика ЭИС - получить готовое приложение высокого качества быстро и при минимальных затратах на его разработку. Кроме того, вкладывая значительные средства на создание системы, заказчики желают контролировать процесс разработки. Критерием качества должно быть наиболее полное удовлетворение требований заказчиков на момент введения системы в эксплуатацию.
Одним из условий обеспечения высокого качества создаваемых ИС является активное вовлечение конечных пользователей в процесс разработки предназначенных для них интерактивных систем, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD.
При создании сложных ЭИС пользователям необходимо работать совместно с проектировщиками на всем протяжении периода разработки, что достигается использованием технологии прототипного проектирования. Данная технология обеспечивает на ранней стадии реализацию действующей интерактивной модели системы (системы-прототипа), позволяющей наглядно продемонстрировать пользователю будущую систему, уточнит его интерфейсные элементы: формы ввода сообщений, меню, выходные документы, структуру диалога, состав реализуемых функций.
В процессе работы с системой-прототипом пользователь реально осознает возможности будущей системы и определяет наиболее удобный для него режим обработки данных. Осуществляются проверка принципиальных проектных решений по составу и структуре ЭИС и оценка основных ее эксплуатационных характеристик (замечания, дополнения).
Согласованная система-прототип служит спецификацией для дальнейшей разработки ЭИС, что позволяет на ранних этапах проектирования выявить возможные ошибки проектирования и определить параметры будущей системы.
Все приемы для быстрой разработки приложений служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:
1) разработка приложения итерациями;
2) необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем;
3) обязательное вовлечение пользователей в процесс проектирования и построения системы;
4) высокая параллельность работ;
5) повторное использование частей проекта;
6) необходимое применение CASE-средств, обеспечивающих техническую целостность на этапах анализа и проектирования;
7) применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы;
8) использование автоматических генераторов (мастеров);
9) использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;
10) тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.
Каждое из перечисленных положений в отдельности способствует повышению скорости, улучшению качества, но только их совместное использование вызывает качественные изменения в процессе разработки. Главная задача - как можно скорее показать пользователям готовый продукт.
Для определения состава, объема работ, необходимого числа разработчиков, распределения работ между участниками используется автоматизация планирования. Основная проблема - определение момента перехода на следующий этап. Для ее решения вводят временные ограничения на каждый этап жизненного цикла. Переход на следующий этап выполняется даже в том случае, если предыдущий не закончен, а отведенное время истекло.
Для реализации технологии типового проектирования необходимо применять высокоуровневые инструментальные средства, которые позволяют быстро преобразовывать прототип системы в функционирующую версию и внести в нее в дальнейшем необходимые изменения. Такие инструментальные средства можно условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД (класс DEVELOPER) и интегрированные инструменты быстрой разработки приложений (класс BUILDER).
К инструментам этих классов можно отнести генераторы компонентов приложений:
* генераторы таблиц БД;
* генераторы форм ввода-вывода;
* генераторы запросов;
* генераторы отчетов;
* генераторы меню.
Такие генераторы существуют почти во всех СУБД, как в персональных Access, FoxPro, так и в окружении промышленных серверов БД (Oracle, Informix).
Отличительной чертой класса BUILDER является то, что инструменты данного класса легко интегрируются с CASE-средствами и представляют собой единую среду быстрой разработки приложения. К интегрированным инструментам этого класса можно отнести Delphi, Builder C++.
Жизненный цикл создания ЭИС на основе RAD-технологии предполагает после формирования ТЗ и декомпозиции системы независимую разработку подсистем с последующей сборкой, тестированием и внедрением комплексной ЭИС.
Существует два базовых варианта использования организационно-технологического процесса проектирования с использованием систем прототипов.
В первом варианте создание системы-прототипа используется для лучшей спецификации требований к разработке ЭИС, после разработки которых сам прототип оказывается ненужным. В этом случае традиционно разрабатывается Постановка задачи, документация которой является спецификацией системы-прототипа. После демонстрации пользователю и доработки прототипа разрабатывается новая Постановка задачи, которая служит основой создания действующей ЭИС.
В соответствии с технологической сетью проектирования на основе ТЗ и описания предметной области выполняется разработка постановки задачи. Вторая технологическая операция с преобразователем служит для разработки системы-прототипа на основе спецификаций постановки задачи и выбранного средства из универсума средств быстрой разработки приложений. Выходом из операции является готовое приложение-прототип. Результаты работы приложения-прототипа демонстрируют заказчику, после чего формируются замечания и уточненные требования к ЭИС и происходит доработка прототипа. На основании результатов доработки прототипа формируется новая постановка задачи. Технологическая операция с преобразователем предназначена для разработки действующего программного приложения.
Основной недостаток этого варианта - неэффективное использование системы-прототипа (не используются в дальнейшем).
Второй вариант предполагает итерационное развитие системы-прототипа в готовый для эксплуатации программный продукт. Итерации разработки системы-прототипа включают создание/модификацию системы-прототипа, ее демонстрацию пользователю и согласование, разработку новых спецификаций-требований к системе, новую модификацию, пока не будет создано новое приложение. Документацию компонентов системы-прототипа непосредственно составляют спецификации, которые являются требованиями к программной реализации системы и определяют характер взаимоотношений с заказчиком на этапе сдачи готовой системы.
На основе ТЗ, описания предметной области, выбранного средства быстрой разработки выполняется разработка системы-прототипа. Выходом операции является готовое приложение-прототип. Результаты работы приложения-прототипа демонстрируются заказчику, после чего либо формируются замечания и уточненные требования к ЭИС и происходят доработка прототипа и разработка новых спецификаций-требований, либо система-прототип полностью удовлетворяет требованиям, и она документируется и сдается в виде готового программного приложения с соответствующей документацией.
Технологическая сеть проектирования на стадии техно-рабочего проектирования имеет вид.
Рис. 11 ТСП на стадии техно-рабочего проектирования имеет вид.
Вопросы для самоконторля
1. Дайте определениеCASE-технологии проектирования ЭИС.
2. Какова структура CASE-средств?
3. Какие классы CASE-средств существуют?
4. Какие диаграммы выступают в качестве инструментальных средств функционально-ориентированного анализа проектирования?
5. Определите основные понятия и элементы диаграммы потоков данных?
6. Определите основные понятия и элементы диаграммы функциональных спецификаций.
7. Определите основные понятия и элементы системной структурной диаграммы.
8. Какие диаграммы выступают в качестве инструментальных средств объектно-ориентированного анализа проектирования?
9. Определите основные понятия и элементы диаграммы прецедентов использования.
10. Определите основные понятия и элементы диаграммы классов.
11. Определите основные понятия и элементы диаграммы состояний.
12. Определите основные понятия и элементы диаграммы взаимодействия объектов.
13. Определите основные понятия и элементы диаграммы деятельностей.
14. Определите основные понятия и элементы диаграммы пакетов.
15. Определите основные понятия и элементы диаграммы компонентов и размещения.
16. В чем заключается сущность прототипной (RAD) технологии.
17. Дайте классификацию инструментальных средств быстрого прототипирования ЭИС?
ЛЕКЦИЯ 9
ТИПОВОЕ ПРОЕКТИРОВАНИЕ ЭИС
ОСНОВНЫЕ ПОНЯТИЯ И КЛАССИФИКАЦИЯ
МЕТОДОВ ТИПОВОГО ПРОЕКТИРОВАНИЕ
Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области.
Под типовым проектным решением (ТПР) понимают представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может выступать реализация как отдельных компонентов ЭИС (программных модулей, функциональных задач, АРМ, локальных БД), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами.
В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования.
При элементом методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному).
Задача
Информационное обеспечение
Программное обеспечение
Техническое обеспечение
Математическое обеспечение
Организационное обеспечение
БД, файлы
ОС, СУБД, ЯП
На какой технике
Математические методы
Методические материалы по работе персонала
Рис. 12. Виды элементов типового проектирования .
Сущность применения ТПР при элементом методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС.
К недостаткам применения этого метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимость ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирования ТПР отдельных элементов, сопоставимые со временем ручного оригинального проектирования ЭИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций.
При использовании подсистемного метода ТП ЭИС в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ЭИС.
ТПР для функциональных подсистем реализуются в виде ППП, которые позволяют осуществить:
* модульное проектирование;
* параметрическую настройку программных компонентов на различные объекты управления;
* сокращение затрат на проектирование и программирование взаимосвязанных компонентов;
* хорошее документирование отображаемых процессов обработки информации.
Вместе с тем адаптивность ТПР в виде функциональных ППП недостаточна с позиции непрерывного инжиниринга деловых процессов. Также возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная, техническая несовместимость между собой при построении единой КЭИС. Пример (1С).
При объектном методе ТП ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС.
Современные типовые проекты отличаются:
* открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах;
* масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест;
* конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления.
Преимущество объектного метода перед подсистемным заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной, технической совместимости компонентов. Примеры: "Галактика", "Парус".
Метод типового проектирования реализуется параметрически-ориентированным и модельно-ориентированным подходами.
ПАРАМЕТРИЧЕСКИ - ОРИЕНТИРОВАННОЕ
ПРОЕКТИРОВАНИЕ ЭИС
При проектировании ЭИС на основе параметрической настройки ППП последний рассматривается как "черный ящик". На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адаптации. Рассмотрим взаимосвязь основных потоков и компонентов ППП.
Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. ИД для функционирования пакета могут быть представлены в виде различных документов, причем как бумажных, так и электронных.
Результаты работы пакета могут быть представлены в виде отчетов, графиков, электронных документов, которые могут направляться во внешнюю среду.
Блок функционирования обрабатывает ИД и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных.
Параметрический поток - информация, необходимая для настройки пакета на конкретные условия функционирования. ПП включает информацию, которая задается один раз при установке этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на их режим работы. Для архитектуры "клиент-сервер" в ПП описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом.
Параметрическая информация предоставляется:
* в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатурных изделий и услуг, видов расчетов, валют);
* в таблицах описаний конфигурации программных модулей (например, условия включения/выключения модуля, режимы ручного и автоматического обновления полей данных, методы расчетов показателей).
Блок обработки параметров представляет собой совокупность специальных модулей по интерпретации значений параметров. В частности блок обработки параметров переносит установки пользователя непосредственно в прикладные программы и используемую БД. Проводимая настройка ППП позволяет использовать его для широкого класса объектов.
Блок адаптации взаимодействует с блоком функционирования и может добавлять модули и модифицировать их. Необходимость применения блока адаптации связана с потребностями доработки программных модулей ППП под воздействием внешних условий функционирования. Поэтому в состав ППП включается инструментарий адаптации существующих типовых проектных решений.
В качестве таких инструментов, доступных квалифицированному пользователю (не программисту), используются:
* генераторы программ ЭИС на основе языковых средств RAD-технологии;
* макроязыки проектирования и настройки типовых модулей.
Сущность применения метода типового проектирования ЭИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее - собственно настройке параметров и возможной доработке закупленного ППП. Технологическая сеть проектирования с помощью параметрической настройки функционального ППП включает следующие операции.
1. Определение критериев оценки функционального ППП.
2. Оценка рынка и закупка функционального ППП.
3. Настройка и внедрение ФППП.
4. Обучение персонала.
5. Эксплуатация ФППП.
6. Адаптация к внешним изменениям.
Определение критериев оценки функционального ППП
Перечень критериев выбора ППП для конкретной подсистемы определяется в зависимости от следующих характеристик проблемной области: срока разработки ИС, денежных ресурсов, технической оснащенности ОУ, существующих и функционирующих ППП, программного, сетевого оснащения.
Анализ технической документации по ППП позволил выявить перечень критериев, характеризующих в различных аспектах применение ППП, которые можно сгруппировать в подмножества и разработать для них систему классификации.
В частности, выделяют следующие группировки критериев, характеризующие ППП:
1. Назначение и возможности пакета:
1.1. Предметная область использования.
1.2. Степень обеспечения функций управления.
1.3. Общий или специализированный.
1.4. Коллективного или индивидуального использования.
1.5. Возможности оптимизации расчетов.
1.6. Возможность взаимозаменяемости ТС.
1.7. Универсальность.
1.8. Применимость для пользователей различной квалификации.
2. Отличительные признаки свойства и пакета:
2.1. Входной язык.
2.2. Управляющий язык.
2.3. Способ хранения, доступа данных.
2.4. Способы проверки данных.
2.5. Диалоговый режим.
3. Требования к программным и техническим средствам:
3.1. Вычислительная система.
3.2. Объем ОП.
3.3. Тип ОС.
3.4. Совместимость с СУБД;
4. Документация пакета:
4.1. Общее руководство по использованию.
4.2. Руководство системного и программного уровня.
5. Факторы финансового порядка:
5.1. Затраты на приобретение пакета.
5.2. Затраты на установку пакета, обучение персонала.
5.3. Экономическая эффективность использования пакета.
6. Особенности установки, эксплуатации пакета:
6.1. Объем работ по установке.
6.2. Время установки.
6.3. Трудоемкость организации информационной базы.
7. Помощь поставщика по установке и поддержанию пакета:
7.1. Обучение персонала.
7.2. Участие поставщика при внедрении пакета.
7.3. Переход от старой системы к новой.
7.4. Корректировка системы ошибок.
7.5. Внесение модификаций.
8. Оценка качества пакета и опыт его использования:
8.1. Источник появления.
8.2. Число и характер переделок пакета.
8.3. Число организаций, пользующихся пакетом.
8.4. Сравнение с аналогичными пакетами.
9. Перспективы развития пакета:
9.1. Подключение новых функциональных возможностей.
9.2. Расширение интерфейса, переход на совершенные ТС.
9.3. Совместимость со старой версией.
Каждая из групп критериев, в свою очередь, разбивается на некоторое подмножество критериев, более полно раскрывающих каждый из выделенных аспектов анализа выбираемых ППП.
Оценка рынка функциональных ППП
Осуществляется по программным средствам, имеющимся на рынке, на основе выделенных групп критериев и может производиться по методик оценки эргономических характеристик продуктов. По данной методике предполагается усреднение оценок группы экспертов, оценивающих ППП.
Для каждой характеристики на основе оценок нескольких экспертов по 10 бальной шкале устанавливаются средневзвешенные весовые коэффициенты значимости, которые нормируются внутри группы:
,
где
- комплексный валовой коэффициент;
- комплексный нормированный весовой коэффициент;
- номер комплексного весового коэффициента;
- количество комплексных весовых коэффициентов.
- единичный весовой коэффициент;
- единичный нормированный весовой коэффициент;
- номер единичного весового коэффициента;
- кол-во единичный весовой коэффициентов, входящих в i-ый комплексный весовой коэффициент;
По каждому ППП осуществляется экспертная оценка в разрезе отдельных характеристик по 10-бальной шкале. Далее оценки автоматически умножаются на весовые коэффициенты и нормируются внутри группы:
,
где
- взвешенная оценка i-й единичной характеристики;
- среднее значение бальных оценок экспертов i-й характеристики;
- среднее значение весовых коэффициентов i-й характеристики.
- взвешенная оценка i-й комплексной характеристики.
- интегральная оценка по ППП.
Взвешенные оценки характеристик суммируются по группам и в целом по ППП. ППП, получивший наибольшую взвешенную характеристику, является претендентом на принятие решения о закупке. В результате принятия решения о закупке фирмой-разработчиком заключается договор о поставке и сопровождении ППП вместе с технической документацией.
Настройка функциональности ППП
Настройка ППП по технической документации начинается с заполнения нормативно-справочной информации, необходимой для выполнения функций объекта, и далее происходит последовательное заполнение всех справочников. На вход преобразователя поступает информация предметной области, необходимая для заполнения справочников. Выходом являются заполненные справочники.
Далее происходит настройка модулей ППП, которая заключается в параметризации функций пакета. В качестве входной информации используются данные предметной области, а также техническая документация пакета. Результатом настройки модулей является пакет прикладных программ, готовый к эксплуатации.
Обучение персонала
Эта операция необходима для ознакомления, выработки навыков использования ППП. На вход поступает техническая документация пакета и сам ППП. Результатом обучения персонала являются прохождение различных контрольных мероприятий (тестов, экзаменов) и получение документов, свидетельствующих о готовности персонала к эксплуатации ППП.
Эксплуатация ППП
Операция отражает автоматизированное выполнение функции управления с помощью ППП. Входом данной технологической являются: информация проблемной области и ППП. Выходом - статистика работы пакета, которая используется для анализа эффективности функционирования ППП и выработки рекомендаций по его перенастройке.
Адаптация типовой конфигурации ППП
с использованием инструментальных средств
На вход поступают операции:
1) описание внешних изменений функционирования ППП;
2) техническая документация ППП;
3) инструментальные средства адаптации ППП.
Выходом данной технологической операции является новая, адаптированная версия ППП и обновленная техническая документация. При изменении условий функционирования используются следующие инструменты адаптации ППП:
* генераторы отчетов;
* макроязыки настройки функций ППП;
* встроенные ЯП.
Таким образом, параметрически-ориентированное проектирование ЭИС на основе использования ППП по сравнению с оригинальным проектированием дает возможности более быстрого и гибкого внедрения ИС.
Однако существует ряд проблем, сдерживающих распространение данной технологии. К ним можно отнести:
* психологические и организационные трудности внедрения ППП;
* достаточно высокую стоимость приобретения ППП и обучения персонала;
* отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках КЭИС.
МОДЕЛЬНО - ОРИНТИРОВАННОЕ
ПРОЕКТИРОВАНИЕ ЭИС
Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.
Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации-репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводится, прежде всего, к построению модели проблемной области и ее периодической корректировке.
Для моделирования проблемной области и последующих конфигураций ИС из отдельных компонентов (программных модулей) используется специальный программный инструментарий (SAP Business Engineering Workbench, BAAN Enterprise Modeler). Несомненным достоинством применения модельно-ориентированных компонентных систем перед CASE - технологиями является накапливание опыта проектирования ИС для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний об эффективных методах организации и управлении БП, которые можно адаптировать в соответствии со спецификой конкретного экономического объекта.
Репозиторий КЭИ, использующей модельно-ориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы, типовой модели определенных классов ЭИС и модели предприятия, получаемой на основе базовой или типовых моделей.
Базовая модель репозитория содержит описания БФ, БП, БО, организационной структуры, которые используются в программных модулях типовой ЭИС. при этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности ИСЮ определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразия и гибкость определения БП и соответствующих конфигураций ИС задаются с помощью набора бизнес-правил.
Типовые модели описывают конфигурации ИС для определенных отраслей (автомобильной, нефтегазовой) или типов производства (единичного, серийного).
Модель предприятия (проблемной области) строится путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия.
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация ИС, в ходе которой выполняется семантический контроль по бизнес-правилам.
Модель предприятия включает: модель функций, модель процессов, модели объектов, модель организационной структуры, модели бизнес-правил.
Модель функций
Модель функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, сервис, финансы. На следующем уровне иерархии для каждой функциональной подсистемы показываются функциональные модули: планирование, потребность в материалах. Для функциональных моделей задаются наборы бизнес-функций, для каждой из которых в дальнейшем определяются бизнес-процессы. Например, для функционального модуля "закупки" определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов.
Модель процессов
Модель БП отражает последовательность выполнения работ (операций) для функций самого нижнего уровня модели бизнес-функции, которая позволяет провести конфигурацию программных модулей ИС в соответствии с характерными особенностями конкретной проблемной области.
Для представления БП используется аппарат сетей Петри, позволяющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если известно состояние системы.
Модели объектов (данных)
В модельно-орентированной технологии проектирования ЭИС интегрирование различных БП осуществляется на основе бизнес-объектов (БО). БО - компоненты уровня проблемной области, которые используются в различных приложениях в произвольных комбинациях и не зависят от них. При этом приложение обеспечивает среду для функционирования БО.
С одной стороны, БО - это объекты-сущности, например заказы, счета, материалы. С другой стороны, в отличие от обычных объектов-сущностей БО являются самодостаточными, т.е. имеют стандартный интерфейс, написанный на языке описания интерфейсов, с помощью которого БО могут взаимодействовать друг с другом. Например, при оформлении заказа от клиента к поставщику могут использоваться следующие стандартные методы БО: выбор группы изделий в каталоге; просмотр описания изделия; выбор изделия из группы; создание заказа.
Модель организационной структуры
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала. Назначение моделирования организационной структуры применительно к ИС заключается в распределении автоматизируемых функций по работникам подразделения и определении полномочий доступа к ИС. В модели БП явно указывается закрепление автоматизируемых функций по подразделениям. Связь модели БП и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами.
Через указатели роли сотрудников устанавливается связь организационной структуры с БП. Указатель роли определяет тип работника, который может выполнять ту или иную работу (экономист, бухгалтер). Для каждой роли определяются полномочия выполнения функций, права доступа к информации, должностные инструкции. При назначении работы конкретному работнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соответствует роли, то последний не получает доступа к выполнению работы.
Модели бизнес-правил
Бизнес-правила - это специальные сведения в области типовой ЭИС, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и процессов конфигурации и эксплуатации ЭИС. Модели бизнес-правил могут быть встроены в бизнес-объекты или выделены в самостоятельные компоненты.
Правила целостности модели предприятия
Правила целостности используются для проверки согласованности модели предприятия с точки зрения полноты и непротиворечивости бизнес-функций. Например, если присутствует вариант бизнес-функции Прямой поставки, тогда бизнес-функции Обработки заказа на приобретение и Обработки заказа на сбыт должны быть представлены в модели.
Правила преобразования моделей бизнес-функций
в модели бизнес-процессов
Модель БФ может быть автоматически преобразована в модель бизнес-процесса посредством правил преобразования, которые задают соответствие БФ и бизнес-процесса. Например, если был определен вариант БФ Обработки заказа на приобретение с контрактами, необходимо выбрать бизнес-процесс Обработки контрактов.
Правила конфигурации (установки параметров)
Правила конфигурации используются для присвоения значения параметру в зависимости от его наличия в БФ, БП или их комбинациях. Например, если был определен вариант БФ Обработки заказа на покупку в режиме ЭОД, то значение параметра ЭОД настраивается на "да".
Правила установки статических условий
<< Пред. стр. 4 (из 6) След. >>
Список литературы по разделу