Диссертация (1136162), страница 7
Текст из файла (страница 7)
Тем не менеее, подход CORBA предпочтителен дляинтеграции ПО в сложных гетерогенных средах, особенно при наличии«унаследованных» приложений. Подход CORBA 3.0 получил компонентнуюмодель CCM, в значительной мере схожую с технологиями .NET и EJB (J2EE).Вероятно, наиболее востребованным, распространенным и доступнымархитектурным подходом для построения распределенных компонентных ИСможет считаться J2EE, однако его основной недостаток – относительно низкаяпроизводительность на сторонних аппаратных платформах.Объединениерассмотренныхтехнологийвозможнонаосновеархитектурного стандарта OMG, или модельно-управляемой архитектуры MDA(Model-Driven Architecture, www.omg.org/mda). Создание архитектуры ИС,независимой от программно-аппаратной платформы, потенциально позволяетпереносить ее на различные платформы ППО.
При этом автоматическаягенерация значительной части кода дает возможность существенно сократитьтрудозатраты на проектирование и реализацию ПО и повысить качествосоздаваемых программных комплексов. Архитектура MDA имеет цельюупростить интеграцию переносимых ИС посредством отображения сходныхсущностей. На базе MDA стандартизуются профили CORBA, J2EE и .NET.С точки зрения архитектуры разделяют интеграцию данных на логическом,физическом и виртуальном уровнях (иначе - на уровнях приложений, данных иметаданных:http://www.dataintegration.info/etl).Ограниченияфизическогоуровня вызваны большими объемами избыточного хранения данных (что крайнезатратно для КПК), логического - узким диапазоном связываемых приложений,виртуального - высокой нагрузкой при сложных запросах.
Разработанная вдиссертации технология существенно снижает влияние указанных ограниченийза счет каскада математических моделей и поддерживающего конвейераинструментальных средств, консолидирующих схемы данных на логическом ивиртуальном уровнях.2 Сравнительный анализ методологий разработки ИС33С появлением в конце 70-х гг. сложных КПК для управления крупнымипредприятиямивозникаетнеобходимостьмоделированиядеятельностикорпорации в ходе разработки и эксплуатации ПО. На сегодня насчитываетсяболее 50 методологий объектно-ориентированного анализа и проектирования(OOAD, Object-Oriented Analysis and Design, www.ooad.org).
Наиболеепредставительным является семейство методологий IDEF.Методологии группы IDEF с варьируемой степенью абстракциииспользуются для отображения и анализа моделей разработки ПО и включаютпоследовательно применяемые стандарты функционального моделирования(IDEF0), моделирования потоков информации (IDEF1), реляционных структурБД (IDEF1X), динамики развития ИС (IDEF2), сценарного документированияпроцессов (IDEF3), структуры объектно-ориентированных ИС (IDEF4), а такжеонтологий (IDEF5).Использование принципов абстракции, наследования, модульности,структурированности, последовательно детализируемой декомпозиции, а такжепроцедур статического и динамического (в т.ч. имитационного) моделирования,однозначной идентификации, диаграммной визуализации, коллективногопроектирования и документирования делает семейство методологий IDEFинтуитивно ясным для аналитиков и проектировщиков, позволяет выявлять икорректировать неполноту информации в корпоративной структуре.
Результатыанализа бизнес-схем в форматах IDEF могут быть использованы длястратегического и оперативного анализа и планирования деятельностипредприятия, а также для совершенствования информационного менеджмента.Важным преимуществом IDEF по сравнению с альтернативными методамипроектирования (ER, ENALIM и др.) является строгая стандартизация,позволяющая избежать неоднозначной интерпретации.Несмотря на стройность технологического цикла методологии ивозможностиоптимизации(IDEF4,IDEF5),всилунеобходимостимногоступенчатой трансформации модели ИС от IDEF0 к IDEF5, высокойсложностирядакомпонент(вособенностиIDEF2)изначительной34ресурсоемкости IDEF-методология в полном объеме применяется крайне редко.Несмотря на обеспеченность CASE-средствами всех уровней IDEF, в силулокализации инструментария CASE-проектирование ПО производится вбольшинстве случаев на уровнях IDEF0-IDEF3.IDEF-проектированиесущественноосложняетсямножественностьювнутриуровневых формальных языков (SL и EL в IDEF5), графических нотаций(PFDD, OSTN в IDEF3) и «вложенных» подмоделей (например, для классов иметодов в IDEF4).
Кроме того, научное обоснование процесса проектированияПОзатрудненоограниченнойформализованностьюсемантикиIDEFметодологии.Стандарт моделирования ПО UML [151], (www.uml.org)графическуюнотацию(язык)вформедиаграммдлявключаетспецификации,визуализации, конструирования и документирования ПО. В настоящее времяUMLде-фактоявляетсяотраслевымстандартомразработкиКПКииндустриального ПО и поддержан в этом качестве OMG.UMLиспользуетсякакметодизученияповеденияобъектноориентированных ИС, а также как язык для извлечения данных и знанийо предметной области, формализации закономерностей функционирования ИС икоординации деятельности разработчиков ПО.Язык UML состоит из статических диаграмм структуры, классов, объектов,пакетов, прецедентов, взаимодействия, последовательностей, сотрудничества,поведения, состояний, действий, реализации, компонент, а также диаграммразвертывания.Статические диаграммы UML моделируют архитектуру ПО и описываюттипы данных и отношения между ними в форме двухуровневой абстракции –домена (domain) и «пакета» (package) – на основе общности свойств.ДинамическиедиаграммыUMLпредназначеныдлямоделированиявзаимодействия экземпляров классов, разработанных с помощью статическоймодели, во время выполнения программы.35В ходе исследования будет показано, что UML-диаграммы могут служитьграфической интерпретацией построения модели динамики и статики объектовданных по схеме двухуровневой концептуализации (свертывания).Для моделирования статической структуры классов и объектов данных впредметной области, а также связей между ними (таких как наследование,ассоциация, агрегация и др.) в UML применяются диаграммы классов.ТиповыемоделируютсясценарииприролевыхпомощиинтерфейсовпользователейнеформализованныхсИСестественно-языковыхспецификаций в виде вариативных диаграмм прецедентов (use-case).Динамика взаимодействия объектов данных учитывается посредствоммеханизма сообщений в диаграммах последовательностей и сотрудничества.Для моделирования динамики состояний объектов данных в зависимостиот событий применяются диаграммы состояний, содержащие явно указанныемножества допустимых переходов.
В главе II настоящей работы понятиесостояния конкретизируется и уточняется при моделировании семантикиинтеграции и управления гетерогенными данными (контентом) в КПК.МоделированиепараллельныхпроцессоввUMLосуществляетсяпосредством диаграмм действий, основанных на принципе структурнойдекомпозиции на элементарные задачи (ветвление, безусловный переход,параллельная задача и др.). В отличие от семантическиориентированныхблоксхем (например, индуктивного метода Р.Флойда [185]), семантика диаграммдействий UML не формализована.UML-методология диаграмм обладает большей гибкостью по сравнению сIDEF, т.к.
не требует строго последовательного применения входящих в неетипов графических нотаций, а также позволяет вести проектирование ИС втерминах, близких к естественно-языковым. Тем не менее, UML-методология невполне формализована и разработка ее семантики математическими средствамине производилась.Процессно-ориентированная нотация ARIS Extended Event DrivenProcess Chain (eEPC) разработана группой исследователей компании IDS Scheer36AG (www.ids-scheer.com) под руководством проф. А.В.Шеера и служит дляописания процессов, управляемых событиями. В рамках нотации используютсяобъектыдляописанияфункций,выполняемыхподразделениямиилисотрудниками корпорации, состояний ИС, управляющих выполнением этихфункций, оргструктуры предприятия, носителей информации, прикладных ИС,данных в форме набора сущностей и связей, отношений между объектами, атакже связей между событиями и функциями (с учетом ветвления).Связи между объектами отражают последовательность функций процесса.Функции инициируются и завершаются не более чем одним событием, а объектыинициализируются расширяемыми наборами атрибутов.Описаниебизнес-процессапредставляетсобойпоследовательностьпроцедур в порядке их выполнения (без учета реальной длительности).Графически заданные логические предикаты позволяют отразить ветвление ислияние корпоративных бизнес-процессов.
Нотация eEPC эквивалентнапоследовательномуиспользованиюнотацийIDEF0иIDEF3.Важнымпреимуществом eEPC является обеспечение возможности двунаправленного(как «снизу вверх», так и «сверху вниз») проектирования прикладного ПО.В силу громозкости (насчитывается до 85 видов «моделей» – графическихдиаграмм) и неформализованности методологии eEPC, ее применение можетоказаться рентабельным только для очень крупных КПК (с десятками тысячодновременно работающих пользователей) и федеративных прикладных систем.Особенности применения графических нотацийПрипроектированииИСкрупномасштабныхгетерогенныхКПКтребованиям близости к предметной области, стандартизации, поддержкиколлективного проектирования, гибкости и эргономичности наиболее полноотвечает подход UML.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
