Исследование компонентной модели объектов для создания программного обеспечения и оценка производительности Web-сайтов

• Автор: Со Тхей Вин
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2007
• Место защиты: Москва
• Количество страниц: 118 с. : ил.

ОГЛАВЛЕНИЕ
Введение.

1 Принципы проектирования распределенных приложений в среде i

1.1 Фундаментальные основы i

1.2 Архитектура современных приложений

1.3 Инструментальные средства и шаблон V.

1.4 Компонентный подход и технологии Интернета.

Выводы по главе.

2 Методика проектирования распределенных приложений

2.1 Основные этапы и формулировка требований.

2.2 Декомпозиция по уровням и создание компонентов.

2.3 Выбор инструментальных средств.
Выводы по главе.
3 Комбинированный подход к оценке производительности.
3.1 Анализ факторов и показателей производительности.
3.2 Моделирование и измерение производительности.
3.2.1 Аналитическое и имитационное моделирование
3.2.2 Измерение производительности
3.2.3 Имитационное моделирование и Сети Петри.
3.2.4 Построение имитационной модели сайта
3.3 Математическое моделирование на основе методов планирования эксперимента
3.3.1 Общая постановка задачи планирования экспериментов
3.3.2 Полный факторный эксперимент ПФЭ
3.3.3 Дробный факторный эксперимент ДФЭ.
Выводы по главе.
4 Планирование измерительных экспериментов и получение оценок
показателей производительности.
4.1 Составление плана тестирования производительности.
4.2 Выбор инструментов нагрузочного тестирования
4.3 Проведение и оценка результатов тестирования
4.4 Построение и анализ уравнения регрессии для оценки производительности
приложений
Выводы по главе.
Заключение.
Список литературы


Компонентной модели интересно то, как обеспечить доступ к возможностям объекта за пределами его мира, который может не соответствовать внутренней структуре объекта. Именно внешний вид объекта, т. В компонентном объекте все его свойства собраны в одну или несколько групп семантически связанных функций, где каждая группа называется интерфейсом. Например, группа функций, описывающих структурный обмен данными, легко специфицируется и, таким образом, может быть стандартным интерфейсом, обеспечивающим обмен данными. Можно также свободно определить пользовательский (custom) интерфейс для своих нужд. Независимо от того, как определяется интерфейс объекта, доступ к объекту осуществляется только через методы интерфейса. Это означаег, что компонентная модель не допускает прямой доступ к внутренним переменным объекта. В настоящее время многие операционные системы (ОС) предоставляют соответствующие службы, необходимые для построения как монолитных, так и распределенных приложений. Примером операционных систем наиболее подготовленных к использованию компонентной модели является операционные системы Windows и [,,]. Они предоставляют пользователю широкий спектр служб для поддержки компонентно-ориентированного программирования. Но даже при наличии таких служб нужно затратить значительное время для создания пользовательских приложений. Для построения и поддержки распределенных сетевых приложений операционные системы Windows и широко используют расширенную компонентную модель (СОМ+) [2,4] и концепцию DNA [,]. Распределенные приложения строятся, как правило, на основе многоуровневых архитектур. Именно наличие в операционных системах Windows и архитектуры Windows DNA позволяет упростить создание многоуровневых приложений. В основе архитектуры Windows DNA лежит тесная интеграция разработки стандартизованных приложений для работы в Интернете Windows DNA предоставляет набор правил, помогающих разработчикам делать корректный выбор вариантов технических решений при создании программного обеспечения для новых приложений. Программная реализация приложения, предоставляющего эти сервисы определяется типом системной архитектуры. В зависимости от типа системной архитекту-ры различают и три типа приложений: одноуровневые, двухуровневые и многоуровневые. В одноуровневых приложениях пользовательский интерфейс, бизнес-правила и сервисы данных поддерживаются одним уровнем. За обработку сервисов всех трех типов отвечает одно приложение или его элемент. Сами данные могут находиться в любом месте, допустим, на сетевом сервере, но функциональность, связанная с доступом к данным, является частью приложения. Пример одноуровневого приложения - Microsoft Excel, поддерживающий как пользовательский интерфейс, так и прикладную логику (бизнес логику). К прикладной логике относятся разнообразные математические функции, проверка правописания и др. На том же уровне содержатся и подпрограммы, обеспечивающие сохранение и доступ к файлам данных. Традиционные приложения для мэйнфреймов тоже являются одноуровневыми (монолитными), просто к ним обращается множество клиентских программ. В двухуровневых, приложениях компоненты, отвечающие за презентационный сервис и прикладную логику, размещаются на клиентской машине и обращаются к общему источнику данных (серверу) по сети. В таких приложениях пользовательский интерфейс и прикладная логика образуют один уровень на клиентском компьютере, а сервисы данных предоставляются отдельными приложениями (на серверах) типа СУБД SQL Server или Oracle. СУБД SQL Server и таким образом получает нужные данные. Первое приложение - это один уровень, второе - другой. Visual Basic[8,], может обращаться к данным, вызывая нужные функции из динамически подключаемой библиотеки [9,] (DLL). В этом случае, хотя пользовательский интерфейс и прикладная логика оказываются в разных местах, они все равно считаются одним уровнем (рис. Двухуровневые приложения (рис. В частности, двухуровневое приложение было бы быть удачным решением для рабочей группы, принимающей заказы на какую-либо продукцию. Рис. Рис.