Содержание к диссертации
Введение
ГЛАВА 1. Краткое описание предметной области и постановка задачи 18
1.1. Процесс проектирования программных систем 18
1.1.1. Корпоративные приложения 18
1.1.2. Этапы проектирования 19
1.1.3. Требования к программному продукту 20
1.1.4. Моделирование сложных программных систем 21
1.1.5. Проектирование по образцам 22
1.2. Архитектура, управляемая моделью 25
1.3. Unified Modeling Language 27
1.3.1. Краткая характеристика UML 28
1.3.2. Основные элементы UML 29
1.3.3. Диаграмма классов 31
1.3.4. Диаграмма компонентов 32
1.3.5. Диаграмма размещения 35
1.4. Технологии Java 2, Enterprise Edition 38
1.4.1. Краткий обзор технологий J2EE 38
1.4.2. Многоуровневая архитектура J2EE 42
1.4.3. Размещение приложения J2EE на сервере 45
1.4.4. Проблемы практического использования J2EE 46
1.5. Постановка задачи 47
ГЛАВА 2. Теоретическая база методики визуального моделирования корпоративных приложений 51
2.1. Основные идеи, положенные в основу методики автоматизированного проектирования 51
2.2. Процесс разработки корпоративных приложений с использованием визуализации 53
2.3. Абстрактная модель проектируемой системы 57
2.4. Определение метамодели 60
2.4.1. Мета-метамодель, метамодель и модель 61
2.4.2. Метамодель Model Driven Architecture 62
ГЛАВА 3. Спецификации визуальных элементов для моделирования корпоративных приложений 63
3.1. Спецификации визуальных элементов для разработки Web-
приложений 64
3.1.1. Назначение диаграммы Web Module 65
3.1.2. Сценарии, реализуемые диаграммой Web Module 65
3.1.3. Детализация визуальных элементов 67
3.1.4. Работа с диаграммой Web Module 81
3.2. Спецификации визуальных элементов для разработки модулей EJB 83
3.2.1. Введение в технологию EJB 83
3.2.2. Назначение диаграммы EJB Module 96
3.2.3. Сценарии, реализуемые диаграммой EJB Module 96
3.2.4. Детализация визуальных элементов 98
3.2.5. Работа с диаграммой EJB Module 106
3.4. Диаграмма Enterprise Module 108
3.4.1. Назначение диаграммы 108
3.4.2. Сценарии, реализуемые диаграммой Enterprise Module 109
3.4.2. Интерфейс пользователя 109
3.4. Обобщенная диаграмма размещения корпоративного приложения 110
ГЛАВА 4. Практическая реализация визуальной методики автоматизированного проектирования 112
4.1. Абстрактный программный интерфейс приложения 112
4.1.1. Source Code Model 115
4.1.2. Deployment Model 115
4.1.3. Модуль Plug-ins 116
4.1.4. Описание абстрактного программного интерфейса 116
4.2. Программный интерфейс для модулей EJB 121
4.3. Программный интерфейс для Web-приложений 133
4.4. Программный интерфейс для корпоративного приложения 140
4.5. Проектирование корпоративных приложений с помощью графического подхода 148
4.6. Разработка образцов 158
ГЛАВА 5. Оценка эффективности использования графического подхода для автоматизации проектирования корпоративных приложений 160
Заключение 166
Список сокращений 169
Список использованных источников
- Требования к программному продукту
- Процесс разработки корпоративных приложений с использованием визуализации
- Назначение диаграммы Web Module
- Описание абстрактного программного интерфейса
Введение к работе
Объектом исследования диссертационной работы является процесс проектирования так называемых корпоративных приложений, то есть программных продуктов, так или иначе связанных с функционированием предприятия и нацеленных на повышение его эффективности. Проектирование программных продуктов — сложный итеративный процесс, успех которого зависит от грамотной организации самого процесса, выбора архитектуры и технологии разработки, а также от качества проектной документации.
Технологии Java 2, Enterprise Edition (J2EE) объединяют наиболее современные подходы и решения, непосредственно предназначенные для разработки распределенных программных систем уровня предприятия. J2EE представляет собой комплекс взаимодействующих Java-технологий, базирующихся на спецификациях фирмы "Sun Microsystems".
Стандарты J2EE характеризуют следующие важные преимущества:
независимость от платформы, связанная с основными свойствами языка Java ([23,24]);
высокая технологичность, связанная с широким использованием компонентных технологий;
переносимость и расширяемость;
поддержка многопользовательского режима;
возможность интеграции с другими платформами и информационными системами;
обеспечение надежной защиты информации.
Технологии J2EE реализуют многоуровневую и многосвязную архитектуру приложений, основанную на компонентной организации, гарантируют качество низкоуровневых служб и обеспечивают совместимость взаимодействующих приложений. Таким образом, эти технологии полностью удовлетворяют высоким требованиям, предъявляемым к современным распределенным Интернет-ориентированным системам, и являются одним из самых мощных средств проектирования и разработки корпоративных приложений.
Однако преимущества компонентных технологий, которые должны были бы сделать процесс проектирования простым и технологичным, на практике нивелируются сложностями, связанными с трудозатратами на их изучение и многочисленными проблемами, возникающими при их реальном использовании. Руководители проектов неизбежно сталкиваются с нехваткой специалистов достаточно высокой квалификации и необходимостью проектирования в условиях дефицита времени.
Из публикаций, посвященных общим вопросам объектно-ориентированного моделирования, проектированию с использованием образцов и описанию технологий J2EE, следует особо отметить работы Г.Буча и Д.Рамбо ([2, 3, 30, 78, 79]), И.Якобсона ([47, 48]), П.Коада и Э.Йордана ([32, 33, 34, 35]), М.Фаулера и К.Скотта ([25]), П.Перроуна и В.Кришны ([22]), И.Грэхэма ([41]), Э.Гаммы ([39]) и Э.Романа ([77]). В них излагаются базовые понятия, архитектура J2EE и детали технологий, но проблемы практического освоения этих технологий, их реального применения и потенциальные возможности автоматизации проектных процедур рассматриваются недостаточно.
Задачи облегчения использования технологий J2EE и автоматизации проектирования корпоративных приложений становятся особенно
актуальными в связи с все возрастающим спросом на разработку программных систем данного типа.
На наш взгляд, эффективным решением указанных проблем является сочетание графического подхода к моделированию программных систем с компонентными технологиями J2EE. В настоящее время активно развивается направление, связанное с архитектурой, управляющей проектом (Model Driven Architecture, MDA). Этот подход позволяет получать глобальные проектные решения, применимые для любой среды разработки и любого конкретного языка программирования.
Общеизвестно, что наиболее удобным и легким для восприятия средством представления любой системы является ее графическое отображение (визуальное моделирование). Стремление к унификации графических элементов, используемых для проектирования, привело к тому, что международной рабочей группой по развитию стандартов объектного программирования (Object Management Group, OMG [74]) в 1997 г. был принят стандарт унифицированного языка моделирования (Unified Modeling Language, UML). Этот язык является основой автоматизированного проектирования и создания программ (Computer-Aided Software Engineering, CASE). Язык UML непрерывно развивается, и в настоящее время действующим является стандарт UML 2.0. Создание среды разработки, позволяющей представлять модель проектируемого корпоративного приложения в графическом виде, следовало вести в рамках общепринятого стандарта UML.
Стандарты UML определяют визуальные элементы, отображающие компоненты программы и связи между ними. Диаграммы UML могут быть использованы как для графического представления модели проектируемой системы, так и для генерации программного кода. Это привело к возникновению интегрированных сред разработки программных продуктов,
ярким представителем которых является Borland@RTogether@R ControlCenter@R x.x. Главное назначение CASE-средств— проектирование больших и сложных программных систем, поэтому вполне естественным является стремление сочетать возможности MDA и UML с мощным потенциалом платформы J2EE.
На сегодняшний день существует не так много продуктов, поддерживающих разработку т2ЕЕ-приложений, из которых только один (WebSphere Studio Application Developer, WSAD) поддерживает визуальное моделирование с помощью UML. Как видно из Таблицы, ни один из существующих продуктов не поддерживает моделирование корпоративных приложений, поэтому на предприятиях используется несколько продуктов: одни - для описания системы, другие - для ее разработки. Это усложняет процесс проектирования и требует дополнительных затрат для синхронизации при малейших изменениях в системе.
Таблица Сравнение инструментальных средств разработки
В настоящей работе предлагаются теоретическая база и методика визуального проектирования корпоративных приложений. Результатом
применения предлагаемого подхода является исчерпывающий набор спецификаций, на основе которых создана инструментальная программная система автоматизированной разработки корпоративных приложений. Кроме того, предложен универсальный абстрактный интерфейс и абстрактная модель на его основе, позволяющая описывать практически любые реальные модели данных.
Актуальность проблемы автоматизации проектирования корпоративных приложений подтверждается тем, что ее решение позволит облегчить и формализовать процесс моделирования, а также ускорить процесс разработки и размещения приложений на серверах. Процесс проектирования при этом становится более качественным и технологичным, что существенно сокращает общие затраты на проектирование и кодирование программных продуктов рассматриваемого класса.
Автором разработаны теоретическая база и методика визуального проектирования корпоративных приложений. Предлагаемая методика обеспечивает возможность технологичной и качественной разработки программных систем уровня предприятия в заданные сроки и существенно сокращает общие затраты на проектирование и кодирование программных продуктов.
Результатом применения данного подхода является исчерпывающий набор спецификаций, на основе которых создана инструментальная программная система автоматизированной разработки корпоративных приложений. Все вышесказанное подтверждает актуальность настоящей работы.
Целью диссертации является разработка методики проектирования корпоративных приложений с использованием их графического представления, создание новых типов визуальных элементов, адекватно отображающих свойства корпоративных приложения, разработка
абстрактного подхода к проектированию с использованием компонентных технологий и, в частности, платформы J2EE. Предлагаемые методики позволят повысить производительность труда разработчиков и эффективность проектирования.
Для достижения этих целей в работе ставились и решались следующие задачи:
разработка универсального набора абстрактных интерфейсов и реализация на его базе абстрактной модели с возможностью ее в интеграции в другие программные продукты;
создание новых визуальных элементов для представления приложений J2EE и их отдельных компонентов (в полном соответствии со стандартом UML) с целью автоматизации процесса проектирования;
разработка методики автоматической генерации исходного кода и дескрипторов поставки на основе созданных моделей, их синхронизация с моделью;
разработка методики проектирования сложных распределенных приложений, использующей графический подход и позволяющей в рамках одного проекта создавать программную систему и размещать ее подсистемы на различных серверах;
создание визуальных шаблонов, реализующих Д2ЕЕ-образцы, и разработка методики их использования в процессе проектирования корпоративных приложений;
автоматизация процесса размещения приложений на различных серверах с учетом их специфики;
практическая реализация полученных теоретических результатов, а именно, создание инструментальных программных средств, ориентированных на программистов средней квалификации и
позволяющих автоматизировать моделирование, кодирование и размещение на серверах сложных программных систем.
В качестве методов исследования в диссертации используются принципы объектно-ориентированного проектирования, системный анализ, теория графов, принципы технологичности, простоты разработки и повторного использования. Применяются архитектура и технологии платформы J2EE, Model Driven Architecture (MDA), Model Driven Development (MDD), стандарты Unified Modeling Language (UML), CASE-средства, а также Constructive Cost Model II (COCOMO II) для оценки эффективности процесса разработки программного продукта.
Достоверность полученных результатов подтверждается следующим образом:
В процессе создания абстрактной модели, отвечающей требованиям универсальности и расширяемости, и абстрактного API, а также конкретной модели и конкретного АРІ для платформы J2EE последовательно применялись принципы MDA.
Разработка новых визуальных элементов производилась в строгом соответствии с требованиями общепринятого стандарта UML, зарегистрированного группой OMG.
Осуществлялась постоянная проверка полноты разработанных визуальных элементов, их адекватности набору компонентов J2EE и соответствия спецификациям фирмы-разработчика платформы J2EE "Sun Microsystems".
Образцы, реализованные автором, разрабатывались в контакте с ведущим специалистом Джоном Круппи, под руководством которого создавались .12ЕЕ-шаблоны в "Sun Microsystems". Производились экспертные оценки визуальных шаблонов.
Корректность исходного кода и дескрипторов поставки, генерируемых на основе визуальной модели, а также их взаимная синхронизация проверялись полномасштабным тестированием.
Достоверность технических решений подтверждается
a. сравнением с другими продуктами и подходами,
b. анализом экспериментальных показателей результатов
практического использования.
7. Для оценки достоверности полученных результатов привлекались
независимые эксперты. Получены положительные отзывы крупных
предприятий, таких, как SAP ("Systems, Applications, and Products in Data
Processing") и RBS ("Royal Bank of Scotland").
Научная новизна работы состоит в следующем:
Предложен и теоретически обоснован новый графический подход к разработке сложных распределенных программных систем уровня предприятия.
Разработана новая абстрактная модель корпоративного приложения и соответствующий абстрактный программный интерфейс (Application programming Interface, API).
Предложен метод построения моделей и программных интерфейсов, поддерживающих конкретные компонентные технологии на основе абстрактной модели и абстрактного программного интерфейса.
Предложена методика автоматизации основных проектных процедур: моделирования, кодирования и размещение приложений на сервере. В рамках UML разработаны спецификации новых .І2ЕЕ-диаграмм, в том числе обобщенная диаграмма размещения.
Для поддержки типовых проектных решений разработаны новые визуальные элементы, реализующие Д2ЕЕ-образцы.
На защиту выносятся следующие основные положения:
Расширяемая абстрактная модель для представления иерархически-связанных элементов и абстрактный программный интерфейс (Application programming Interface, API) к ней, а также метод построения конкретных моделей и конкретных программных интерфейсов для проектирования корпоративных приложений, поддерживающих выбранную компонентную технологию (J2EE, .NET, CORBA и пр.), на основе абстрактной модели и абстрактного API.
Методика визуального моделирования корпоративных приложений с использованием технологий J2EE. На основе стандарта UML разработаны и специфицированы новые типы визуальных элементов для графического представления программной системы рассматриваемого класса, адекватно описывающие его свойства и служащие основой для последующей автоматической генерации кода и размещения приложения на сервере.
Методика проектирования распределенных программных систем с использованием обобщенной диаграммы размещения, позволяющая в рамках одного проекта реализовать автоматическое размещение подсистем на различных серверах.
Новые визуальные элементы, реализующие шаблоны J2EE. Использование этих элементов в процессе проектирования облегчает и ускоряет решение типовых задач, часто встречающихся при разработке корпоративных приложений.
Практическая значимость работы заключается в следующем:
1. Предложенный метод визуального проектирования корпоративных приложений на основе технологии J2EE доведен до практической реализации в реальных продуктах (Borland!* Together@R ControlCentergR 6.x; BorlandgR JBuilder; BorlandgR Together@R ControlCenter@R, Eclipse Edition), которые уже длительное время используются разработчиками.
Предложенный программный интерфейс и реализованная на его основе абстрактная модель могут быть с успехом использованы для разработки других программных продуктов.
Использование данной методики позволяет сократить затраты на проектирование и существенно снизить их при внесении каких либо изменений в технические требования на разрабатываемую систему, а также на начальном этапе проектирования (по экспериментальным оценкам от 25% до 50%, в зависимости от объема и сложности проекта).
Основные результаты диссертационной работы обсуждались в рамках научно-практических конференций СПбГПУ (2001г. - 2004г.), на 2-й международной научно-практической конференции «Информационные технологии в моделировании и управлении» (Санкт-Петербург, 2000г.), на конференции «Bea User's Conference» (Даллас, США, 2002г), на семинаре для отдела маркетинга фирмы «Togethersoft» (Рэйли, США, 2002г.), на семинаре для отдела поддержки фирмы «Togethersoft» (Рэйли, США, 2003г.), на конференции «Технологии Microsoft в теории и практике программирования» (Санкт-Петербург, 2004г.), на 5-й международной научно-технической конференции «Компьютерное моделирование 2004» (Санкт-Петербург, 2004г.), на семинаре «Royal Bank of Scotland» (Лондон, Великобритания, 2005г.) и на научно-техническом семинаре профессорско-преподавательского состава кафедры «Информационные и управляющие системы» СПбГПУ (Санкт-Петербург, 2005г.).
Автором проводились также теоретические и практические занятия для разработчиков интеграционной команды фирмы «Togethersoft» (Рэйли, США, 2002г.), для разработчиков фирмы «Borland» (Прага, Чехия, 2004г.), для студентов СПбГПУ (Санкт-Петербург, 2004г.).
Результаты диссертационной работы использовались при разработке диаграмм и компонентов J2EE, вошедших в интегральную среду разработки линии Borland@RTogether@R ControlCenter@R.
Методика автоматизированной разработки корпоративных приложений внедрена в ООО «Интеллект-ФТК» при разработке учебно-методического комплекса. Практическое использование представляемых на защиту результатов подтверждается соответствующими актами о внедрении. По материалам диссертации опубликовано 6 работ.
Кратко остановимся на структуре работы. Диссертация содержит 178 страниц основного текста, 71 рисунок, 12 таблиц и состоит из введения, 5 глав, заключения, списка сокращений и списка использовавшихся источников.
Первая глава посвящена изучению процесса проектирования корпоративных приложений, исследованию архитектуры, управляемой моделью (MDA), унифицированного языка моделирования (UML) и технологий J2EE с точки зрения их применимости для автоматизации разработки сложных программных систем. В этой же главе содержится постановка задачи.
Во второй главе содержится описание теоретических основ методики визуального проектирования, разработанных автором на основе анализа концепций MDA, стандартов UML и технологий J2EE.
В третьей главе предлагаются к рассмотрению спецификации визуальных элементов, предназначенных для моделирования и разработки приложений J2EE.
Четвертая глава содержит описание реализации предлагаемой методики автоматизированного проектирования, рассматриваются абстрактный и конкретный программные интерфейсы, классы и образцы,
разработанные автором. Кратко описываются инструментальные средства разработки.
В пятой главе анализируется эффективность разработанной методики. Приводятся результаты сравнительного анализа практического проектирования по предлагаемой методике визуального проектирования и с помощью традиционного подхода.
Заключение подытоживает результаты диссертационной работы, выносимые на защиту.
Требования к программному продукту
Требования, предъявляемые к современным программным продуктам как заказчиками, так и самими разработчиками, подробно описаны в [7, 10, 22]. Их можно разделить на две группы: - функциональные требования, определяемые заказчиком; - нефункциональные требования, связанные с удобством использования программного продукта, его надежностью и эффективностью.
Несмотря на несомненную важность первой группы требований, нефункциональные требования к программным системам становятся наиболее важными в условиях все обостряющейся конкуренции на рынке высоких технологий. Именно стремление удовлетворить этим требованиям вызывает совершенствование проектных решений.
Перед руководителем проекта неизбежно встают вопросы: - Сколько людей потребуется для разработки? - Как уложиться в заданные сроки? - Как разделить задачу на отдельные части, которые можно разрабатывать параллельно? - Как обеспечить выполнение всех требований заказчика? - Что может затормозить работу? - Как на ранних стадиях проектирования учесть возможные изменения в требованиях заказчика и возможное расширение проектируемой системы в будущем? - Какую архитектуру и технологию выбрать?
Адекватная модель программного продукта позволяет избежать многих неприятностей, связанных со сложностью разработки и сжатыми сроками, отводимыми на процесс проектирования.
Структурное моделирование ([11, 13]) предполагает рассмотрение системы на различных уровнях абстрагирования. Это позволяет моделировать систему с различной степенью детализации и при этом каждый раз иметь дело с легко обозримым и компактным описанием.
Поведенческое моделирование предназначено для анализа динамики системы. Проектируемый программный продукт должен быть корректно описан, и его модель должна быть достаточной для разработки архитектуры будущего приложения. В свою очередь, архитектура приложения представляет собой совокупность моделей, отображающих структуру и поведение проектируемого программного продукта.
При объектно-ориентированном подходе ([2, 3, 10, 31, 32, 33, 34, 35, 40]) система на данном уровне рассмотрения разбивается на компоненты, характеризующиеся своими параметрами и обладающие определенным поведением. Эти компоненты представляют собой целостные абстракции данной предметной области, и работа системы в целом описывается как совокупное поведение объектов-участников с учетом их взаимодействий друг с другом и с внешней по отношению к данной системе средой.
Объектно-ориентированная декомпозиция ([1, 16, 17, 19]) отличается от декомпозиции структурной. Объектный подход рассматривает программную систему как систему некоторых взаимосвязанных и взаимодействующих сущностей (объектов). Объекты имеют некоторые параметры или атрибуты (данные), и им присущи некоторые действия (методы), которые отражают поведение данного объекта в системе, могут изменять собственные параметры объекта, а также определенным образом влиять на поведение других объектов системы. Принципы объектно-ориентированного проектирования полностью поддерживаются стандартами MDA / MDD, унифицированным языком моделирования UML и такими современными компонентными технологиями, как .NET, CORBA и J2EE.
Питер Коад ([18, 32, 33, 34, 35]) справедливо считает, что наиболее эффективным является обучение на примерах. Это касается и проектирования программных продуктов. Естественно стремление максимально учесть как свой собственный опыт, так и опыт других разработчиков. Идеи проектирования на основе лучших образцов развиваются также в работах других авторов [38, 39, 40, 68], и интерес к разработке готовых шаблонов с течением времени только усиливается.
Действительно, нетрудно заметить, что многие классы и объекты оказываются похожими в различных разработках, функциональность некоторых частей различных систем также сходна. Так, например, задачи класса e-commerce ([59]) в большинстве случаев имеют совершенно определенные общие очертания. Это приложения, как правило, предполагающие регистрацию пользователя в системе с предоставлением ему определенных прав доступа и обеспечивающие некоторый набор возможностей на основе информации, хранящейся и обновляемой в базе данных. Довольно широкий круг задач, представляющих разные предметные области и ориентированных на работу в сети Интернет, можно свести к задаче «Электронный магазин».
Повторяемость проектных решений дает возможность таким образом проектировать программные системы на основе компонентных технологий, чтобы быстро и эффективно строить новую систему на основе готовых и проверенных кирпичиков, адаптируя их к конкретным особенностям системы. Основным результатом удачной разработки является достижение заданной цели при наименьших затратах и в кратчайшие сроки. Возможность повторного использования лучших технических решений (reusability) является одним из ключевых моментов.
Процесс разработки корпоративных приложений с использованием визуализации
В соответствии с определением, данным в [1], автоматизированная система представляет собой программно-аппаратный комплекс, выполненный на базе средств вычислительной техники, предназначенный для решения задач проектирования на основе получения и использования моделей объекта проектирования. Одним из перспективных направлений является сведение различных аспектов поведения системы в некоторую единую схему.
Применяя методы системного анализа к объекту исследования (обобщенному корпоративному приложению), пространство объектов ОЕ можно представить как совокупность объектов уровней бизнес-логики Ов, представления Ow и интеграции О/, удовлетворяющую заданным требованиям R:
Используя принцип декомпозиции, будем рассматривать эти подпространства как отдельные, но взаимосвязанные части проектируемой системы.
При разработке графической модели пространство объектов проектирования ОЕ отображается в совокупность графов GE: OE GE = GB\]GW\}GI, где GE, GB, GW, GI принадлежат пространству G плоских изоморфных графов (диаграмм) и визуально отображают уровни бизнес-логики, представления и интеграции, соответственно. В UML вершины графа трактуются как узлы, представляющие собой визуальные элементы v/, отображающие компоненты соответствующего уровня.
Каждый элемент vt, принадлежащий пространству визуальных элементов (v/Є V), в общем случае, имеет имя Ni, атрибуты (свойства) Ак (k=l,..kmax) и обладает некоторым поведением, отображаемым набором операторов (методов) Орт (т -1,...тМах). Можно выделить ограниченное рМах множество TV типов визуальных элементов Tv = \j Tvp и каждому типу TvP Р=\ поставить в соответствие двумерное графическое изображение, имеющее специфический для данного типа дизайн DvP. Тогда узел v/є V типа TvP можно описать следующим образом: кМах тМах Пп \\П\ v,=W,U4. U OpJ\Dvf А=1 от=1
Узлы V/ и V/ могут быть связаны ребром графа (связью) sy. Связи отражают отношения между компонентами. Определено множество 7 типов связей между компонентами, элементами которого являются «зависимость», «наследование», «ассоциация», «агрегация» и т.д.
Следовательно, каждая связь sy принадлежит пространству связей S (sy є S) и имеет некоторый тип TsP.
Связь характеризуется наименованием связи Nsy, типом и, возможно, некоторыми свойствами Psij, например, направленностью, отношением множественности и т.п.: Шах P V = IK,,
Каждый тип связи Tsp также имеет свой дизайн DsP. Тогда связь Si/є S типа DsP можно описать следующим образом: Шах s9={NSi/9\JPsgJ}\Dsp 1=1
Диаграмма GreG некоторого типа г представляет собой объединение подпространства визуальных элементов Vre V и подпространства связей SreS, причем, на ней могут располагаться и изолированные элементы. Отдельный визуальный элемент, соответствующий компоненту, можно понимать как нуль-граф. Диаграмма имеет имя Ngr и обладает набором свойств Pgr, соответствующих одному из типов диаграмм TgP. Каждому из определяемых типов диаграмм TgP соответствует свой дизайн DgP: Gr={Ngr,Vr[jSr,Pgr}\Dgp
Граф GE представляет все корпоративное приложение в целом, т.е. совокупность входящих в него модулей, причем, может содержать kwKtax несколько модулей уровня представления Gw = \j(Gw)kw, несколько іи = 1 kbMia модулей бизнес-логики GH= (J( GH )kh И т.д. kb=\
Свойства диаграмм и размещенных на них элементов могут служить основой для автоматической генерации частей кода и дескрипторов поставки. В процессе кодогенерации совокупность графов GE отображается в кодовое пространство С и пространство текстовых дескрипторов поставки D: GE= {C,D}
Основой всего проекта является абстрактная модель, отражающая общие требования к архитектуре и функциональности системы вне зависимости от операционной системы, выбранной компонентной технологии и языка программирования.
Абстрактная модель может быть трансформирована в специфичную для платформы модель. На этом этапе уже появляются понятия, связанные с выбранными технологиями: для платформы J2EE это компоненты EJB, сервлеты, страницы JSP, библиотеки тэгов и т.п. Рис. 2.1. иллюстрирует процесс разработки корпоративного приложения с использованием предлагаемой автором методики.
Визуальные элементы Д2ЕЕ-модели создаются на базе стандартных элементов UML. Рис. 2.1 отражает роль спецификаций платформы и конкретного сервера приложений в формировании окончательной модели приложения J2EE, размещенного на выбранном промышленном сервере.
Назначение диаграммы Web Module
Диаграмма Web-приложения (Web Module diagram) предназначена для визуального моделирования, конструирования и размещения Web-приложения в Web-контейнере. Кроме настоящей спецификации, разработана также спецификация, расширяющая классовую диаграмму и позволяющая работать с некоторыми Web-элементами на классовой диаграмме. Диаграмма Web Module фактически является визуальным представлением дескриптора поставки для Web-приложения [4, 5, 7].
На классовой диаграмме специальным образом выделяются классы, относящиеся к Web-приложению (такие, как сервлеты, фильтры и т.п.). Эти элементы имеют дополнительные свойства, используемые при размещении приложения на сервере.
Пользователь имеет возможность создать и моделировать Web-приложение: создать диаграмму Web Module, добавить необходимые компоненты на нее и редактировать их свойства.
Пользователь должен иметь возможность создать сервлет (servlet), фильтр (filter) или слушатель событий (listener) как класс на диаграмме классов. В дальнейшем ему предоставляется возможность ссылаться на эти классы из диаграммы Web Module.
Пользователю предоставляется возможность добавить сервлет и страницу JSP к Web-приложению. Для этой цели на линейке инструментов диаграммы Web Module предусматриваются соответствующие пиктограммы. Сервлет и страница JSP должны представляться на диаграмме визуальными элементами. Каждый элемент имеет набор свойств, значения которых могут быть установлены пользователем. Визуальные элементы имеют вид компонентов с соответствующими стереотипами. На диаграмме должен быть также представлен визуальный элемент «страница ошибки».
Пользователь имеет возможность добавить библиотеку тэгов к Web-приложению в виде визуального элемента, который ссылается на диаграмму Taglib или на tld- и jar- файлы.
Концепция разработки: диаграмма должна представлять в графическом виде процесс создания и модификации Web-приложения. Диаграмма должна являться визуальным представлением дескриптора поставки.
Диаграмма должна иметь следующие свойства (properties), отображаемые в дескрипторе поставки соответствующими тэгами: о Small icon ( small-icon ) - маленькая пиктограмма; о Large icon ( large-icon ) - большая пиктограмма; о Display name ( display-name ) - выводимое имя; о Description ( description ) - описание; о Distributable ( distributable ) - подлежит распределению; о Session timeout ( sessionimeout ) - ограничение по времени сеанса связи (при отсутствии отклика).
В первоначальной версии на диаграмме Web-приложения располагались следующие визуальные элементы, необходимые для формирования любого Web-приложения: - Servlets and Filters (Сервлеты и Фильтры); - Security Role (Роль секретности); - Principal (Принципал, основное действующее лицо); - Security Constraint (Ограничение секретности); - Web Resource Collection (Коллекция Web-ресурсов); - EJB Reference (Ссылка на компонент EJB); - Environment (Ссылка на переменную программного окружения); - Resource (Ссылка на ресурс); - JSP (Страница JSP); - JSP Collection (Коллекция страниц JSP); - Web Files ("Web-файлы": рисунки и пр.); - Filter Mapping (Привязка фильтра); - Error Page (Страница ошибок); - Taglib (Библиотеки тегов); - Web Link (Web-связь); - Стандартные элементы UML Note (Комментарий) и Note Link (Связь комментария).
В дальнейшем было принято решение максимально приблизить визуальную модель приложения к дескриптору поставки, используя стандартные UML-средства с небольшими дополнениями. А именно, за основу была взята стандартная компонентная диаграмма UML. Далее представлены элементы, вошедшие в окончательный вариант спецификации.
Описание абстрактного программного интерфейса
Этим группам приписываются следующие роли ([37]): Enterprise JavaBean provider (Поставщик компонентов EJB). В функции поставщика компонентов EJB входит разработка Java-классов реализации компонентов EJB и соответствующих интерфейсов;
- Application assembler (Специалист, объединяющий компоненты в более крупные программные единицы — модули). Его задачей является комбинирование компонентов в модули, подготовка описания структуры модуля EJB и его сохранение вместе с соответствующим описанием (дескриптором поставки) в одном или нескольких архивных JAR-файлах;
- EJB deployer (Специалист, обеспечивающий размещение приложения на сервере). Этот специалист обладает знанием конкретного сервера J2EE и свойств программного окружения приложения. Он размещает один или несколько архивных JAR-файлов на сервере приложений с учетом специфики конкретного сервера приложений и программного окружения;
- System administrator (Системный администратор) отвечает за управление системой и контролирует работу сети, в которой функционирует сервер приложений;
- Server provider (Поставщик сервера приложений) В функции специалистов этой группы входит поддержка работы сервера приложений в полном соответствии с требованиями платформы J2EE (поддержка транзакций, обеспечение секретности и т. д.);
- EJB container provider (Поставщик контейнера EJB). Этот специалист должен поддерживать функциональность контейнера, обновление версий спецификации EJB и т. п. Так как контейнер EJB функционирует на сервере приложений и является его неотъемлемой частью, роли поставщика сервера приложений и поставщика контейнера EJB, как правило, объединяются;
- Tools vendors (Разработчики инструментальных средств, поддерживающих работу компонентов EJB). Поставщик инструментальных средств поставляет продукты, облегчающие и автоматизирующие разработку.
Спецификации, предлагаемые автором, призваны облегчить задачу для каждой из вышеописанных категорий, так как охватывают весь спектр задач от моделирования модулей EJB и до разработки инструментальных средств.
Процесс разработки EJB-приложения включает следующие основные этапы, которые целесообразно автоматизировать: - разработку компонентов EJB; - ассемблирование, то есть комбинирование компонентов и представление их в виде модулей; - размещение модуля в контейнере EJB на сервере приложений.
Компонент Enterprise JavaBean {EJB) — это компонент серверной стороны, написанный на языке Java, который инкапсулирует бизнес-логику приложения и используется как основной элемент для реализации среднего уровня многоуровневых приложений J2EE. К компонентам EJB возможен как удаленный доступ, так и локальный доступ в пределах одного контейнера. Компоненты EJB основываются на концепции распределенных объектов.
Преимущества использования компонентов EJB связаны со следующими основными факторами: - за системную поддержку и обслуживание компонентов EJB отвечает контейнер EJB, в котором эти компоненты функционируют, т. е. поставщик реализации платформы J2EE, а не разработчики самих компонентов; - доступ клиентов к компонентам EJB осуществляется через посредничество контейнера; - компоненты EJB содержат логику приложения, что соответствует архитектуре J2EE, рассмотренной нами в главе 8, и позволяет отделить уровень представления от уровня бизнес-логики, а также поддерживает разработку тонкого клиента; - компоненты EJB могут быть размещены на любом сервере приложений, удовлетворяющем спецификации J2EE; - компоненты EJB являются компонентами повторного использования, поэтому их можно, как кирпичики, использовать при построении другого приложения, а также применять в качестве образцов; - компоненты EJB поддерживают транзакции, что облегчает поддержку одновременного доступа к данным многих клиентов; - компоненты EJB облегчают доступ к базам данных и другим информационным системам; - компоненты EJB могут адаптироваться к требованиям заказчика в процессе размещения на сервере с помощью редактирования их свойств, связанных с программным окружением; - различные сервисы низкого уровня отделены от класса реализации компонента EJB, что дает возможность управлять этими сервисами в процессе компоновки и размещения; - компонент EJB может быть включен в существующий модуль EJB без изменения кода или перекомпиляции.
Спецификация Enterprise JavaBeans версии 2.0 [37] содержит как описание концепций архитектуры EJB 2.0, так и детальное рассмотрение всех типов компонентов EJB и поддерживающих их интерфейсов.
