Модельно-алгоритмическая поддержка анализа транзакционной надежности в системах обработки информации и управления

• Автор: Гаврилов, Евгений Сергеевич
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Красноярск
• Количество страниц: 170 с. : ил.

СОДЕРЖАНИЕ
Введение

1 .Моделирование программной архитектуры и транзакций на

архитектурном уровне.

1.1 Моделирование программной архитектуры

1.1.1 Определение программной архитектуры

1.1.2 Цели использования программной архитектуры.

1.1.3 Связь внешней среды и программной архитектуры

1.1.4 Структуры программных средств

1.1.5 Процесс разработки и программная архитектура.

1.1.6 Связанные направления

1.2 Моделирование транзакций на архитектурном уровне проектирования программных средств.
1.2.1 Транзакционная структура ТС
1.2.2 Описание транзакционной структуры на иМЬ.
1.3 Выводы.
2. Транзакции в АСУИО
2.1 Транзакции и целостность баз данных
2.1.1 Пример нарушения целостности базы
2.1.2 Понятие транзакции.
2.1.3 Ограничения целостности
2.1.4 Классификация ограничений целостности
2.1.5 Классификация ограничений целостности по способам реализации.
2.1.6 Классификация ограничений целостности по времени проверки.
2.1.7 Классификация ограничений целостности по области действия
2.1.8 Ограничения домена.
2.1.9 Ограничения атрибута.
2.1. Ограничения кортежа.
2.1. Ограничения отношения.
2.1. Ограничения базы данных.
2.1. Реализация декларативных ограничений целостности средствами БРЬ.
2.1. Синтаксис операторов 8СЬ, использующих ограничения
2.2 Транзакции и восстановление данных
2.2.1 Индивидуальный откат транзакции1
2.2.2 Восстановление после мягкого сбоя.
2.2.3 Восстановление после жесткого сбоя
2.3 Выводы
3. Многоверсионность данных и управление параллельными транзакциями
ф 3.1 Транзакции и параллелизм
3.2 Временные метки.
3.3 Многоверсионный вариант двухфазного протокола синхронизации.
3.4 Многоверсионный протокол для транзакций,
не изменяющих данные
3.5 МУБОпланировщики.
3.6 Проблемы реализации версионных алгоритмов.
3.7 Выводы
4. Модель оценки транзакционной наджности программного обеспечения вАСУИО
4.1 Описание модели оценки транзакционной наджности
4.2 Программная реализация системы модельноалгоритмической поддержки анализа транзакционной
надежности программных средств
4.3 Примеры решения задач и анализ результатов
4.4 Выводы
Заключение
Список использованной литературы


При этом не рассматриваются выполняемые компонентами действия (вычисления), которые не характеризуют их взаимодействие. Любое программное средство, являясь системой, имеет архитектуру, так как может быть представлено как совокупность (композиция) компонентов и отношений между ними. Из определения также следует, что поведение компонента входит в состав архитектуры, поскольку оно обозримо с точки зрения остальных компонентов и позволяет им взаимодействовать друг с другом. И, наконец, из определения вытекает, что программное средство может иметь более чем одну структуру. Действительно, распределенная информационная система как объект моделирования, с одной стороны, может быть рассмотрена как совокупность программных модулей, а с другой стороны, как совокупность параллельно выполняющихся процессов или потоков управления. Свойство множественности системного (модельного) описания объекта в зависимости от целей этого описания является определяющим при моделировании программной архитектуры. В соответствии с возникающими потребностями могут быть введены различные структуры, требуемые для моделирования интересующих свойств (характеристик) программных средств. Применительно к множественности структур правомерна аналогия с человеческим организмом. Для него, в зависимости от предмета исследования, также определяют различные структуры, например, структуру кровеносной системы, структуру системы пищеварения, структуру нервной системы и т. Наличие тех или иных структур, являющихся составной частью программной архитектуры, обусловлено целями, которые исследователи и/или разработчики планируют достичь в процессе ее моделирования. Описание нелсй. Обобщая [, , , ], можно утверждать, что использование программной архитектуры позволяет достигнуть следующих целей при разработке программных средств. Программная архитектура обеспечивает достижение понимания программного продукта, коммуникации на высоком уровне проектирования, коммуникации между заинтересованными лицами. Для различных групп заинтересованных лиц, каждая из которых имеет свои интересы в проекте, чрезвычайно важно достигнуть понимания программного средства, осуществить коммуникации в рамках единого языка общения. Например, будущих пользователей интересует полнота и практическая значимость требований, которым будет удовлетворять система. Заказчика (покупателя) волнует возможность реализации проекта за приемлемое время, в рамках определенного бюджета. В случае создания больших (крупномасштабных) программных средств каждому разработчику сложно достигнуть детального понимания всех программных компонентов системы, и поэтому его интересует, как минимум, понимание системы в целом. Программная архитектура обеспечивает достижение высокоуровневого понимания программного средства различными заинтересованными лицами (представителями со стороны заказчика, менеджерами высшего звена руководства, членами кросс-функциональной команды (маркетинг, качество и др. Программная архитектура воплощает получаемые на самых ранних этапах разработки решения, определяющие успех проекта и являющиеся базисом для принятия других проектных решений. Эффективное управление проектом (распределение работы). Программная архитектура предусматривает декомпозицию системы на относительно независимые (слабо связанные) подсистемы/компоненты, для каждой из которых явно определены обеспечиваемая ей функциональность и интерфейсы взаимодействия с другими подсистемами/компонентами. Декомпозиция системы на слабо связанные составляющие позволяет организовать параллельное выполнение работ по созданию различных подсистем/компонентов, делает возможным рассмотрение деятельности по их реализации как самостоятельные задания (work tasks). При этом команды разработчиков взаимодействуют друг с другом в терминах интерфейсов, поддерживаемых основными компонентами. Это увеличивает вероятность правильного формирования организационной структуры (организационной архитектуры) проекта. Несмотря на то, что не только программная архитектура определяет организационную структуру, последняя часто является отражением программной архитектуры.