Здравствуйте, AlexanderLozhechkin, Вы писали:
SR>>+10
SR>>Приятно слышать (и читать) практиков !!!
AL>Сергей, расскажите, плз, о своем реальном и практическом опыте использования UML в реальных, доведенных до конца, проектах?
Александр , приветствую!
Извини, конечно, за предыдущий пост, но заголовок треда "UML и\или DSL", и последующий опрос, где вопросы, в принципе вполне адекватные до "точки", а далее "маркетинговый спам"
, цитирую
"Для создания высокоуровневых диаграмм без привязки к коду" — вполне нормальная формулировка, но далее
"По мере изменения кода диаграммы устаревают, т.к. их лень обновлять" — то что кому-то лень, проблема вовсе не UML, а инструментальной поддержки или организации процесса. И как я могу голосовать за такой ответ? — да я использую UML создания ..., но мне не лень.
Вообще Сергей Орлик высказался (как и часто это он делает) как говорится в точку.
Что касается реальных проектов, вот некоторые из них: ИС учета дорожного хозяйства «ДОДД Спб», ЕУС «ЗАО Петербургрегионгаз», ЕУС КЭП Спб, ГИС "Водоканал" итд. Во всех проектах по крайней мере документ "Концепция и логика" полностью сопровождался диаграммами, причем ни разу не слышал от заказчика каких либо нареканий насчет недоступности представления информации. Задания разработчикам также в основном представлялись с сопутствующими диаграммами.
Особо хотелось подчеркнуть пару проектов ИСУП МЭРТ, СЭДО МЭРТ, Обмен СЭДО МЭРТ и РФФИ , проекты выполнены на платформе DocsVision (узнаешь
), так вот учитывая "ограничения" платформы в средствах моделирования и проектирования, без применения UML просто не реально было что-либо описать, спроектировать, а самое главное донести до разработчиков постановку задачи
AL>Если можно, с конкретикой:
AL>1. Какие создавались диаграммы?
UseCase, Activity, State, Sequence,Class (правда обычно при моделировании, при проектировании редко и в основном на бумаге для коммуникации между членами команды.
Могу сказать какие не использовал, так как трудны понимания (для меня) — Collaboration
AL>2. Каким образом поддерживалась их непротиворечивость друг другу?
Я никогда не задавался такой целью, я использовал UML как стандарт при коммуникации.
AL>3. Создавался ли на основе диаграмм код? Каким образом?
Создавал и создаю. Например, для генерации мэппинга, Entity-классов, DAO-классов при использовании ORM.
AL>4. Поддерживались ли диаграммы в актуальном состоянии в течение проекта? Каким образом?
Нет. Считаю это излишним. IMHO, "рисовать" — нужно до тех пор, пока это полезно, но не использовать модели ради самих моделей
AL>5. Какие проблемы помогло решить использование UML в проекте?
Основная решаемая проблема — это IMHO, коммуникация, все члены команды говорят на одном языке.
AL>6. Насколько сложные это были проекты?
Про некоторые ты и сам знаешь
Вообще трудно по каким-либо метрикам оценить "сложность"
Позвольте я скажу:
Определение DSL содержится в его названии:
Domain Specific Language — Специализированный язык предметной области.
Определение DSL от Ложечкина:
> http://blogs.gotdotnet.ru/personal/allo/CommentView.aspx?guid=8b96b298-edfb-4f45-b2c8-89f1a3ed610e
> Но сначала немного о DSL. DSL (Domain Specific Languages) – это технология и методология,
> которую предлагает Microsoft в области моделирования.
Тут нужно сказать следующее — звучит сие чрезмерно претенциозно.
Семантика выражения
"это технология и методология, которую предлагает Microsoft в области моделирования"
несколько отлична
от "это технология и методология, которую Microsoft начала другим советовать."
Правда звучит так:
Domain Specific Language — Специализированный язык предметной области.
Создание DSL — старый как человеческий разум подход к абстрагированию,
который переживет и UML и много других страшных терминов из
современного IT.
Microsoft приняло решение обратить мощь PR машины и подразделений
разработчиков внутри компании на этот факт и предоставить (i.e. продать)
методологию и средства ее поддержки (tools) для технологий MS.
Как обычно чтобы сделать сообщение полезным, несколько ссылок и цитат:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4
Chapter 4 Metalinguistic Abstraction
...
Metalinguistic abstraction -- establishing new languages -- plays an
important role in all branches of engineering design. It is
particularly important to computer programming, because in programming
not only can we formulate new languages but we can also implement
these languages by constructing evaluators. An evaluator (or
interpreter) for a programming language is a procedure that, when
applied to an expression of the language, performs the actions
required to evaluate that expression.
It is no exaggeration to regard this as the most fundamental idea in
programming:
The evaluator, which determines the meaning of expressions in a
programming language, is just another program.
To appreciate this point is to change our images of ourselves as
programmers. We come to see ourselves as designers of languages,
rather than only users of languages designed by others.
(перевод:
http://newstar.rinet.ru/~goga/sicp/sicp.pdf)
...
И сюрприз:
Форматная строка в fprintf(), regexp, конфигурация от make, скрипты
awk, yacc/lex, и SQL, HTML, это то же DSL.
Мир нормального программирования, не зашторенный
"умными" IDE, монстровидными run-time библиотеками для всего,
полон DSL'а уже давно, т.к. ценится возможность компактного
описания проблемной области.
The Practice of Programming
by Brian W. Kernighan and Rob Pike.
http://cm.bell-labs.com/cm/cs/tpop/
Chapter 9: Notation
9.1 Formatting Data
9.2 Regular Expressions
9.3 Programmable Tools
9.4 Interpreters, Compilers, and Virtual Machines
9.5 Programs that Write Programs
9.6 Using Macros to Generate Code
9.7 Compiling on the Fly
(перевод:
http://www.ozon.ru/context/detail/id/938233/
Б. Керниган, Р. Пайк Практика программирования)
--
Что же касается того, что в Microsoft сами ее уже давно используют
разнообразные DSL то в этом нет сомнений, т.к. там вполне адекватные люди.
А отношение к CASE утилитам в Microsoft:
Освящено в вышей степени ироничной, но глубокой книге
посвященной снятию лапши с ушей "молодых профессионалов":
Edward Yourdon "Death March"
известной в переводе как Эдвард Йордан «Смертельный марш»
ГЛАВА 6. ТЕХНОЛОГИЯ И СРЕДСТВА
Летом 1992 года мне довелось обедать с дружной группой менеджеров
среднего уровня Microsoft. Во время завязавшейся беседы я спросил,
является ли для проектных команд Microsoft обычным делом использование
таких методологий, как структурный анализ или объектно-ориентированное
проектирование. Ответы были примерно следующими: «иногда», «хммм,
вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я
спросил их относительно использования CASE-средств (которые в то время
все еще были довольно популярными в индустрии ПО), то из их ответов
понял, в чем заключается общее мнение майкрософтовцев: такие средства
годятся для «людей с улицы». С таким выражением я еще не встречался,
его можно грубо интерпретировать как «невежественные дикари, которые
только что вылезли из своего первобытного леса и начали обучаться
программированию, в отличие от настоящих программистов, которые не
нуждаются во всяких финтифлюшках».
Будучи слегка уязвленным, я поинтересовался, используют ли их
проектные команды хоть какие-нибудь средства, и в ответ услышал, что
каждая команда Microsoft может выбрать любые средства, которые сочтет
подходящими для своего проекта. Ухватившись за такой ответ, я спросил,
какое средство считает наиболее важным типичная проектная команда?
«На днях я задал одной из проектных команд такой же вопрос», — ответил
один из менеджеров. «Как вы думаете, что они ответили?» «Какой-нибудь
высокопроизводительный компилятор С++?», — спросил я. «Ассемблер? Или
мощное средство отладки для устранения множества ошибок в их коде
(хи-хи-хи)?» «Ничего подобного», — ответил менеджер, игнорируя мое
гнусное хихиканье. «Они ответили: электронная почта. Средний
разработчик Microsoft получает сотню сообщений в день; он живет в
электронной почте. Уберите электронную почту, и проект умрет».
---------------------------------------------------------------------
Итог: следите за тем не превратилась вы вы в «людей с улицы».
Снимайте лапшу, и читайте книги — они ключ к знаниям.
Статьи от MSFT надо воспринимать как PR — это есть их работа.
В данном случае, статья привлекает внимание к важной теме — DSL
(более актуальной чем прибитый гвоздями UML), незаслуженно мало
обсуждаемой.
И в ближайшем будущем надеюсь автор раскроет нам суть Microsoft way,
в отношении DSL, сделав упор на предлагаемые методологии и утилиты.
P.S. а определение DSL все же поправить хорошо бы.
Ваш opossum.
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, Вы соглашаетесь с тем, что Майкрософт не несет ответственности за использование Вами данной информации.
Автор(ы): Б. Керниган, Р. Пайк
