Нужно ли формально моделировать?

lnew — Fri, 21 Jan 2011 19:51:04 GMT

В своем блоге на сайте UML2.ru (http://blogs.uml2.ru/post/Modelirovanie-arhitektury-predpriyatiya-yazyk-UPIA-karkasy#comments) я разместил свое обращение, подобное тому, которое представлено выше. Действительно ведь не вдохновляет, когда работаешь "на корзину".

Получены два комментария. Их можно посмотреть по ссылке. Здесь я попытаюсь ответить на комментарий пользователя maksiq и обосновать свою позицию.

"Стоит ли писать?" Стоит! Большое спасибо!

Первое утверждение: Никакой стандарт не гарантирует успеха. Успеха могут добиться только грамотные люди. (Увы, могут и не добиться!).

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

Утверждение второе: Сегодня серьезный проект, если он не документирован (процесс разработки и целевая система), обречен на неудачу.

Уже при группе в 5 человек недокументированная неуправляемая разработка превращается в хаос!

Утверждение третье: Документирование - очень трудоемкая задача.

Настолько трудоемкая, что ее просто не выполняют, что приводит к плачевным результатам: то, что сделали, не отвечает ожиданиям. Требуются доделки, переделки, тратятся время и деньги.

Что пропагандируют эти циклы статей, публикуемые на сайте "Я - аналитик"?

Главная цель - это не описание UPIA и TOGAF (хотя я считаю это важным).
Я пытаюсь поделиться своим опытом выполнения "самодокументирующихся" проектов с использованием UML.

К формализму UML вопросы есть?
Русский язык тоже формальный (хотя в нем есть т.н. "неформальная лексика", ну ... Вы знаете!).
Да, недостаточно грамотный специалист может не суметь что-то сказать на UML, и будет употреблять неформальную лексику. Я участвовал во множестве проектов, и пока не встречался с тем, чтобы не суметь выразить на UML концепцию, связанную с разработкой ПО.

Мой опыт, которым я делюсь на курсах по моделированию и при выполнении проектов по внедрению RUP, в общем, состоит в следующем:
1. Все, что можно представить в виде модели, представляется в виде модели. Вы считаете, что документировать в виде текста быстрее? Если инструмент хороший, вряд ли!
2. Каждый элемент документируется в момент создания (описание - одна фраза, редко - две). Вы думаете - это затраты времени? Нет! Когда вы создаете элемент (если Вы не перерисовываете с бумажки, а я верю, что это не так), Вы обдумываете роль элемента, связи и т.д. Время, затрачиваемое на ввод описания существенно меньше времени обдумывания роли элемента, особенно, если не "вылизывать" формулировки. А зачем их сейчас "вылизывать"? Увидим в контексте в общем документе - исправим, что надо (в модели, и перегенерируем).
3. Генерируется нужный документ (отчет) из соответствующего шаблона.

"Бесплатный сыр бывает только в мышеловке!".

Трудозатраты есть, но другие, и существенно меньшего объема.
Я использую инструменты IBM Rational. Для документирования модели, допустим, спецификации прецедента по RUP (очень похоже на описание по Коберну) нужны Rational Software Architect и Rational SoDA (или BIRT).
Чтобы не переделывать шаблон SoDA для каждой спецификации, желательно определить стандартную структуру модели в организации: где что лежит. Думаю, это полезно не только для отчетов, особенно когда над моделью работают больше одного человека.
Под структуру делается стандартный шаблон, который вставляет в отчет заголовки, элементы (названия, описания, атрибуты, описания атрибутов и т.д., все, что Вы хотите туда вставить), диаграммы деятельности. Этот шаблон Вы будете использовать для генерации всех спецификаций прецедентов, пока будет соблюдаться принятая структура модели.
Вам нужно напечатать спецификацию? Берете шаблон, правите одну строчку (адрес прецедента в модели) и нажимаете Generate. Через некоторое время Вы получаете красивый документ Word, который не стыдно показать любому заказчику, а главное - тестеру и проектировщику! Но они и в модели посмотреть могут!

Вернемся к формальному моделированию.

Моделирование заинтересованных лиц позволяет сохранять информацию о них не в блокноте, не в Worde или Excele, а в модели. Ту же информацию, которую раньше сохраняли в голове. Какие тут ограничения? В моей модели нет нужных атрибутов для описанию нюансов? Добавьте атрибуты, и нет проблем! Изменились сами заинтересованные лица? Их не один, а три?
Преимущества:
1. (возможно, только для меня) Когда я их вижу на диаграмме, я вижу общую картину. Когда я "кликаю" по "человечку" - я рассматриваю и думаю о подробностях.
2. На диаграмме можно установить связь Заинтересованного лице (класса или экземпляра) с модельными элементами, на которые он может оказать влияние; знание, для кого что делаем поможет в разработке.
3. Документирование по стандартному шаблону.

С моделированием стратегии предприятия все то же самое. Формально, при разработке ПО бизнес моделирование, а тем более - знание стратегии предприятия, считается не обязательным. Но если уж дело дошло до стратегии, то Вы все равно используете стандартные понятия Видения, Миссии и т.д. Можно все это описать в виде текста. Мне такой текст не написать: что-нибудь забуду. А в тех же терминах нарисовать на одной страничке, с детализацией некоторых элементов на других страничках - вполне доступно. В результате тот же текстовый документ, который напишете Вы. Только с картинками. Какие формальные ограничения?

Другое дело, что я неправильно могу понять стратегию, которую рассказывает мне ЗЛ "Владелец бизнеса". Так тут никакое моделирование не поможет!!!

Не верите? присылайте материалы, я Вам сделаю отчет (если не слишком много). Или, если хотите, свой (из существующих) пример подберу!

Здравствуйте!

lnew — Sat, 15 Jan 2011 19:58:25 GMT

Дорогие друзья - читатели!
Пишите, пожалуйста, ваши отзывы и замечания на материалы сайта.

С момента основания сайт посетило достаточно много народу, но ни в гостевой книге, ни на форуме я не получил ни одного отзыва! Может быть, я просто графоман, и мои опусы никому не нужны? Тогда я не буду тратить время!

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

Например, материал "Расширение моделирования в TOGAF с использованием UML и здравого смысла" рассчитан на людей, знакомых с TOGAF. Но есть, увы и незнакомые, но которые хотят познакомиться!

Пишите, я откорректирую свою политику, если буду знать потребности аудитории!

Спасибо!

Я - Аналитик

Нужно ли формально моделировать?

Здравствуйте!