Теоретическая часть

По мере завершения анализа фокус моделирования перемещается на проектирование. В принципе анализ и проектирование могут проводиться параллельно. Методология UP рекомендует не разделять функции аналитиков и проектировщиков. За разработку артефактов (таких как прецедент) – от требований через анализ и проектирование до реализации – должна отвечать одна команда

Проектная модель содержит все то же самое, что и аналитическая модель, но все артефакты в ней проработаны более основательно и должны включать детали реализации. Проектная модель базируется на аналитической модели и может считаться просто ее улучшенной и уточненной версией.

В общем случае проектные модели образуются:

- проектными подсистемами;

- проектными классами;

- интерфейсами;

- реализациями проектных прецедентов;

- диаграммой развертывания (в первом приближении).

Объектно-ориентированное проектирование, в частности методология UP, включает два вида деятельности: проектирование архитектуры системы и проектирование элементов системы.

Проектирование архитектуры системы ведется на всех этапах ЖЦ ПО, выполняется архитектором системы и включает в себя: 1) идентификацию архитектурных решений и механизмов, не­обходимых для проектирования системы; 2) анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов; 3) формирование архитектурных уровней; 4) проектирование структуры потоков управления; 5) проектирование конфигурации системы.

Проектирование элементов системы выполняется проектировщиками и включает в себя: 1) уточнение описания вариантов использования; 2) проектирование классов; 3) проектирование баз данных (диаграммы развёртывания).

С другой стороны, технологический процесс проектирования предусматривает разработку или модификацию

- диаграмм состояний

- диаграмм деятельности.

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

Сокрытие от пользователя внутреннего устройства объектов называется инкапсуляцией. Если говорить более "научным" языком, то инкапсуляция - это защита отдельных элементов объекта, не затрагивающих существенных характеристик его как целого. Инкапсуляция нужна не только для того, чтобы создать иллюзию простоты объекта для пользователя (по словам Г. Буча).

В программировании инкапсуляция обеспечивается с помощью т. н. модификаторов видимости. С их помощью можно ограничить доступ к атрибутам и операциям объекта со стороны других объектов. Если атрибут или операция описаны с модификатором private, то доступ к ним можно получить только из операции, определенной в том же классе. Если же атрибут или операция описаны с модификатором видимости public, то к ним можно получить доступ из любой части программы.

Модификатор protected разрешает доступ только из операций этого же класса и классов, создаваемых на его основе. В языках программирования могут встречаться модификаторы видимости, ограничивающие доступ на более высоком уровне, например, к классам или их группам, однако смысл инкапсуляции от этого не изменяется. В UML атрибуты и операции с модификаторами доступа обозначаются специальными символами слева от их имен: