Ada_Ru форум

Обсуждение языка Ада

Re: [ada_ru] OOD and Ada95

Оставить новое сообщение

Сообщения

Dmitriy Anisimkov
Re: [ada_ru] OOD and Ada95
2003-08-03 16:35:07

Alexandr Molchevsky wrote:

Ты сам как то скептически отзывался о построителях пользовательского

интерфейса, если я не ошибаюсь.

............

Думаю построение кода по UML и обратно, примерно из той же оперы.

 

Не смог придумать как вышеописанное можно применить к построению кода.

..............

Пока рисуешь кружочки и квадратики быстро приходишь к новым решениям

которые в случае реализации в коде пришли бы в голову именно в момент

реализации того-же самого класса или модуля. Вобщем IMHO удобно получается.

 

Что-ж, наверное мне стоит попробовать порисовать кружочки и квадратики,

вдруг мне это поможет ;-).

 

Вот только время выберу, и инструмент.

 

Вот одну ссылочку нашел в инете

http://www.artisansw.com/corporate/site_map.asp

 

Похоже что это платная штука, но попробовать дают, если зарегистрируешься.

Hello!

 

>Ты сам как то скептически отзывался о построителях пользовательского >интерфейса, если я не ошибаюсь.

............

>Думаю построение кода по UML и обратно, примерно из той же оперы.

 

Не смог придумать как вышеописанное можно применить к построению

кода.

..............

Пока рисуешь кружочки и квадратики быстро приходишь к новым решениям которые в случае реализации в коде пришли бы в голову именно в момент реализации того-же самого класса или модуля. Вобщем IMHO удобно

получается.

 

Что-ж, наверное мне стоит попробовать порисовать кружочки и квадратики, вдруг мне это поможет ;-).

 

Вот только время выберу, и инструмент.

 

 

Вот держи ниже по теме цитата из моего только что отосланного письма к Александру Хавва.

 

Там во второй половине пример адских проблем о которых я хотел узнать из фидошной эхи но мне ни кто не сказал. Но домаю не все поторяно, время еще есть. :)

 

-----------------------------------

 

Кстати ты юзаешь что-то генерящее код из UML и диаграммы из кода?

 

нет, до UML у меня руки/ноги не дошли.

к тому же, что-то мне подсказывает, что _пока_ это только

интересное/модное/возможно перспективное академическое направление развития программирования,

 

Это ты зря. Я вот потратил пол-года на самообразование в этой сфере и совсем не жалею.

Рекомендую купить книжку "Применение UML и шаблонов проектирования" автор Крэг Ларман, я читал второе издание, но написано что оно расширяет и дополняет первое, в оригинале "Applying UML and patterns" Craig Larman, и читать ее перед сном по паре листов. Сильно больше прочитать не получится потому что большая смысловая нагрузка на строчку текста, это не Гради Буч.

:) Кстати у нее прекрасный перевод, например use case переведено как "прецедент", это вообще самая хорошая попытка перевода которую я видел. В ней автор описывает свой личный опыт проектирования и реализации программ, причем все на конкретный примерах, и вообще там вся книжка построена вокруг создания POS-системы. А автор тех. дир. по вопросам проектирования в консалтинговой конторе Valtech. Короче не теоретик, а серьезный практик.

 

особенно в части касающейся

финального кода. основные проблемы: надежность и читабельность

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

генерирует достаточно надежный код.

однако представь,

что программер на фирме А нагенерил этого кода по самое оно,

а ты сидишь в фирме Б и тебе необходимо модифицировать этот код. кодогенератора из UML, такого как на фирме А, у твоей фирмы нет.

 

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

допустим даже, что есть сам исходник UML, что скорее всего

будет вряд-ли,

 

Таки скорее всего он будет потому что это неотъемлемая часть проектной документации в тех конторах который юзают UML при проектировании.

да и при отсутствии генератора фирмы А

он будет до лампочки. можно даже допустить, что у твоей

конторы такой же кодогенератор имеется, но вот среда в которой

он работает, практически гарантированно будет отличаться,

а значит "жить" он будет по другому.

 

Это все не так потому что если тебе надо править код то ты берешь и правишь его руками как все.

 

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

 

в общем, единственное чем ты гарантированно обладаешь

это _исходным_ кодом системы (_не_ hello world), который сгенерирован из

UML.

проблема понятна?

 

Проблемы нет. Исходник программы сделанной с использованием генератора кода ни чем не отличается от того что пишут руками.

 

Почему неявно, есть же четко описанное правило наследования, нужно его учитывать.

Хотя конечно если бы не наследовалось то были бы свои преимущества.

 

проблема подобного "скрытого" наследования проявляется

во всей красе, когда у тебя система имеет соответствующие

габариты. особенно, когда эти "грабли" качественно закопает

сосед по проекту. компилятор при этом даже не чихнет,

 

Да, я забыл что в Ada не нужно так часто лазить в исходники спецификаций как в ++, и что можно вообще их не иметь.

 

а _твоя_ результирующая программа, использующая

библиотеку от соседа, в которой эти "грабли" зарыты

фиг будет работать. и отыскать это будет не просто.

сосед ведь чесно скажет, что у него все работает.

 

Ясно. Теперь понял. Вот такие тонкости я хотел выяснить в фидошной эхе но ни кто мне не рассказал. :(((

 

еще один, наверное, "тонкий" момент, который понять можно,

а вот осознание вызывает проблемы.

для показанных выше примеров типы Object и Object_2

вовсе не нуждаются в функции Create (сюрприз?)

гораздо естественнее использование агрегатов

(Ада - это _не_ Паскаль).

 

Конечно, я все это учитываю, IMHO конструкторы вообще здесь нужны

только

если требуется нетривиальная инициализация объекта. Правда в фидо мне так

и

не успели объяснить почему

использование контролируемых типов серьезно сказывается на

производительности, и как сделать на Ada простой пример который я там приводил на С++. Меня модератор раньше покрестил. :)

 

я могу высказать только одну философскую мысль по этому поводу:

надо пытаться решить задачу, а не пытаться извихнуться на Аде

также как и на С/С++.

 

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

 

 

Good luck!

Alexandr Molchevsky jolly-fellow@...

Alexandr Molchevsky wrote:

 

Общий смысл итеративной разработки с использованием UML заключается в

том что ты пишешь проект, рисуешь диаграммы, потом из диаграмм тебе

генерится костяк твоего проекта, то есть спецификации нарисованных тобой

классов, а потом ты программишь руками. Если в процессе программирования ты

расширяешь/изменяешь спецификацию класса, то потом напускаешь на исходники

программу для реверс-инжиниринга и она модифицирует твои диаграммы в

документации согласно внесенных тобой изменений.

 

Извините, но могу сказать только одно: Ха-ха! :)

 

 

Проблемы нет. Исходник программы сделанной с использованием генератора

кода ни чем не отличается от того что пишут руками.

 

В учебнике? На деле практика использования UML в разработке RT программ уже второй-третий год обсуждается на всех всемирных попойках, в которых принимают участие весьма умные (и в теории и в практике) дядьки. Результат - продолжают использовать Hood (кажись так оно называется).

 

Второй момент. На сегодняшний день редко разрабатывают программы с нуля. Старый код обычно писан вообще без ОО. Как реверс-инжиниринг разберется с наследованием путем построения эквивалента таблицы виртуальных методов как записи/массива и косвенным вызовам?

 

Поэтому ради бога не смешите меня генерацией кода и обратным инжинирингом. UML неспроста придуман. Когда провалились святые мечты на CASE средства и было доказанно, что по неверным описаниям любая CASE система абсолютно правильно построит неверную программу, был придуман UML. Зачем? А затем, что бы зафиксировать _стандартный_ язык _моделирования_. Как это в конструкторском деле всех видов принято. Но болезнь CASE-изации не прошла, а приняла новый вид. Результат же наверняка будет тот же.

 

 

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

 

 

-- Vadim Godunko

Vadim Godunko wrote:

Проблемы нет. Исходник программы сделанной с использованием генератора

кода ни чем не отличается от того что пишут руками.

 

 

В учебнике? На деле практика использования UML в разработке RT программ уже второй-третий год обсуждается на всех всемирных попойках, в которых принимают участие весьма умные (и в теории и в практике) дядьки.

Ага. Вот можно почитать как об UML отзываются в Praxis Critical Systems

http://www.sparkada.com/downloads/magics.pdf (искать слово UML)

В двух словах - "UML надувательство и дань моде. Семантика UML до того

расплывчата, что не только генераторы не могут писать правильный код,

но и люди понимают UML диаграмму каждый по своему"

 

Я пытался посмотреть что есть в плане генерации кода UML->Ada.

От тех версий Rational Rose, что у меня были, Аду ни одна не генерила.

 

Из Open Source программ видел dia2code

http://dia2code.sourceforge.net/

Результат - жуть.

 

Есть еще

http://uml.sourceforge.net/feature.php

Тоже пишут про Ada, но я не пробовал.

 

Максим

В двух словах - "UML надувательство и дань моде. Семантика UML до того

расплывчата, что не только генераторы не могут писать правильный код,

но и люди понимают UML диаграмму каждый по своему"

 

Категорически согласен. Мне тут довелось вести практикум по UML на

пятом курсе ВМиК (сама по себе затея практикума на пятом курсе - уже

идиотизм).

 

UML хорош в двух случаях - в рамках относительно небольшой команды,

где все _ДОГОВОРИЛИСЬ_ о том, как и зачем им пользоваться и как его

понимать, и для составления отчетов о победах и достижениях,

чтобы начальству пыль в глаза пускать.

 

Я пытался посмотреть что есть в плане генерации кода UML->Ada.

От тех версий Rational Rose, что у меня были, Аду ни одна не генерила.

 

Моя вот генерит. Но лучше б она этого не делала :(

Sergey I. Rybin wrote:

 

Я пытался посмотреть что есть в плане генерации кода UML->Ada.

От тех версий Rational Rose, что у меня были, Аду ни одна не генерила.

 

 

Моя вот генерит. Но лучше б она этого не делала :(

 

Извините за любопытство, а ACT/ACTE используют UML для внутренних разработок?

 

 

-- Vadim Godunko

Моя вот генерит. Но лучше б она этого не делала :(

 

 

Извините за любопытство, а ACT/ACTE используют UML для внутренних разработок?

 

Нет :)

 

Я ж говорил - я практикум по UML на ВМиК МГУ вел. Дали нам розу -

потренироваться. Ну, я для какой-то дурацкой задачи попросил сгенерить

код на Аде. И ужаснулся.

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти