Проектирование методов класса.
Достаточно существенную информацию о действиях, которые должны, выполняться методами класса, можно получить, анализируя диаграммы последовательности действий. Однако алгоритмы всех сколько-нибудь сложных методов необходимо проработать детально. При этом можно использовать как уже известные нотации (схемы алгоритмов и псевдокоды), так и диаграммы деятельностей.
Диаграммы деятельностей, которые предлагалось использовать в процессе уточнения спецификаций для описания вариантов использования, могут использоваться и при проектировании методов обработки сообщений, в том числе и затрагивающих несколько объектов. В последнем случае целесообразно указать вертикальными пунктирными линиями ответственности объектов соответствующих классов, что позволит проследить вызовы других объектов.
Следует помнить, что в соответствии с общими правилами процедурной декомпозиции любую деятельность можно декомпозировать и изобразить в виде диаграммы деятельности более низкого уровня.
Пример 14.8. Построить диаграмму деятельности для операции Начать () класса Решение. Анализ рис. 14.4, 14.7 – 14.8 показывает, что данная деятельность затрагивает три объекта уже детализированных классов Решение, Алгоритм и Задание. Определим зоны ответственности объектов этих классов (рис.14.21):
Рис. 14.21. Диаграмма деятельности для операции Решение Начать()
объект класса Решения организует обработку, т. е. инициализирует переменные (в том числе определяет тип Алгоритма), создает объект класса Алгоритм требуемого типа, активизируют обработку, а затем уничтожает объект класса Алгоритм;
объект класса Задание должен в ответ на запрос сообщить тип Алгоритма, предоставить данные и запомнить результаты;
объект класса Алгоритм отвечает за решение задачи.
Полностью спроектированные классы реализуют на конкретном языке программирования.
Компоновка программных компонентов.
Диаграммы компонентов применяют при проектировании физической структуры разрабатываемо программного обеспечения. Эти диаграммы показывают, как выглядит программное обеспечение на физическом уровне, т. е. из каких частей оно состоит и как эти части связаны между собой.
Диаграммы компонентов оперируют понятиями компонент и зависимость. Под компонентами при этом понимают физические заменяемые части программного обеспечения, которые соответствуют некоторому набору интерфейсов и обеспечивают их реализацию. По сути дела, это отдельные файлы различных типов: исполняемые (.ехе), текстовые, графические, таблицы баз данных и т. п., составляющие разрабатываемое программное обеспечение. Условные графические обозначения компонентов различных типов приведены на рис. 14.22.
Рис. 14.22. Условные обозначения компонентов в UML: а – программный компонент; б – файл; в – база данных; г – таблица базы данных
Зависимость между компонентами фиксируют, если один компонент содержит некоторый ресурс (модуль, объект, класс и т. д.), а другой – его использует. Качество компоновки оценивают по количеству и типу связей между компонентами, т. е. по степени независимости компонентов. На диаграмме компонентов зависимость обозначают пунктиром со стрелкой на конце.
На рис. 14.23 в качестве примера приведена диаграмма компонентов системы решения комбинаторно-оптимизационных задач.
Рис. 14.23. Диаграммы компонентов системы решения комбинаторно-оптимизационных задач