Смерть от UML

Лечить надо причину болезни, а не следствие ее.

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

Перед тем как начать описание UML лихорадки и соответствующих ей симптомов, важно отметить то, что сам по себе UML не является непосредственной причиной описываемого недуга. UML – это невинная жертва плохой постановки процесса, неправильных регламентов или некомпетентности его пользователей. Тем не менее, UML, опять же не по своей вине, усиливает симптомы болезни в первую очередь из-за созданной вокруг него «божественной» ауры. Зачастую людям кажется, что даже самая нелепая задача приобретает серьезный смысл, если она описана в терминах UML.

Данная статья основана на том факте, что наличие и серьезность многих «программных» заболеваний в программных продуктах часто может быть оценено теми же рамками, что и UML: слишком много, слишком детализировано, слишком функционально. Некоторые читатели могут сразу предположить, что точно так же можно думать и о любом другом методе моделирования. И в чем-то они будут правы, но ни одна технология кроме UML не смогла так быстро и глубоко проникнуть в жизненный цикл разработки программного обеспечения.

МЕТАЛИХОРАДКИ

Широкое исследование показало, что все типы UML лихорадки могут быть разделена на 4 определенные группы, называемые «металихорадкамии». Их признанные научные названия: металихорадка «помешательства», металихорадка «нервозности», металихорадка «розовых очков» и металихорадка «производства» (смотри рисунок 1). Каждой из групп посвящен отдельный раздел статьи.

Рисунок 1

Рисунок 1. Лихорадка UML.

МетаЛихорадка помешательства

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

Рисунок 2

Рисунок 2. Металихорадка помешательства

Лихорадка утопии. Субъекты, пораженные этой лихорадкой, искренне верят, что UML является радикально новой технологией, имеющей божественные истоки. Зараженные часто повторяют что-то вроде «Где бы мы были сейчас без UML?» или «Только подумайте, куда мы могли бы продвинуться, если бы у нас был UML 20 лет назад?». Другие симптомы болезни это, к примеру, амнезия, когда люди напрочь забывают о том, что большинство программных систем успешно создавались и без UML.

Спросив стоящего перед Вами инженера, каковы истоки UML или какой методологией пользовались до UML для создания комплексных систем, по данному ответу можно с легкостью определить будущего носителя вируса лихорадки утопии.

Слепая лихорадка. Характеризуется потерей рассудительности, и способности здраво оценивать подходит ли данная технология или процесс для решения собственных задач. Жертвы слепой лихорадки склонны принимать то, что делали люди для решения других задач, даже если это мало подходит к их собственным.

Как было замечено, зараженные инженеры вживляют семантику конечных автоматов во все создаваемые ими модели, просто потому что это подразумевает использование передовых инженерных технологий, которые конвертируют UML диаграммы в код. Другой наблюдаемый синдром заключается в использовании готовых процессов или «коробочных решений» для собственных задач, вместо того чтобы адаптировать или приспосабливать их под свои нужды. Побочным эффектом слепой лихорадки является потраченные на производство никому не нужных объектов время и деньги.

Лихорадка абракадабра. Наиболее распространенный симптом – слабое ощущение реальности. У пораженных этой лихорадкой менеджеров начинается обильное слюнотечение, когда они слышат о технологиях, автоматически создающих программный код из UML диаграмм. Мысли о супер быстром способе улучшения кода вызывает такие симптомы, как расширение зрачков и щебетание про большие новогодние бонусы. Можно себе представить дальнейшее развитие лихорадки абракадабры, когда управляющие требуют развивать целые системы только с помощью MDA.

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

Лихорадка 42. Как и в книге Дугласа Адамса «Автостопом по галактике», 42 – это ответ на любой вопрос жизни вселенной и вообще, так и UML – ответ на все вопросы. Инженеры думают, что все проблемы разработки программного обеспечения можно решить с помощью UML диаграмм. Хотя лихорадка 42 и лихорадка абракадабры очень похожи и часто влияют на несчастных одинаково, существуют некоторые различия в симптоматике заболеваний. Если для лихорадки 42 UML – это решение всех проблем, то зараженные лихорадкой абракадабра находят спасение в виде UML лишь для тех вопросов, на которые сами не знают ответа.

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

Часто встречается поведение, когда аналитики создают тома диаграмм вариантов использования, но забывают про тот факт, что важнейшей процедурой создания диаграмм вариантов использования является создание сопровождающего их текста. UML диаграммы взаимодействия с сообщениями типа «спасти Африку от голода» не представляют никакого интереса для любого участника проекта. Специалисты по моделированию диаграмм вариантов использования, пораженные лихорадкой руководителя, часто обвиняют в непрофессионализме разработчиков, если они не могут строить системы исходя из многоуровневых UML диаграмм.

Лихорадка гравитации. Заставляет зараженных верить в то, что ускорение свободного падения придает вес их UML моделям. Незнакомые со вторым законом Ньютона о движении считают, что скорость исполнения работ по созданию ПО прямо пропорциональна количеству нарисованных в течение проекта UML диаграмм.

Исследование показало, что ИТ менеджеры наиболее подвержены этому заболеванию. Когда они видят разработчиков увлеченно строчащих то, что менеджерам абсолютно непонятно, они заставляют их рисовать многотомные UML диаграммы. Самое обидное, что для них это так и остается картинками.

Лихорадку гравитации часто путают с лихорадкой управляющего, но разница в симптомах существует: в первом случае людей интересует исключительно размер диаграммы, во втором – ее содержание.

МЕТАЛИХОРАДКА НЕРВОЗНОСТИ

Болезни, входящие в эту группу UML лихорадок, в первую очередь влияют на центральную нервную систему человека.

Рисунок 3

Рисунок 3. Металихорадка нервозности

Лихорадка перста указующего. Эта лихорадка, на удивление, поражает тех, кто уже потихоньку начал восстанавливаться от более серьезных видов UML эйфории, описанных ранее. Стадия болезни напрямую зависит от количества ранее потраченных денег и времени на разработку UML диаграмм. Синдром – обвинение UML в затормаживании всех процессов разработки ПО или предъявлении языку обвинений в чрезмерной экспрессивности и детальности: зачем нужны диаграммы низших уровней?!

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

Лихорадка отчаяния. Обширные клинические исследования выявили высокий коэффициент корреляции между лихорадкой отчаяния и скользящими сроками проекта, низкой продуктивностью, низким качеством продукции и другим и проектными «травмами». Симптом – сплющенные уши в результате двадцатичетырехчасовых переговоров с продавцами в поисках продукции, спасающей от всех проектных бед.

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

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

ПРОИЗВОДСТВЕННАЯ МЕТАЛИХОРАДКА

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

Рисунок 4

Рисунок 4. Производственная металихорадка

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

Лечение – заставлять жертв болезни создавать только необходимые диаграммы и вовлекать клиента с целью выяснения, удовлетворены ли были его потребности. В конце курса лечения пациенты обнаруживают, что UML диаграммы не являются первостепенными в процессе выполнения проекта.

Лихорадка движения по кругу. Первый симптом – стремление жертвы использовать диаграммы вариантов использования для получения подробной функциональной декомпозиции предметной области. Название пошло от склонности изображать диаграммы вариантов использования так, как показано на рисунке 5. Казалось бы, благое намерение провести объектно-ориентированный анализ проблемы, приводит к дроблению проблемы на все более мелкие кусочки вследствие неуправляемости жертвы. В результате вместо упрощения моделей люди занимаются все большим их усложнением, что сильно затрудняет их понимание.

Рисунок 5

Рисунок 5.Диаграмма вариантов использования

Болезнь сильно распространена, поэтому стоит следить за инженерами с самого начала проекта.

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

Лихорадка кругосветного путешествия. Симптомы ужасны – жертвы оказываются не в состоянии использовать абстракции для управления сложными процессами разработки ПО. Не могут отличить UML модель от модели реализации, созданной инженером из детализированного программного кода. Системные архитекторы, пораженные лихорадкой кругосветного путешествия, ответственные за проведение анализа часто выдают отрицательное заключение, если им предоставляют модель, созданную на основе существующей программной реализации. Чаще поражает инженеров, больше работающих с технологиями, чем способными быть системными архитекторами.

МЕТАЛИХОРАДКА РОЗОВЫХ ОЧКОВ

Обычно этим лихорадкам подвержены менеджеры полные глупого и слепого оптимизма.

Рисунок 6

Рисунок 6. Металихорадка розовых очков

Лихорадка неудачника. Заставляет жертв поверить, что весь состав участников проекта взаимозаменяем независимо от опыта, квалификации или образования. Таким образом, все обязаны уметь читать UML диаграммы. Самое страшное начинается когда люди, страдающие этим заболеванием, попадают из методологов в практики.

Лихорадка одноглазого. «В Стране Слепых и кривой – король». Эта пословица воплощается в реальность, когда несведущих менеджеров ставят на управляющую должность в проекте по разработке программного обеспечения. Этой лихорадке часто подвергаются менеджеры, не разбирающиеся в технологиях настолько, чтобы правильно судить о них. Самый опасный побочный эффект – когда слепая организация следует наставлениям одноглазого и все процессы приспосабливаются под его требования.

Лихорадка оборотня. Жертвы этой лихорадки отсылают людей к инструментам дизайна и языку синтаксиса классов с надеждой на то, что они вернуться экспертами в этой области. Способность повторить последовательность нажатий «Файл – Новый – Диаграмма классов» является показателем качества разработчика ПО. Симптомы этой лихорадки особенно раздражают, когда знания о классах и инструментарии языка значительно отличаются от того как они будут использоваться в реальной программе. «Человека встречают по одежке, а Разработчика встречают по UML».

БОРЬБА

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

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

Результат будет более убедительным, если компания проведет самоанализ влияния лихорадки на сотрудников и на процессы разработки ПО. Как ранее было отмечено, некоторые организации так глубоко погружаются в море моделирования, что гигантские диаграммы для них становятся важнее непосредственно разработки ПО. В таких случаях независимая экспертная помощь извне – единственный способ инициировать процесс выздоровления компании. Менеджмент должен регулярно проверять персонал, занимающий ключевые позиции, на наличие признаков лихорадки, т.к. зачастую процесс заражения проходит плавно и незаметно. Нераспознанные симптомы заболевания могут привести к распространению болезни в масштабах эпидемии, что будет являться разрушительным для компании.

Систематическая диагностика UML лихорадки возможна только в случае, если ее симптомы перечислены, охарактеризованы и оглашены.Тем не менее, диагностика является лишь первой ступенью к выздоровлению компании. Если зараженной организации нужно избавиться от истощающего эффекта заболевания, ей требуется в первую очередь определить и соблюдать правильный режим работы. Путь к выздоровлению часто очень непрост. Благоприятно настроенные индивидуумы, пытающиеся вылечить компании, часто сталкиваются с язвительными замечаниями, беспочвенными доводами и открытой неприязнью со стороны руководства, если лихорадка поднялась высоко по иерархической лестнице организации. Борьба против UML лихорадки может быть выиграна только, если сотрудники понимают опасность болезни и осознано встают на путь выздоровления.

 Первоисточник: “Death by UML Fever” by ALEX E. BELL, THE BOEING COMPANY.