Язык UML.
Тема 3.1. Анализ требований к ПО и декомпозиция системы при объектном подходе
В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, т. е. представление разрабатываемого программного обеспечения в виде совокупности объектов, в процессе взаимодействия которых через передачу сообщений и происходит выполнение требуемых функций (рис. 6.1).
Однако при объектном подходе так же, как при структурном подходе, сразу можно выполнить декомпозицию только очень простого программного обеспечения. Поэтому на заре эпохи объектно-ориентированного программирования были предложены различные методы анализа и проектирования программного обеспечения в рамках объектного подхода, использующие различные модели и нотации. Спорить о достоинствах и недостатках этих методов и моделей можно было бесконечно. Эта ситуация получила название «войны методов».
Конец «войне методов» положило появление в 1995 г. первой версии языка UML (Unified Modeling Language - унифицированный язык моделирования - см. приложение), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области: Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».
Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: использования, логическую, реализации, процессов, развертывания (рис. 6.2).
Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя.
Логическая модель описывает ключевые абстракции программного обеспечения (классы, интерфейсы и т. п.), т. е. средства, обеспечивающие требуемую функциональность.
Модель реализации определяет реальную организацию программных модулей в среде разработки.
Модель процессов отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения.
И, наконец, модель развертывания показывает особенности размещения программных компонентов на конкретном оборудовании.
Таким образом, каждая из указанных моделей характеризует определенный аспект проектируемой системы, а все они вместе составляют относительно полную модель разрабатываемого программного обеспечения.
Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:
• диаграммы вариантов использования (см. § 6.2);
• диаграммы классов, (см. § 6.3, 7.3 и 7.4);
• диаграммы пакетов (см. § 7.1);
• диаграммы последовательностей действий (см. § 6.4 и 7.4);
• диаграммы кооперации (см. § 7.3);
• диаграммы деятельностей (см. § 6.5 и 7.4);
• диаграммы состояний объектов (см. § 7.4);
• диаграммы компонентов (см. § 7.5);
• диаграммы размещения (см. § 7.6),
Все указанные диаграммы по возможности используют единую графическую нотацию, что облегчает их понимание.
Помимо указанных диаграмм, как и при структурном подходе, спецификация обязательно включает словарь терминов, а также различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком.
UML и предлагаемая теми же авторами методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами программы Microsoft Visual Modeler и других GASE-средств. По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний используют UML при разработке программного, обеспечения с использованием объектного подхода, что и позволяет говорить о том, что сегодня UML фактически стал стандартом описания подобных разработок.