| Разработка диаграммы деятельностей |
| Детализация диаграммы прецедентов использования |
| Разработка диаграммы взаимодействий объектов |
| Уточнение диаграммы состояний |
| Детализация диаграммы классов объектов |
| Детализация диаграммы компонентов |
Рис 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-й комплексной характеристики.
