Вот об этом - http://18delphi.blogspot.com/2013/09/blog-post_1303.html
"Полную КД на какое-нить физическое реальное изделие вообще видел?
"Полную КД на какое-нить физическое реальное изделие вообще видел?
Там тоже встречаются
моменты когда все взглядом не охватишь. Когда все вместе свтдится.
А диаграмму можно еще на
несколько попилить. Типа все про тесты вынести. Все про библиотеки и т.д. но это
ценой еще одного уровня абстракции. Сложность то никуда не
денется..
Еще. Говоришь что
картинка говно и надо другими средствами пользоваться. Так скажи какими именно
или доходчиво на пальцах покажи на какие именно грабли и как больно ты будешь
натыкаться если продолжишь так делать.
К тому же есть похоже
проблемы в терминологии вообще. У вас же не диаграммы UML и не модель. И не RUP
ни разу.
Вместо толпы моделей
(прецедентов, реализации, тестирования, развертывания, ..) - все лежит на одной
диаграмме.
По RUP модель реализации
именно модель (упрощенная) по которой код педаляется и теоретически на ней все
может быть не отражено (типа приватные методы, какое-нить замороченные
внутренние приватные классы, сторонние библиотеки) - у все же это ближе именно к
чертежу по которому кодогенерация идет. И по определению на вашей диаграмме
должно быть ВСЕ.
И то что вы твердите UML
сбивает с толку. Поскольку от UML у все фактически осталось диаграмма с некими
квадратиками которые соединены некими стрелочками которые по начертанию похожи на
такие же в UML. А вот смысл в эту диаграмму заложен другой - это не модель, а
чертеж"
Интересный текст создал "товарищ" :-)
ОтветитьУдалить«А диаграмму можно еще на несколько попилить. Типа все про тесты вынести. Все про библиотеки и т.д. но это ценой еще одного уровня абстракции. Сложность то никуда не денется ..»
-- А общая, совокупная сложность никого особенно не трогает :-) Ну, разве что, ею можно хвастаться перед девушками в кабаке, а так... :-)
Сложность вызывает затруднения там, где она локализована в каком-то одном месте и с этим местом приходится работать - вносить в него изменения. тогда приходится думать, выражаясь программистским языком, "чтобы где чего не отвалилось". Одна из цель разработки архитектуры в уменьшении локализованной сложности - для этого существуют удачные методы: уменьшение связности, декомпозиция и т.д.
«Еще. Говоришь что картинка говно и надо другими средствами пользоваться. Так скажи какими именно или доходчиво на пальцах покажи на какие именно грабли и как больно ты будешь натыкаться если продолжишь так делать.»
-- О! Это вероятно, уже в мой огород :-)
Видите-ли "товарищ"... Средства неразрывно связаны с целями. Обычно, удачными средствами для описания архитектуры решения является техническое задание или другой документ, в явном виде описывающий архитектуру.
Очень хорошо, если описание архитектуры содержит изложение иде и целей, которые преследовались при проектировании. В таком случае удаётся донести "дух", а "буква" - она может меняться со временем.
Насчёт "граблей" понял не вполне, домысливать не стану.
«К тому же есть похоже проблемы в терминологии вообще. У вас же не диаграммы UML и не модель. И не RUP ни разу.»
-- То, что "не UML" - здесь не могу с "товарищем" не согласиться. RUP/не RUP сказать сложно, поскольку RUP не требует UML в явном виде.
«Вместо толпы моделей (прецедентов, реализации, тестирования, развертывания, ..) - все лежит на одной диаграмме.»
-- Да, в UML проводится разделение понятий. Немного смущает, когда на диаграмме перемешаны классы, объекты
прецеденты и определения стереотипов. Но не готов утверждать, что это - плохо. В конце концов, у меня сложилось впечатление, что можно так не делать.
«По RUP модель реализации именно модель (упрощенная) по которой код педаляется и теоретически на ней все может быть не отражено (типа приватные методы, какое-нить замороченные внутренние приватные классы, сторонние библиотеки) - у все же это ближе именно к чертежу по которому кодогенерация идет.»
-- Пока у меня не возникло понимание *необходимости* кодогенерации.
«И по определению на вашей диаграмме должно быть ВСЕ.»
Удалить-- Наверное, здесь уместнее говорить о совокупности диаграмм.
Кроме того, этот тезис IMHO очень связан с моим вопросом о том, как именно устроена работа "конечного" программиста. Вероятно, он должен вносить изменения в модель, отражать там вводимые им понятия, связывать их с существующими, порождать код посредством кодогенерации и вносить в него изменения с помощь IDE.
Если так, то работы очевидно больше. Помимо собственно создания кода, приходится перекладывать решение на язык диаграмм, после чего, после генерации прототипа, дорабатывать код вручную. Это дольше, чем просто написать нужный код.
Кодогенерация не может создать что-то новое, она может по формальным правилам сдублировать некоторый каркас, в который потребуется дорабатывать вручную. Кроме того, при изменении мета-модели, или даже самой модели в более низкоуровневой части, возникнет вопрос, что делать с написанным кодом, который противоречит модели после её рефакторинга. Провести его автоматический рефакторинг, очевидно, невозможно, поскольку кодогенератор, вероятно, не ничего не знает о смысле кода, расположенного за пределами создаваемого им каркаса. В таких случаях, вероятно, потребуется ручная работа, причём, квалифицированная. И этой работы будет больше, чем в случае, если приходится работать непосредственно с кодом.
По крайней мере, на текущий момент сложилось такое впечатление.
«И то что вы твердите UML сбивает с толку. Поскольку от UML у все фактически осталось диаграмма с некими квадратиками которые соединены некими стрелочками которые по начертанию похожи на такие же в UML. А вот смысл в эту диаграмму заложен другой - это не модель, а чертеж "»
-- В целом, присоединяюсь к "товарищу" в этой части его спича. Разве что, чертежом я бы это называть не стал, скорее, уместнее говорить о ещё одной графической нотации, ориентированной на кодогенерацию.
Хотя, впрочем, De gustibus non est disputandum... :-)
"А общая, совокупная сложность никого особенно не трогает :-) Ну, разве что, ею можно хвастаться перед девушками в кабаке, а так..."
Удалить-- вот это ИМХО - лишнее...
"«Еще. Говоришь что картинка говно и надо другими средствами пользоваться. Так скажи какими именно или доходчиво на пальцах покажи на какие именно грабли и как больно ты будешь натыкаться если продолжишь так делать.»
Удалить-- О! Это вероятно, уже в мой огород :-)"
--- вообще-то это камень в МОЙ огород...
"Кодогенерация не может создать что-то новое, она может по формальным правилам сдублировать некоторый каркас, в который потребуется дорабатывать вручную"
Удалить-- именно так...
"каркас"... с "параметризуемостью "по-месту""
http://18delphi.blogspot.com/2013/10/uml_16.html
"«И то что вы твердите UML сбивает с толку. Поскольку от UML у все фактически осталось диаграмма с некими квадратиками которые соединены некими стрелочками которые по начертанию похожи на такие же в UML. А вот смысл в эту диаграмму заложен другой - это не модель, а чертеж "»
Удалить-- В целом, присоединяюсь к "товарищу" в этой части его спича. Разве что, чертежом я бы это называть не стал, скорее, уместнее говорить о ещё одной графической нотации, ориентированной на кодогенерацию.
Хотя, впрочем, De gustibus non est disputandum... :-)"
- http://18delphi.blogspot.com/2013/10/blog-post_5617.html
«-- вот это ИМХО - лишнее...»
ОтветитьУдалить-- Я просто пошутил. И не над Вами. И тонко причём :-)
Обычно, проявление сложности - недостаток. Это в юности мне приятно смотреть на свою программу и восхищаться тем "какая она большая" и "как я крут" в этой связи. Став старше я понял, что гордиться нечем, что программа большая ввиду не объективной сложности задачи, а ввиду моего субъективного неумения описывать предметную область операционным языком. В неумении выделить этот язык. В незнании того, что такой язык нужен, наконец... :-)
В итоге сформировалось представление о сложности, которое я кратко изложил в предыдущем сообщении.
Какова совокупная сложность - никого не волнует. А вот какова она здесь и сейчас - это весьма существенно.
Рискну предположить, что удачную архитектуру можно выделить тем, что в ней локально (в произвольном месте) - всё просто, а глобально - всё иерархично и малосвязно.
«--- вообще-то это камень в МОЙ огород...»
-- Мне приятно Александр, что по крайней мере с позиции "товарища", "огород" у нас стал общим :-)
"Мне приятно Александр, что по крайней мере с позиции "товарища", "огород" у нас стал общим :-)"
ОтветитьУдалить-- товарищ (хотя и мой) - он не "за вас" и "не за меня".. он - рядом.. посему - незаинтересован.. да и ругаться с вами - я никогда не хотел..
"Я просто пошутил. И не над Вами. И тонко причём"
Удалить-- есть просьба... давайте не будем так шутить. у меня есть "коллега".. который примерно так же шутит.. притом - "не тонко".. я бы предпочёл.. без подобных эпитетов.. это - просьба..
"Рискну предположить, что удачную архитектуру можно выделить тем, что в ней локально (в произвольном месте) - всё просто, а глобально - всё иерархично и малосвязно."
Удалить-- согласен.. сам к этому стремлюсь.. но не всегда получается..
Что говоря про UML - "ограничения инструмента"... Это - ПРАВДА... Верхний уровень он по-имени связывается.. а нижние - по GUID.. и это нам такое "наследство" досталось...
Надеюсь - вы поняли...