UML-кунфу. Мастер-класс от невского лаоши

24 февраля 2011 года на кафедре информационных технологий Ивановского государственного химико-технологического университета состоялась лекция-семинар, посвященная практике использования UML при разработке ПО. Лекцию читал Денис Иванов, известный популяризатор UML в России. В мероприятии участвовали студенты и преподаватели кафедры. Лекция носила просветительский характер. Основная задача — продемонстрировать возможности UML, показать принципы работы при создании моделей системы, умения работы с первичной документацией.

В начале Денис пытался показать и доказать, почему собственно стоит изучать UML, каково его место в процессе разработки ПО. Кратко, идею вступительной части можно было изложить следующим образом. 1/ Разработка ПО — это процесс, состоящий из массы различных видов деятельности, вовлекающих специалистов различного уровня и профиля, порождающий разной полезности и направленности результаты этой деятельности, т.е. 2/ Процесс — сжато и грубо  — это Роли и Артефакты. 3/Роли — это способ классификации вопросов, которые возникают в процессе разработки ПО, причем это обычный, стандартный способ классификации с точки зрения того, КТО разрабатывает ПО. 4/Но, ведь, это не единственный способ классификации вопросов, могут быть и иные, и с точки зрения автора лекции, куда более прагматичные. Такой классификацией может быть классификация с точки зрения того, ЧТО следует разрабатывать. 5/Итак, главное это вопросы и, естественно, ответы на них. Кто будет отвечать на эти вопросы наиболее эффективным способом, возможно, послужит основанием для формирования той или иной методологией. 6/ Отталкиваясь именно от вопросов, Денис предлагает рассматривать всю систему с позиций трех основных вопросов: ЧТО ДЕЛАЕТ СИСТЕМА (аспект ее использования, назначения), тут дополнительными могут быть кто использует, зачем использует, почему использует и т.п.; КАК СИСТЕМА УСТРОЕНА (структурный аспект системы, ее организации); КАКИМ ОНА ДОЛЖНА ОБЛАДАТЬ ПОВЕДЕНИЕМ (функциональный, поведенческий аспект). Ортогонально этим трем группам вопросов, вопросы могут делиться по уровням абстракции. Тогда получаем некую матрицу, в чем-то подобную модели Захмана. Как можно было бы пользоваться такой матрицей? На верхнем уровне обычно локализуются вопросы аналитиков, аналитики охватывают обычно аспект использования, немного организации и возможно поведения. На средних уровнях локализуются вопросы архитектора и проектировщиков, они в большей степени охватывают структурные и поведенческие аспекты. На нижних уровнях вопросы разработчика, программиста, охватывающие детали структуры и поведения. На каждом таком уровне выстраивается своя сложная иерархия моделей: модель предметной области, модель использования, модель требований(?), аналитическая модель …, ниже архитектурные модели, модели взаимодействия, декомпозиция, проектные модели, модели алгоритмов и т.п., еще ниже модели вычислительного процесса, выраженные на языке программирования или некотором псевдокоде. Понятно, что на каждом таком уровне, описание одного и того же может происходить разными способами: на одной стороне — это естественный язык (к моменту своей профессиональной карьеры люди учатся его использовать в течение 20 и более лет), на другой стороне — это язык программирования. Естественный язык слишком многообразен и гибок, он неоднозначен, субъективен, эмоционален. Но в принципе он может выразить практически все, что требуется. Более того, одному человеку под силу сделать это. Сумел же написать Толстой свой роман «Война и мир». Но посильно это похоже единицам, за это их и называют великими. Язык программирования точен и буквален, но на нем сложно или невозможно отразить аспекты использования, да и другие важные моменты. Он детален, но из-за это и ограничен в описательной силе. 7/ Совершенно ясно, что хотелось бы иметь некий язык, общий язык, действующий на всех уровнях, обладающий достаточной описательной силой, формальный настолько, что на нем можно писать точные спецификации и писать точные инструкции трансформации в язык программирования. 8/И такой язык есть. Это UML. Пожалуй он единственный, который может охватить и перекрыть всю область разработки ПО, на практически любом уровне детализации. Говорят, что одному человеку невозможно обозреть сколь-нибудь сложную систему. А так ли это? Не является ли UML той вещью, той хрустальной сферой, которая позволит постичь вся систему целиком и одному человеку?

Вторая часть мероприятия была посвящена практическому использованию . Рассматривали уже ставшую (с моей скромной подачи) классической задачу про Cafeteria Ordering System. Денис виртуозно вел слушателей по документу об образе и границах системы и разворачивал на глазах волшебный мир UML. Под рукой мастера все проходило естественно, логично и недвусмысленно. Никакой отсебятины, ничего извне. Строго следуя описанию, мы вместе выстраивали модели системы, и не дискретно, сначала диаграмму использования, затем диаграмму классов, диаграмму состояний, нет, все сразу и одновременно. Причем знаково, все равно с какой точки начать, главное начать и двигаться в ритме исходного документа. Это канва, это направляющая. В ходе построения мы выделяли: модель использования, модель структуры, модель поведения. Уже через полчаса у нас был набросок вариантов использования (на диаграмме), приличная модель предметной области (бизнес-классы), некое структурное воплощение размещения системы, диаграмма деятельности, состояний и последовательности, реализующих один вариант использования. Тщательный контроль наименований, постоянная (пусть и ручная) синхронизация любых изменений — вот залог успеха. Уже в ходе этого небольшого времени у нас, самым естественным образом, накопилось десятка полтора вопросов. На которые мы тут же и пытались дать ответы. Сам факт неоднозначности и туманности ответа на тот или иной вопрос говорил за то, что нам требуется некий эксперт в этой области, возможно это уровень заказчика. Тут же Денис продемонстрировал и исключительную полезность диаграммы объектов. Уже в ходе ее построения возникла логическая проблема: куда привязать компот Сидорова  и два компота Соловьевой. Появился новый структурный элемент — Пункт меню. Может это и кажется вполне очевидным. Но предложенный подход помог нам выявить недостающее вначале звено, получить пропущенную информацию.

Да, не все так шоколадно. UML сложен, вероятно, начавший его изучать усердно получит отдачу не ранее, чем через 3-4 года, а может и дольше. UML сложнее языков программирования по определению.

Кстати, у нас на семинаре была также Наталья Желнова, системный аналитик из Лаборатории Касперского. Ну и в конце хочу поблагодарить Дениса за увлекательную лекцию, бескорыстную помощь в деле российского образования, и пожелать ему таланта и способностей в его нелегком деле!