- •Технология проектирования программных систем методические указания к изучению курса с элементами кредитно - модульной системы организации учебного процесса
- •Содержание лекционных занятий
- •Темы лабораторных работ
- •Оценка успешности в баллах при полном выполнении условий и графика учебного процесса
- •Распределение баллов по смысловыми модулями для определения оценки по результатам изучения учебной дисциплины
- •Шкала оценивания
- •Лабораторная работа № 1
- •Краткие теоретические сведения:
- •Моделирование взаимодействий
- •Взаимодействия
- •Лабораторная работа № 2
- •Краткие теоретические сведения:
- •Выявление требований
- •Прототипирование
- •Системные сервисы
- •Системные ограничения
- •Проектные вопросы
- •Приложения
- •Спецификации состояний
- •Моделирование классов
- •Выявление классов
- •Подход на основе использования именных групп
- •Подход на основе использования общих шаблонов для классов
- •Подход на основе использования прецедентов
- •Комплексный подход
- •Некоторые правила выявления классов
- •Лабораторная работа № 3
- •Краткие теоретические сведения
- •Архитектура программного обеспечения
- •Распределенная архитектура
- •Трехзвенная архитектура
- •Программирование баз данных
- •Взаимодействие "приложение-база данных"
- •Стратегия повторного использования
- •Компоненты
- •Развертывание
- •Проект развертывания
- •Модели данных
- •Модель объектной базы данных
- •Объектно-реляционная модель базы данных
- •Элементарные типы модели рбд
- •Реляционные таблицы
- •Лабораторная работа № 4
- •Краткие теоретические сведения
- •Связность и увязка классов
- •Виды увязки классов
- •Закон Деметра
- •Методы открытия доступа и бессмысленные классы
- •Проектирование клиент-серверных кооперативных взаимодействий
- •Хранимые процедуры
- •Триггеры
- •Проектирование транзакций
- •Пессимистическое управление параллельностью
- •Точка сохранения
- •Триггерный откат
- •Тестирование баз данных
- •Тестирование авторизации
- •Тестирование других ограничений
Моделирование взаимодействий
Моделирование взаимодействий (interaction modeling) охватывает вопросы взаимодействия между объектами, необходимыми для выполнения прецедента. Модели взаимодействия используются на более развитых стадиях анализа требований, когда становится известной модель классов, так что ссылки на объекты опираются на модель классов.
Приведенное выше наблюдение служит опорой для установления основного различия между моделированием видов деятельности и моделированием взаимодействий. Модели обоих типов описывают поведение одного прецедента (как правило). Однако, моделирование видов деятельности осуществляется на более высоком уровне абстракции оно отражает последовательность событий вне связи событий с объектами. Моделирование взаимодействий отображает последовательность событий (сообщений) в их связи с действующими в кооперации объектами.
Диаграммы взаимодействий разделяются на два вида - диаграммы последовательностей и диаграммы кооперации. Они могут использоваться как взаимозаменяемые, и, конечно, многие CASE-средства поддерживают автоматическое преобразование одной модели в другую. Разница между моделями заключается в акцентах. Модели последовательностей концентрируются на временных последовательностях событий, а в моделях кооперации основное внимание уделяется отношениям между объектами.
Взаимодействия
Взаимодействие (interaction) представляет собой набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты ъ соответствии с установленными между ними связями (последние могут быть постоянными или временными (Диаграмма последовательностей представляется двумерным графом. Объекты располагаются по горизонтали. Последовательности сообщений располагаются сверху вниз по вертикали. Каждая вертикальная линия называется линией жизни (lifeline) объекта.
Стрелки представляют каждое сообщение, направляемое от вызывающего объекта (отправителя) к операции (методу) вызываемого объекта (получателя). Для каждого сообщения, как минимум, указывается его имя. Кроме того, для сообщения могут быть указаны фактические аргументы сообщения и другая управляющая информация. Фактические аргументы соответствуют формальным аргументам метода объекта-получателя.
Фактические аргументы могут быть входными аргументами (передаются от отправителя к получателю) или выходными аргументами (передаются от получателя назад к отправителю). Входные аргументы могут быть обозначены ключевым словом in (если ключевое слово отсутствует, то предполагается, что аргумент - входной). Выходные аргументы обозначаются ключевым словом out. Допускаются также аргументы типа inout ("входные-выходные"), однако, для объектно-ориентированного подхода они не характерны. Сообщение getCourseName, отправленное объекту, обозначенному переменной crs_ref, имеет один выходной аргумент и ни одного входного:
crs_ref.getCourseName(out crs_name)
Показывать на диаграмме возврат управления от объекта-получателя объекту-отправителю не обязательно. Стрелка, указывающая на объект-получатель, предполагает автоматический возврат управления отправителю. Получатель знает уникальный идентификатор объекта (OID) отправителя.
Сообщение может быть отправлено коллекции (collection) объектов (коллекция может быть набором, списком, массивом объектов и т.д.). Довольно частой является ситуация, когда вызывающий объект связан с несколькими объектами-получателями (поскольку кратность ассоциации указана как "один ко многим" или "многие ко многим"). Итеративный маркер- звездочка перед обозначением сообщения - указывает на процесс итерации сообщения по всей коллекции.
Задание:
Выполнить планирование разработки системы. Выполнить анализ требований и моделирования.
Предоставить отчет, содержащий результаты проведенного планирования и результаты моделирования системы.
Контрольные вопросы:
1. Реинжиниринг бизнес - процессов (BPR) проводит ясное различие между бизнес - процессом и бизнес - функцией. В чем заключается это различие? Приведите пример бизнес - процесса, который разорван по горизонтали по всей организации.
2. Почему понимание метода ISA (архитектура информационной системы) важно для системной разработки?
3. Объясните разницу между этапами определения требований и разработки спецификации.
4. Объясните взаимосвязь двух этапов проектирования (архитектурное проектирование и детализированное проектирование) с первыми двумя этапами жизненного цикла - этапом определения требований и этапом разработки спецификации.
5. Каковы основные причины сдвига от структурного подхода к проектированию объектно - ориентированном?
