Большинство классов можно отнести к определенному типу, который применительно к данному подходу называют стереотипам, например:
- Классы-сущности (классы предметной области)  
	![Условные обозначения стереотипов классов - класс-сущность](../Pictures/05_01.%20Условные%20обозначения%20стереотипов%20классов%20-%20класс-сущность.png)
- Граничные (интерфейсные) классы  
	![Условные обозначения стереотипов классов - граничный класс](../Pictures/05_02.%20Условные%20обозначения%20стереотипов%20классов%20-%20граничный%20класс.png)
- Управляющие классы  
	![Условные обозначения стереотипов классов - управляющий класс](../Pictures/05_03.%20Условные%20обозначения%20стереотипов%20классов%20-%20управляющий%20класс.png)
- Исключения  
	![Условные обозначения стереотипов классов - явное указание стереотипа](../Pictures/05_04.%20Условные%20обозначения%20стереотипов%20классов%20-%20явное%20указание%20стереотипа.png)
- И т. д.
  
**Граничные классы** обеспечивают взаимодействие между действующими лицами и внутренними элементами системы. К этому типу относят как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными средствами или программными системами. Для обнаружения граничных классов изучают пары "действующее лицо - вариант использования".  
**Управляющие классы** служат для моделирования последовательного поведения, заложенного в один или несколько вариантов использования.  
Если количество классов-кандидатов и других ресурсов велико, то их целесообразно объединить в группы - пакеты. **Пакетом** при объектном подходе называют совокупность описаний классов и других программных ресурсов, в том числе и самих пакетов. Объединение в пакеты используют только для удобства создания больших проектов, количество классов в которых велико. При этом в один пакет обычно собирают классы и другие ресурсы единого назначения.  
**Диаграмма пакетов** показывает, из каких частей состоит проектируемая программная система, и как эти части связаны друг с другом.  
**Связь** между пакетами фиксируют, если изменения в одном пакете могут повлечь за собой изменения в другом. Она определяется внешними связями классов и других ресурсов, объединенных в пакет. Возможны различные виды зависимости классов, например:
- Объекты одного класса посылают сообщения объектам другого класса
- Объекты одного класса обращаются к компонентам объектов другого
- Объекты одного класса используют объекты другого в списке параметров методов
- И т. п.
  
Самыми хорошими технологическими характеристиками отличается вариант, при мотором каждый пакет включает **интерфейс**, содержащий описание всех ресурсов данного пакета, и взаимодействие пакетов осуществляется только через этот интерфейс. Изменения реализации ресурсов пакета в этом случае не затрагивает других пакетов. И только изменения в интерфейсе могут потребовать изменения пакетов, использующих ресурсы данного пакета.  
Пакеты, с которыми связаны все пакеты программной системы, называют **глобальными**. Интерфейсы таких пакетов необходимо проектировать особенно тщательно, так как изменения в них потребуют проверки всех пакетов разрабатываемой системы.  
Обозначения нотации UML, которые допустимо использовать на диаграммах пакетов:
- Пакет  
	![Условные обозначения, применяемые на диаграммах пакетов - пакет](../Pictures/05_05.%20Условные%20обозначения,%20применяемые%20на%20диаграммах%20пакетов%20-%20пакет.png)
- Пакет с обозначением содержимого  
	![Условные обозначения, применяемые на диаграммах пакетов - пакет с обозначением содержимого](../Pictures/05_06.%20Условные%20обозначения,%20применяемые%20на%20диаграммах%20пакетов%20-%20пакет%20с%20обозначением%20содержимого.png)
- Глобальный пакет  
	![Условные обозначения, применяемые на диаграммах пакетов - глобальный пакет](../Pictures/05_07.%20Условные%20обозначения,%20применяемые%20на%20диаграммах%20пакетов%20-%20глобальный%20пакет.png)
- Зависимость классов (стрелка указывает направление вызовов)  
	![Условные обозначения, применяемые на диаграммах пакетов - зависимость классов](../Pictures/05_08.%20Условные%20обозначения,%20применяемые%20на%20диаграммах%20пакетов%20-%20зависимость%20вызовов.png)
  
Кроме указанных обозначений на диаграммах пакетов допустимо показывать обобщения, что, как правило, подразумевает наличие единого интерфейса нескольких пакетов. В этом случае фиксируется связь от пакета-подтипа к пакету-супертипу:  
![Пример обозначения обобщенных пакетов](../Pictures/05_09.%20Пример%20обозначения%20обобщенных%20пакетов.png)  
**Пример.** Разработать диаграмму пакетов системы решения комбинаторно-оптимизационных задач.  
Анализ концептуальной модели и вариантов использования позволяют выделить следующие группы классов или пакеты:
- Пользовательский интерфейс - классы, реализующие объекты интерфейса с пользователем
- Библиотека интерфейсных компонентов - классы, реализующие интерфейсные компоненты: окна, кнопки, метки и т. п.
- Объекты управления - классы, реализующие сценарии вариантов использования
- Объекты задачи - классы, реализующие объекты предметной области системы
- Интерфейс базы данных - классы, реализующие интерфейс с базой данных
- База данных
- Базовые структуры данных - классы, реализующие внутренние структуры данных, такие, как деревья, n-связные списки и т. п.
- Обработка ошибок - классы исключений, реализующие обработку нештатных ситуаций
  
Последние 2 пакета объявим глобальными, так как их элементы могут использовать классы всех пакетов.  
Определим зависимости классов и построим диаграмму пакетов:  
![Диаграмма пакетов системы решения комбинаторно-оптимизационных задач](../Pictures/05_10.%20Диаграмма%20пакетов%20системы%20решения%20комбинаторно-оптимизационных%20задач.png)