Объектно-ориентированные технологии проектирования прикладных программных систем

Объектно-ориентированные технологии проектирования прикладных программных систем
Основные понятия объектно-ориентированного подхода
Семантика (смысл программы с точки...
Жизненный цикл программной системы
Объектно-ориентированная разработка программ
Объектно-ориентированные языки программирования
Сквозной пример
Схема банковской сети
Схема банкомата (ATM)
Первая фаза жизненного цикла...

Объектная модель системы
Построение объектной модели
Пример объектной модели
Понятие подсистемы
Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением
Объектная диаграмма банковской сети и ее системного окружения
Динамическая модель системы или подсистемы
Функциональная модель подсистемы
Заключительные замечания к разделу
Объекты и классы

Пример класса и объекта этого класса
Множественное наследование
Множественное наследование
Множественное наследование от непересекающихся классов
Реализация множественного наследования с помощью вложенного простого наследования
Реализация множественного наследования путем делегирования с использованием агрегации ролей
Реализация множественного наследования с использованием простого наследования и делегирования
Связь объектов с базой данных
Объектная модель, определяющая абстрактный и конкретный классы
Тиражирование метакласса

Возможные ключи бинарных зависимостей
Возможные ключи тренарных зависимостей
Ограничения на объекты
Ограничения на связи
Общее ограничение между зависимостями
Производный атрибут
Производный объект и производная зависимость
Пример гомоморфизма
Общий случай гомоморфизма
Атрибуты объектов

Операции и методы
Другие примеры классов
Полное представление объекта в OMT
Возможные классы для системы AMT (банковское обслуживание)
Зависимости между классами (объектами)
Зависимости между классами
Дальнейшие примеры зависимостей. Обозначения
Зависимости между объектами
Более сложные зависимости между объектами
Атрибуты зависимостей

Пример атрибута зависимости
Атрибуты двух зависимостей между одним и многими
Представление зависимости в виде класса
Имена ролей, квалификаторы
Имена ролей
Использование квалификаторов
Агрегация
Агрегация
Примеры агрегации
Вторая фаза жизненного цикла - конструирование системы

Разработка архитектуры системы
Архитектура системы управления банковской сетью
Архитектура системы управления банковской сетью
Разработка объектов
Разбиение системы на модули
Пример системы с уровневой архитектурой
Типичная структура системы
Топология звезды
Выявление асинхронного параллелизма
Распределение модулей и подсистем по процессорам и задачам

Управление хранилищами данных
Управление глобальными ресурсами
Реализация управления программным обеспечением
Пограничные ситуации
Обзор архитектур прикладных систем
Система непрерывной обработки: машинная графика
Система с интерактивным интерфейсом: ATM
Совместное рассмотрение трех моделей
Сравнительный анализ объектно-ориентированных методологий разработки программных систем
Методология OMT

Методология SA/SD
Методология JSD
Методология OSA
Модель зависимостей между объектами для системы управления топкой в теплоцентрали
Поведение объекта "термостат"
Различные представления модели топки
Формальная модель топки, разработанная с помощью методологии OSA
Третья фаза жизненного цикла - реализация объектно-ориентированного проекта
Объектно-ориентированный стиль программирования
Объектно-ориентированные системы программирования

Часть объектной модели графического редактора
Реализация на языке C++
Другие объектно-ориентированные системы программирования
Не объектно-ориентированные системы программирования
Реализация классов
Порождение объектов
Вызов операций
Использование наследования
Реализация зависимостей
Шаблоны в языке C++

Реализация классов
Порождение объектов
Вызов операций
Обобщение и наследование
Обобщение (выделение суперклассов)
Другие примеры обобщения (наследования)
Абстрактные классы
Абстрактный класс
Определение классов
Подготовка словаря данных

Определение зависимостей
Неизбыточные зависимости
Уточнение атрибутов
Организация системы классов, используя наследование
Дальнейшее исследование и усовершенствование модели
Определение объектов и классов
Подготовка словаря данных
Определение зависимостей
Первая версия объектной диаграммы для банковской сети
Уточнение атрибутов

Организация системы классов с использованием наследования
Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов
Объектная диаграмма для банковской с учетом наследования
Дальнейшее усовершенствование модели
Окончательный вид объектной диаграммы для банковской сети
Интерфейсы и окружения
Объектная диаграмма банковской сети после выделения подсистемы банк
События, состояния объектов и диаграммы состояний
Пример сценария: разговор по телефону
Трасса событий для разговора по телефону

Диаграмма состояний телефонной линии
Условия
Диаграмма состояний, на которой указаны условия
Активности и действия
Указание активностей и действий на диаграмме состояний
Диаграмма состояний телефонной линии, на которой указаны активности и действия
Одновременные события. Синхронизация
Диаграмма состояний составного объекта (подсистемы)
Передача события из одного объекта другому
Синхронизация в подсистеме

Вложенные диаграммы состояний
Динамическая модель банковской сети
Нормальный сценарий для банковской сети
Сценарий для банковской сети, содержащий исключительные ситуации
Трасса событий в банковской сети
Привязка событий к объектам банковской сети
Диаграмма состояний объектов класса ATM (банкомат)
Диаграмма состояний объектов класса консорциум
Диаграмма состояний объектов класса банк
Диаграммы потоков данных

Примеры процессов

Примеры процессов
Потоки данных
Активные объекты (экторы)
Хранилища данных

Поток управления
Описание операций
Спецификация операции изменить_счет...
Ограничения
Функциональная модель банковской сети
Входные и выходные значения банковской сети
Процессы верхнего уровня в системе обслуживания банковской сети
ДПД процесса выполнить проводку в системе обслуживания банковской сети
Разработка алгоритмов, реализующих полученные операции
Сравнение рекурсивного и нерекурсивного алгоритмов вычисления n!

Оптимизация разработки
Ускорение поиска с помощью производной зависимости
Использование производных атрибутов для исключения повторных вычислений
Использование производной зависимости
Реализация управления
Псевдокод, соответствующий динамической модели ATM
Уточнение наследования классов
Реализация стека с использованием наследования(а) и делегирования(б)
Разработка зависимостей
Реализация односторонней зависимости

Реализация двусторонней зависимости
Реализация зависимости с помощью таблицы
Реализация наследования
Реализация зависимостей
Преобразование классов в структуры данных
Передача параметров методам
Размещение объектов в памяти
Реализация наследования
Выбор методов для операций
Реализация зависимостей

Объектно-ориентированное программирование на Фортране
Чем неудобны не объектно-ориентированные системы программирования


Теория систем автоматического управления

Мир технических систем разнообразен. Однако математика и физика выявили простые параллели в этом сложном мире. Можно выделить ряд энергетических доменов, которым принадлежат те или другие системы или их модули. Это электрический, магнитный, термальный, гидравлический, акустический, механический и ротационный домены. Так же существуют два фундаментальных постулата. Первый постулат гласит, что материя не может появиться ни откуда и не может исчезнуть в никуда. Второй постулат утверждает то же самое в отношении энергетического потенциала. Эти постулаты имеют частные формулировки для каждого энергетического домена. Например, для электрического домена это первый и второй законы Кирхгофа. Каждый из энергетических доменов характеризуется двумя физическими величинами первого и второго рода. В случае электрического домена - это электрические ток и напряжение соответственно. Эти парные физические величины, в каждом энергетическом домене, связаны между собой законом Ома в соответствующей формулировке (существуют: электрическое, магнитное, термальное, гидравлическое, акустическое, механическое и ротационное сопротивления). Так же следует отметить, что произведение физических величин первого и второго рода всегда есть мощность.
Представленная система параллелей позволяет понять, что математическое описание процессов движения координат систем принадлежащих разным энергетическим доменам подобно, и может быть предметом изучения одной науки, которая называется "Теория систем автоматического регулирования". Более того, в последние годы, приобретен успешный опыт применения методов этой теории при решении задач управления в экономических, финансовых и других нетехнических системах.

Система управления
Методические указания к моделированию и рекомендации к содержанию отчета

Методы оптимизации выполнения запросов в реляционных СУБД

Можно рассматривать оптимизацию и в более широком смысле. Оптимизатор запросов выбирает наиболее оптимальный способ выполнения запроса на основе известных в оптимизаторе стратегий выполнения элементарных составляющих запроса и способов композиции более сложных стратегий на основе элементарных. Тем самым, пространство поиска оптимального плана выполнения запроса ограничено заранее фиксированными элементарными стратегиями. Поэтому существенным направлением исследований, непосредственно примыкающим к вопросам оптимизации, является поиск новых, более эффективных элементарных стратегий [28-49]. В контексте реляционных СУБД это более всего относится к разработке эффективных алгоритмов выполнения реляционной операции соединения наиболее накладной реляционной операции. При этом исследуются и возможности выбора более адекватных для эффективного выполнения этой операции управляющих структур базы данных, и возможности повышения эффективности за счет распараллеливания выполнения операции на специализированной аппаратуре (здесь направления исследований примыкают к тематике машин баз данных).

Оптимизация запросов
В этой статье мы рассмотрим ряд вопросов, связанных с оптимизацией выполнения запросов в реляционных системах управления базами данных (СУБД). Мы рассматриваем проблемы оптимизации именно в контексте реляционных систем, хотя многие аспекты, связанные с оптимизацией организации данных на внешней памяти, распространяются и на не реляционные системы.

Развитие идей и приложений реляционной СУБД System R
Система управления реляционными базами данных System R разрабатывалась в исследовательской лаборатории фирмы IBM в 1975-1979 г.г. Эта работа оказала революционизирующее влияние на развитие теории и практики реляционных систем во всем мире. Именно System R практически доказала жизнеспособность реляционного подхода к управлению базами данных.

Транзакционные параллельные СУБД новая волна
Происходящие важные изменения в области компьютерных аппаратных средств, а именно, возможность сравнительно дешевого построения неограниченно горизонтально масштабируемых кластерных систем (будь то системы, основанные на использовании публичных или частных облачных инфраструктур, или кластеры, конфигурируемые традиционным образом) привели к резкой активизации исследований и разработок пригодных для использования в таких средах архитектур систем управления данных без совместного использования ресурсов (shared nothing).

OLTP в Зазеркалье
В статье, пересказ которой предлагается вашему вниманию, развивается тема, начатая авторами в статье Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными, опубликованной в начале осени 2007 г. Напомню, что в этой статье речь шла о необходимости применения новых подходов для построения систем управления данных, обеспечивающих высокую эффективность в конкретных областях использования.

Альтернативные архитектуры СУБД
Сегодня имеется совсем другая ситуация. Во-первых, современные процессоры являются очень быстрыми, так что время вычислений для многих транзакций категории OLTP измеряется микросекундами.

Тенденции в области OLTP
Как отмечалось во введении, истоки большинства популярных реляционных СУБД отслеживаются в системах, разработанных в 1970-х гг. В этих СУБД используются дисковые индексные структуры и неупорядоченные файлы, поддерживаются транзакции на основе журнала и блокировочное управление параллелизмом.

Архитектура Shore
СУБД Shore (Scalable Heterogeneous Object Repository) разрабатывалась в Висконсинском университете в начале 1990-х гг. как типизированная система персистентных объектов, заимствовавшая черты технологий файловых систем и объектно-ориентированных баз данных [CDF+94]. Система обладала многоуровневой архитектурой, которая позволяла пользователям выбрать соответствующий уровень поддержки их приложений.

Исследование производительности
Этот раздел организован следующим образом. Сначала авторы описывают свой вариант тестового набора TPC-C. В подразделе 4.2 приводятся детали аппаратной платформы #x2013; экспериментальной установки, а также описываются инструментальные средства, которые использовались для сбора данных о производительности

Следствия для будущих серверов баз данных OLTP
На основе результатов, описанных в предыдущем разделе, авторы снова обращаются к обсуждению будущего систем баз данных OLTP, начатому в разд. 2. Прежде чем перейти к детальному рассмотрению следствий полученных результатов для разработки различных подсистем СУБД, авторы приводят два общих наблюдения, вытекающих из полученных численных показателей

Литература
Конец архитектурной эпохи
Все популярные реляционные СУБД берут свое начало от системы System R, разработанной в 70-е годы прошлого века. Например, СУБД DB2 является прямой наследницей System R, и на первый выпуск этой системы оказала сильнейшее влияние подсистема RDS System R. Аналогично, MS SQL Server #x2013; это непосредственный наследник Sybase System 5, на разработку которой очень сильно повлияла System R. Наконец, в первом выпуске Oracle был напрямую реализован пользовательский интерфейс System R.

Базы данных - ЛИНТЕР - статьи

С развитием информационных технологий возрастают требования, предъявляемые к прикладным системам, а, следовательно, и к инструментам разработки. Основой любой современной прикладной программы является система управления базами данных (СУБД). Именно от СУБД во многом зависят наиболее важные параметры системы, такие как скорость, надежность, отказоустойчивость и многие другие.
В принципе основные функции СУБД (хранение данных и доступ к ним) могло бы взять на себя приложение. Однако это, как правило, не выгодно, так как усложняет процесс разработки, отладки, сопровождения и пр. В общем, как ни крути, а без системы управления базами данных современному приложению просто не обойтись.
С другой стороны возникает еще одна проблема, связанная с тем, что конечному пользователю приложения абсолютно неинтересно как и с помощью чего построена система. Следовательно, перед программистом, разрабатывающим приложение, стоит задача «сокрытия» от конечного пользователя присутствия в прикладной системе достаточно больших и сложных подсистем (порой даже более сложных, чем использующие их приложения). Эту проблему можно условно разделить на несколько подзадач.

Зачем нужна встроенная СУБД
Вопрос о необходимости встраивания СУ БД в прикладную программу достаточно спорен. Безусловно, чтобы встроить СУБД в дистрибутив приложения необходимо потратить определенное количество сил и средств. Естественно, возникает вопрос: а надо ли это? Зачем усложнять приложение? Почему бы просто не поставлять СУБД отдельно от прикладной программы?

Быстрый старт ЛИНТЕР (Windows)
ЛИНТЕР – это программный продукт, предназначенный для создания и поддержки информационных систем различного назначения на основе реляционной модели хранения данных. В состав ЛИНТЕР входят: система управления базами данных (СУБД) – сертифицированная, многоплатформенная, масштабируемая, защищенная СУБД

Новое в СУБД ЛИНТЕР 6.1
Если есть устройство, предназначенное для работы с данными, должно быть и программное обеспечение, облегчающее эту работу. Сегодня СУБД ЛИНТЕР уже реально функционирует под ОС Microsoft Windows CE. СУБД ЛИНТЕР для Windows CE, несмотря на жесткие требования, налагаемые аппаратурой КПК, является полноценным SQL-сервером и ни в чем не уступает системам, работающим на "больших" компьютерах.

СУБД ЛИНТЕР. Технический обзор
В дистрибутив ЛИНТЕР включены следующие компоненты: ядро СУБД ЛИНТЕР (собственно ядро системы, транслятор с SQL, процессор сортировки, компилятор хранимых процедур, сетевые драйверы, менеджер распределённых транзакций); программы обслуживания базы данных (генератор системной базы данных, тестер физических структур); организующие интерфейсы (инструментарий администратора, менеджер хранимых процедур со встроенным отладчиком, интерактивный SQL-интерфейс); средства разработки приложений (встроенный SQL для C/C++, исполняющая система 4GL языка Intcom, средство интерактивной разработки Лакуна)