Диаграммы кооперации
Кооперация - одно из фундаментальных понятий UML.
Предназначена для спецификации структурных аспектов взаимодействия.
Обозначает множество взаимодействующих с определенной целью объектов.
Цель кооперации – специфицировать особенности реализации отдельных наиболее значимых операций в системе.
Уровни представления кооперации
На уровне спецификации - показывает роли классов и роли ассоциаций в рассматриваемом взаимодействии.
На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.
Диаграмма кооперации уровня спецификации
Показывает роли, которые играют участвующие во взаимодействии элементы.
Изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации.
Относится к отдельному варианту использования и детализирует особенности его последующей реализации.
Диаграмма кооперации уровня примеров
Представляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций).
Связи дополняются стрелками сообщений.
Время не указывается в виде отдельного измерения.
Последовательность взаимодействий может быть определена с помощью порядковых номеров.
Пример диаграммы кооперации
Диаграмма компонентов
Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы.
Цели диаграммы компонентов:
Визуализация общей структуры исходного кода программной системы
Спецификация исполнимого варианта программной системы
Обеспечение многократного использования отдельных фрагментов программного кода
Представление концептуальной и физической схем баз данных.
Компонент:
Компонент – средство представления физических сущностей в языке UML
Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели
Для графического представления компонента может использоваться специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками.
Виды:
Компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций:
(а)динамически подключаемые библиотеки (dll)
(б) web-страницы (html),
(в) файлы справки (hlp).
2. (г) Компоненты-рабочие продукты. Как правило - это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++
3. Компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе. Они обозначаются обычным образом.
Зависимости и реализации
компонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым
отношение между различными видами компонентов.
внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента
Отношения зависимости между компонентами и задействованными в них классами.
Для обеспечения согласования логического и физического представлений модели системы.
Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом.
При необходимости такая информация отображается следующим образом:
Диаграммы развертывания
Предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime)
Представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками
Содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, ДР едина для системы в целом, поскольку должна всецело отражать особенности ее реализации.
Цели
Определить распределение компонентов системы по ее физическим узлам
Показать физические связи между всеми узлами реализации системы на этапе ее исполнения
Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.
Узел
физически существующий элемент системы, обладающий некоторым вычислительным ресурсом на основе
электронной или магнитооптической памяти и/или процессора
В последних версиях UML понятие узла расширено и может включать в себя не только вычислительные ресурсы, но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы.
Узлы могут представляться как в качестве типов (а), так и в качестве экземпляров (б).
Изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узла
Если дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значения
Если необходимо явно указать компоненты, которые размещаются на отдельном узле, то это можно сделать двумя способами:
Отношения между узлами
физические соединения между узлами и
зависимости между узлами и компонентами
Соединения
Являются разновидностью ассоциации и изображаются отрезками линий без стрелок
Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами.
Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением.
Зависимости
Это - альтернатива вложенному изображению компонентов внутри символа узла, что не всегда удобно.
Размерно-ориентированные метрики
LOC, KLOC - то количество строк в программном продукте. (KLOC – тысячи строк)
общие затраты (в человеко-месяцах - чел.-мес);
- объем программного изделия (в тысячах строк исходного кода -KLOC);
- стоимость разработки (в тыс.рублей или в долларах $);
- объем документации (в страницах документов -СД);
- ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО);
- число людей, работавших над изделием (человек);
- срок разработки (в календарных месяцах).
На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):
Достоинства размерно-ориентированных метрик:
1) широко распространены;
2) просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
1) зависимы от языка программирования;
2) требуют исходных данных, которые трудно получить на начальной стадии проекта;
3) не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные метрики
Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик.
1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.
3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы - каждый учитывается отдельно.
4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Количество функциональных указателей вычисляется по формуле
После вычисления FP на его основе формируются метрики производительности, качества и т. д.:
Область применения метода функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки
Архитектурно-значимые требования проекта
Расширяемость
Возможность добавления новых возможностей в разработанную систему
Усложнение структуры системы
Удлинение срока разработки
Определение класса возможных расширений
Роль необязательных требований.
Изменение требований
Возможность изменений требований в процессе создания системы
Те же приемы, что и на предыдущем слайде
Подходы к управлению требованиями
Формализованный подход
Подход методологии ХP.
Производительность
Выполнение тех или иных операций за установленный промежуток времени
Работа в режиме реального времени
Множественные подключения.
Минимизация числа подсистем
Минимизация взаимодействия между подсистемами.
Защищенность от НСД
Многоуровневая структура
Защита критических системных элементов на внутренних уровнях
Проверка безопасности на более высоком уровне.
Исключение ошибок - Минимизация числа подсистем, отвечающих за критичные операции.
Бесперебойная работа - Добавление избыточных элементов.
Простота
Простота понимания
Простота реализации
Простая и эффективная архитектура – затраты на создание.