- •4. Объектно-ориентированное проектирование, основы uml
- •4.1 Значение моделирования
- •4.2 Принципы моделирования
- •4.3 Объектное моделирование
- •4.4 Принципы моделирования с использованием uml
- •4.5 Основные диаграммы языка uml
- •4.6 Сущности uml
- •4.7 Отношения uml
- •5. Диаграмма классов и моделирование предметной области
- •5.1 Общие сведения
- •5.2 Класс
- •5.3 Имя класса
- •5.4 Атрибуты класса
- •5.5 Операции класса
- •5.6 Отношения между классами
- •5.7 Отношение зависимости
- •5.8 Зависимость между пакетами
- •5.9 Отношение ассоциации
- •5.10 Отношение агрегации
- •5.11 Отношение композиции
- •5.12 Отношение обобщения
- •5.13 Рекомендации по построению диаграммы классов
- •6. Диаграмма состояний
- •6.1 Общие сведения
- •6.2 Автоматы
- •6.3 Состояние
- •6.4 Начальное и конечное состояния
- •6.5 Переход
- •6.6. Составное состояние и подсостояние
- •6.7. Параллельные подсостояния
- •6.8 Рекомендации
- •7 Диаграмма деятельности
- •7.1 Общие сведения
- •7.2 Состояние действия и состояние деятельности
- •7.3 Переход
- •7.4 Ветвление
- •7.5. Разделение и слияние
- •7.6 Дорожки
- •7.7. Объекты
- •7.8. Рекомендации по построению диаграмм деятельности
- •8. Моделирование взаимодействия объектов. Диаграммы последовательности и кооперации (коммуникации)
- •8.1 Диаграмма последовательности, общие сведения
- •8.2 Объекты
- •8.3 Линия жизни объекта
- •8.4 Фокус управления
- •8.5 Сообщения
- •8.6 Ветвление потока управления
- •8.7 Стереотипы сообщений
- •8.8 Временные ограничения
- •8.9 Пример построения диаграммы последовательности
- •8.10. Рекомендации по построению диаграмм последовательности
- •8.11 Общие сведения о диаграмме кооперации (коммуникации)
- •8.12 Кооперация
- •8.13 Объекты
- •8.14 Мультиобъекты
- •8.15. Активные объекты
5.13 Рекомендации по построению диаграммы классов
Процесс разработки диаграммы классов занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность создаваемой информационной системы. Как показывает практика ООП, каждый программист в своей работе стремится в той или иной степени использовать уже накопленный личный опыт при разработке новых проектов, чтобы иметь возможность использовать не только проверенные фрагменты программного кода, но и отдельные компоненты в целом (библиотеки компонентов). Такой стереотипный подход позволяет существенно сократить сроки реализации проекта, однако приемлем лишь в том случае, когда новый проект концептуально и технологически не слишком отличается от предыдущих.
При определении классов, атрибутов, операций и задании их имен и типов перед отечественными разработчиками всегда встает невольный вопрос: какой из языков использовать в качестве естественного, русский или английский? С одной стороны, использование родного языка для описания модели является наиболее естественным способом ее представления и в наибольшей степени отражает коммуникативную функцию модели системы. С другой стороны, разработка модели является одним из этапов разработки соответствующей системы, а применение инструментальных средств для ее реализации в абсолютном большинстве случаев требует использования англоязычных терминов. Именно поэтому возникает характерная неоднозначность, с которой, по-видимому, совершенно незнакома англоязычная аудитория. Наиболее целесообразно придерживаться следующих рекомендаций. При построении диаграммы прецедентов, являющейся наиболее общей концептуальной моделью проектируемой системы, применение русскоязычных терминов является не только оправданным с точки зрения описания структуры предметной области, но и эффективным с точки зрения коммуникативного взаимодействия с заказчиком и пользователями. При построении остальных типов диаграмм следует придерживаться разумного компромисса.
В частности, на начальных этапах разработки диаграмм целесообразность использования русскоязычных терминов вполне очевидна и оправдана. Однако, по мере готовности графической модели для реализации в виде программной системы и передачи ее для дальнейшей работы программистам, акцент может смещаться в сторону использования англоязычных терминов, которые в той или иной степени отражают особенности языка программирования, на котором предполагается реализация данной модели.
Более того, использование CASE-инструментариев для автоматизации ООАП, чаще всего, накладывает свои собственные требования на язык спецификации моделей. Именно по этой причине большинство примеров в литературе даются в англоязычном представлении, а при их переводе на русский может быть утрачена не только точность формулировок, но и семантика соответствующих понятий.
После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях. С одной стороны, если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и компонентов. Однако для сложных динамических систем поведение представляет важнейший аспект их функционирования. Детализация поведения осуществляется последовательно при разработке диаграмм состояний, последовательности и деятельности.