Не могу не рассказать...
Ни для кого не секрет, что практически ВСЕ приложения имеют те или иные пользовательские настройки.
Настройки обычно выглядят как "дополнительные требования" к ТЗ на прецедент.
И в ТЗ они описываются "обычно" примерно так - "название настройки" -> "список допустимых значений".
Далее программист берёт это и "кодирует".
Кодирует он примерно следующее:
1. Идентификатор настройки во внутренней базе настроек. Ключ-константа.
2. Пользовательское имя настройки - локализуемое значение.
3. "Ручки" для чтения/записи настройки из базы настроек. Скрывающие ключ и "пользовательское имя".
4. Умолчательные значения.
5. Поведение системы в зависимости от того или иного значения настройки. Считайте - "микро"-конечный-автомат.
6. Шаблон Publisher/subscriber на тот случай, если настройка изменится на лету.
7. "Визуализатор" данной ОТДЕЛЬНОЙ настройки в диалоге настройки системы.
Так вот я сделал такой шаблон кодогенерации которому достаточно "названия настройки" и "списка её значений" ПРЯМО в ТЗ. Как "дополнительных требований к прецеденту".
Далее берём элемент кода - на котором должна "жить" настройка, ставим ему связь РЕАЛИЗАЦИИ к данной настройке из требований и всё, и вся остальная обвязка - генерируется АВТОМАТИЧЕСКИ. С минимумом "рукописного" кода. Все ключи/значения, а также publisher/subscriber - генерируются. А также - "визуализатор" и "конечный автомат".
Интересно?
Написать как это выглядит на UML и Delphi? Или опять - "фуу - не бетон же месим..."?
Ни для кого не секрет, что практически ВСЕ приложения имеют те или иные пользовательские настройки.
Настройки обычно выглядят как "дополнительные требования" к ТЗ на прецедент.
И в ТЗ они описываются "обычно" примерно так - "название настройки" -> "список допустимых значений".
Далее программист берёт это и "кодирует".
Кодирует он примерно следующее:
1. Идентификатор настройки во внутренней базе настроек. Ключ-константа.
2. Пользовательское имя настройки - локализуемое значение.
3. "Ручки" для чтения/записи настройки из базы настроек. Скрывающие ключ и "пользовательское имя".
4. Умолчательные значения.
5. Поведение системы в зависимости от того или иного значения настройки. Считайте - "микро"-конечный-автомат.
6. Шаблон Publisher/subscriber на тот случай, если настройка изменится на лету.
7. "Визуализатор" данной ОТДЕЛЬНОЙ настройки в диалоге настройки системы.
Так вот я сделал такой шаблон кодогенерации которому достаточно "названия настройки" и "списка её значений" ПРЯМО в ТЗ. Как "дополнительных требований к прецеденту".
Далее берём элемент кода - на котором должна "жить" настройка, ставим ему связь РЕАЛИЗАЦИИ к данной настройке из требований и всё, и вся остальная обвязка - генерируется АВТОМАТИЧЕСКИ. С минимумом "рукописного" кода. Все ключи/значения, а также publisher/subscriber - генерируются. А также - "визуализатор" и "конечный автомат".
Интересно?
Написать как это выглядит на UML и Delphi? Или опять - "фуу - не бетон же месим..."?
"название настройки" -> "список допустимых значений".
ОтветитьУдалить-- по-моему чем-то похоже на Fit-таблицы.
Или feature-tables?
ОтветитьУдалитьhttp://www.insdc.org/files/feature_table.html
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368585(v=vs.85).aspx
ОтветитьУдалить«Интересно?
ОтветитьУдалитьНаписать как это выглядит на UML и Delphi?»
-- Мне было бы *очень* интересно.
Только интересует полный цикл:
1. UML
2. Необходимые шаблоны
3. Код
4. Методика применения
Хорошо. Я обязательно напишу. Хотя не все слова понял. Например "Методика применения" - это что? Инструкция как применять?
Удалить«Хорошо. Я обязательно напишу. Хотя не все слова понял. Например "Методика применения" - это что? Инструкция как применять?»
Удалить-- Именно так. Необязательно сочинять здесь ВойнуИМир :-) Нужно указать просто, как технологически выглядит процесс добавления новой настройки. Какие действия должны выполнить разработчики для того, чтобы в приложении появилась новая требуемая настройка.
"Какие действия должны выполнить разработчики для того, чтобы в приложении появилась новая требуемая настройка."
УдалитьТам до банального всё просто. Внутри прецедента рисуем "настройку" с её названием, а внутри неё делаем квадраты-значения с их названиями. И клиентскому классу ставим связь РЕАЛИЗАЦИИ к данной настройке. Всё. Всё остальное - генерируется само.
Все остальные клиентские классы ходят к указанному выше классу как к ФАСАДУ.
Удалить«Внутри прецедента рисуем "настройку" с её названием, а внутри неё делаем квадраты-значения с их названиями. И клиентскому классу ставим связь РЕАЛИЗАЦИИ к данной настройке.
ОтветитьУдалитьВсе остальные клиентские классы ходят к указанному выше классу как к ФАСАДУ.»
-- 1. Внутри *какого* прецедента рисуем настройку?
2. Какими элементами UML описываем новую настройку?
3. О каких "квадратах" идёт речь (классы/объекты/примечания и т.д.)?
4. Какими элементами UML описывается связь "РЕАЛИЗАЦИИ"?
5. Посредством каких средств UML Вы отражаете, что клиентские классы "ходят к указанному выше как к ФАСАДУ".
Я знаю, что такое "фасад", но интересует, как Вы отражаете это средствами UML, ведь сделать это можно разными способами.
Обо всех обозначенных Вами вещах можно только догадываться, Александр.
UML - это не квадраты со стрелками, а до какой-то степени формальное описание по определённым правилам.
Убеждён, что если отступить от подразумеваемых Вами соглашений - ничего "само" не генерируется.
Опишите этапы конструирования UML, опишите соглашения, укажите, что конкретно в данном случае возлагается на шаблоны. В таком виде это будет представлять интерес.
"Убеждён, что если отступить от подразумеваемых Вами соглашений - ничего "само" не генерируется."
Удалить-- конечно! Отступать от мета-модели - НЕЛЬЗЯ! Но во-первых это не даст сделать редактор (он валидирует возможные физические связи), а во-вторых - генератор (он валидирует логические связи).
Подробнее напишу позже. Сейчас - цейтнот.
" Внутри *какого* прецедента рисуем настройку"
Удалить-- внутри того прецедента системы (или библиотеки) к которому относится данная настройка.
Этот комментарий был удален автором.
УдалитьЭтот комментарий был удален автором.
Удалить"Какими элементами UML описываем новую настройку?"|
ОтветитьУдалить-- "UseCaseSetting" и "UseCaseSettingValue"
"О каких "квадратах" идёт речь (классы/объекты/примечания и т.д.)?"
Удалить-- "UseCaseSetting" и "UseCaseSettingValue", а также - "SimpleClass" и "SettingsHolder".
"Какими элементами UML описывается связь "РЕАЛИЗАЦИИ"?"
Удалить-- стандартной стрелкой Realize. Вот такой - "--->"
"Посредством каких средств UML Вы отражаете, что клиентские классы "ходят к указанному выше как к ФАСАДУ"."
Удалить-- стрелками Dependency. Со стереотипом "uses".
Спасибо Александр. По-моему, всё Вами сказанное пришло время проиллюстрировать соответствующими UML в отдельном посте. Тем более, что расшифровывая одни свои соглашения, Вы уже упомянули другие:
ОтветитьУдалить«"UseCaseSetting" и "UseCaseSettingValue", а также - "SimpleClass" и "SettingsHolder"».
В общем, интересно увидеть продолжение.
Напишу...
УдалитьСпасибо Александр. В этом месте действительно, *очень* интересно.
ОтветитьУдалить"Спасибо Александр. В этом месте действительно, *очень* интересно."
Удалить-- в каком именно? Про ограничения мета-модели? Развить тему?
«в каком именно? Про ограничения мета-модели? Развить тему?»
Удалить-- Да, получается то, что Вы обозначили как "ограничения модели" очень важны.
Для того, чтобы представить конкретику технологии работы нужно понимать, какими описательными инструментами вы (не только Вы) пользуетесь. С Ваших слов известно, что применяется UML и интенсивно разрабатываются диаграммы вариантов использования.
Вы упомянули, что "рисуете" настройку в том прецеденте, или библиотеке (прецедентов?), к которым настройка относится.
Но настройка может быть востребована в нескольких прецедентах - например, в одном (как минимум) настройку используют, а в другом - обеспечивают интерактивную возможность пользователю её изменить. Так вот, интересно увидеть соответствующие UML для этих use-cases, чтобы понять, каким образом (посредством каких элементов языка UML) происходит связывание элементов одних прецедентов (квадратов, как Вы пишите) с другими, а также осознать, посредством каких приёмов не теряется наглядность совокупной диаграммы. Ведь классов, объектов, интерфейсов и связей между всем этим "хозяйством" в реальном проекте становится очень много и диаграмма (в классическом её представлении) становится слишком сложной для банальной навигации по ней, не говоря уже о понимании того, что и как она описывает. Деревьев много, лес - теряется.
Если используется иерархичность диаграмм (вложенность набора диаграмм в другую диаграмму), как в ARIS, например, то хотелось бы понять, как организованы связи из одной диаграммы, на другую, при условии, что первая и вторая вложены (м.б. опосредовано) в разные диаграммы. Это нужно для того, чтобы понять, какие требования к инструменту разработки диаграмм предъявляются.
«О каких "квадратах" идёт речь (классы/объекты/примечания и т.д.)?"
-- "UseCaseSetting" и "UseCaseSettingValue", а также - "SimpleClass" и "SettingsHolder".»
-- Ok, могу догадаться, что это специфические базовые классы, для генерации кода которых вы, очень вероятно, используете шаблоны. Приведите примеры этих шаблонов, обозначьте, почему шаблоны необходимы в данном случае (или, почему они не нужны в нём). Решение каких конкретно задач выносится на уровень шаблонов. Наверняка у вас существует парадигма (м.б. и не одна) создания этих шаблонов, где Вы описываете детали, для отражения которых UML не предназначен.
Важно понять, какой набор вопросов придётся решать программисту при "программировании на шаблонах". Ведь код писать напрямую - это на втором шаге потерять связь с UML, а на третьем - сделать диаграммы совсем неактуальными.
Тут вообще-то, вопросов просто уйма, я просто утомлюсь их перечислять и утомлю тех, кто решится их читать. Самое дурацкое, что вопросы эти будут основаны на моих домыслах относительно того, что и как у вас устроено. Собственно, я хочу разобраться, но у меня мало информации для того, чтобы прояснить существенные моменты.
Наконец, хотелось бы прояснить следующее. Предположим, у вас существует новый сотрудник. Предположим, перед ним поставлена задача:
Удалить1. Создать настройку,
2. Обеспечить возможность её интерактивного ввода в контексте существующего интерактивного режима (ну, уже есть в проекте форма, в которой пользователь может ввести настройки).
3. Использовать эту настройку в ситуации для которой она предназначена.
Что и в каком порядке он делает для решения указанной задачи? Ему нужно найти, в каком месте создавать настройку (библиотека, прецедент). Как (основываясь на чём) он ищет, посредством чего (возможно, на диаграммах у вас поддержан контекстный поиск) находит?
Далее, нужно отыскать прецеденты, в которых на настройку нужно реагировать. Опять же, как он находит эти прецеденты, в предположении, что они явно указаны в постановке, но возможно, на другом языке. Например, если постановщик не вовлечён в создание UML (если UML связан с кодом у него просто может не быть требуемой квалификации), то для описания места, где требуется использовать настройку, он вероятно использует язык, который ближе пользователю. Например: «во всех открываемых окнах, содержащих редактор текста, обеспечить перенос по словам в соответствии с настройкой XXXX». - Нет так? А как?
В таком случае, чем будет руководствоваться новый сотрудник, чтобы найти прецедент(ы) соответствующие «всем окнам, содержащим редактор текста»?
Далее, какие действия потребуются с UML и шаблонами, чтобы отразить требование по использованию настройки.
Я надеюсь, очевидно (хотя, если честно, уже не надеюсь, потому и пишу это явно), что я от Вас ничего не требую, не настаиваю, не ожидаю и на "моральное право" (или что бы то ни было ещё) не претендую. Вообще же, в отношении лично себя я руководствуюсь известной фразой «Это интернет, детка, здесь могут и на … послать». Я просто пытаюсь максимально внятно сформулировать, что лично мне непонятно и без понимания чего представление о *технологии* у меня не складывается.
Если у меня не складывается представление, я (и, вероятно, не только я) могу воспринимать информацию только нейтрально: ну и я так могу, в чём гешефт, собственно? Если оно (представление) сложится, возникнет (и, возможно, не только у меня) ясность в отношении преимуществ UML в его связи с кодом в сравнении с просто кодом, без UML или UML в качестве пояснительных картинок в постановках или на доске для корпоративного «трёпа».
«Это интернет, детка, здесь могут и на … послать»
Удалить-- нет - тут вот как раз всё по делу.
Много всего написано. Много вопросов. Переварю - отвечу.
Особенно про "нового сотрудника" - сложная тема.
У меня сейчас дома происходит "пожар"/ремонт/переезд. Так что в блоге может вообще образоваться "оперативная пауза".
"Но настройка может быть востребована в нескольких прецедентах - например, в одном (как минимум) настройку используют, а в другом - обеспечивают интерактивную возможность пользователю её изменить"
Удалить-- да мы это представляем себе. И не раз сталкивались. Более того у нас мета-модель не позволяет прецедентам НАПРЯМУЮ использовать друг-друга. Точнее (РЕАЛИЗАЦИЯМ прецедентов). Так что - вопрос - хороший и серьёзный.
1. Создать настройку,
УдалитьОн создаёт её в соответствующем прецеденте.
2. Обеспечить возможность её интерактивного ввода в контексте существующего интерактивного режима (ну, уже есть в проекте форма, в которой пользователь может ввести настройки).
Если "есть форма", то туда настройка попадает "автоматом". Лукавлю немного. У нас не совсем так. Но проблемы - чисто технические.
3. Использовать эту настройку в ситуации для которой она предназначена.
Если она нужна ВНУТРИ соответсвующего прецедента, то ничего делать не надо. Она автоматом доступна в namespace'е соответствующего прецедента. Если из ДРУГОГО, то просто надо поставить стрелку uses от ДРУГОГО прецедента к данной настройке.
"(хотя, если честно, уже не надеюсь, потому и пишу это явно), что я от Вас ничего не требую, не настаиваю, не ожидаю и на "моральное право" (или что бы то ни было ещё) не претендую."
УдалитьНу вы уж не "демонизируйте" меня и моих коллег :-)
"Важно понять, какой набор вопросов придётся решать программисту при "программировании на шаблонах"."
Удалить-- "конечному" программисту - никакие. Шаблоны уже есть. И они - обычно работают. Если не работают, то всё - сложнее.
"Да, получается то, что Вы обозначили как "ограничения модели" очень важны."
Удалить-- это правда. Есть модель. И есть мета-модель. Мета-модель задаёт правила создания модели. Эти правила разрабатываются отдельно. Проектно-зависимые. Я надеюсь, что я отдельно про это напишу. Хотя уже "кое-что"написал. Жаль, что я не всё "могу донести". Если бы я тыкал бы "пальцем в монитор" - было бы сильно проще. Но я - напишу.
"Например, если постановщик не вовлечён в создание UML (если UML связан с кодом у него просто может не быть требуемой квалификации), то для описания места, где требуется использовать настройку, он вероятно использует язык, который ближе пользователю."
Удалить-- это правда. Мы пытались "научить" постановщиков UML'ю. Но потерпели фиаско. Однако некоторые "формальные правила" мы всё же - разработали.
"Самое дурацкое, что вопросы эти будут основаны на моих домыслах относительно того, что и как у вас устроено. Собственно, я хочу разобраться, но у меня мало информации для того, чтобы прояснить существенные моменты."
Удалить-- поверьте, я не скрываю ничего. Просто не всё могу "письменно объяснить". В "разговорах в курилке" - получается сильно проще. Но это - моя личная особенность. Не завязанная на технологический процесс..
"Приведите примеры этих шаблонов, обозначьте, почему шаблоны необходимы в данном случае (или, почему они не нужны в нём)."
Удалить--вот тут есть скользкий момент. Они на том самом "криптованном" языке. От которого мы избавляемся.
"Например: «во всех открываемых окнах, содержащих редактор текста, обеспечить перенос по словам в соответствии с настройкой XXXX»."
Удалить-- именно так. И это вписывается в ТЗ "на прецедент". А внутри прецедента уже потом - рисуется настройка.
А если прецедентов с похожими настройками несколько, то выделяется базовый абстрактный прецедент. Не постановщиком задачи конечно же.
"Если используется иерархичность диаграмм (вложенность набора диаграмм в другую диаграмму)
Удалить-- мы так и делаем.
«Особенно про "нового сотрудника" - сложная тема.»
Удалить-- Если нужно, я могу рассказать как такой "новый сотрудник" будет решать задачу в нашей организации.
«-- да мы это представляем себе. И не раз сталкивались. Более того у нас мета-модель не позволяет прецедентам НАПРЯМУЮ использовать друг-друга. Точнее (РЕАЛИЗАЦИЯМ прецедентов). Так что - вопрос - хороший и серьёзный.»
-- А в таком случае, это не просто важно, а критически важно. Тем более, что сам по себе UML не запрещает прецедентам использовать друг друга.
Если Вы ввели такое ограничение, то убеждён, что это уж точно не с проста. Но это мотивация этого ограничения никак не следует из того, что Вы говорили ранее.
«1. Создать настройку,
Он создаёт её в соответствующем прецеденте.»
-- Простите, но "соответствующем" чему?
«2. Обеспечить возможность её интерактивного ввода в контексте существующего интерактивного режима (ну, уже есть в проекте форма, в которой пользователь может ввести настройки).
Если "есть форма", то туда настройка попадает "автоматом". Лукавлю немного. У нас не совсем так. Но проблемы - чисто технические.»
-- Конечно лукавите. Как она может попасть в *нужное* место этой формы, если не помещена туда явно? Форма может содержать множество элементов оформления (вкладки, панели, про фреймы, подгружаемые отдельно, я уже не говорю). Где-то и как-то нужно указать, в каком месте такой формы мы ожидаем настройку. Да это вообще может постановщик явно указать (или даже нарисовать соответствующее поле самостоятельно).
«3. Использовать эту настройку в ситуации для которой она предназначена.
Если она нужна ВНУТРИ соответсвующего прецедента, то ничего делать не надо. Она автоматом доступна в namespace е соответствующего прецедента. Если из ДРУГОГО, то просто надо поставить стрелку uses от ДРУГОГО прецедента к данной настройке.»
-- Ну, тут просто масса вопросов... Обозначу только самые очевидные:
* Как произойдёт синхронизация настройки при интерактивном изменении её пользователем с активными реализациями прецедентов, использующих эту настройку? Например, открыто несколько не модальных окон редактора (являющихся реализациями соответствующих прецедентов), и пользователь интерактивно меняет настройку (в другом прецеденте), которую "отрабатывают" редакторы, в открытых окнах. На каком уровне отрабатывается такая связь? Как она задаётся средствами UML?
* Как сказанное Вами здесь:
«Если из ДРУГОГО, то просто надо поставить стрелку uses от ДРУГОГО прецедента к данной настройке.»
согласуется со сказанным ранее:
«-- да мы это представляем себе. И не раз сталкивались. Более того у нас мета-модель не позволяет прецедентам НАПРЯМУЮ использовать друг-друга. Точнее (РЕАЛИЗАЦИЯМ прецедентов).»
Стрелка класса ”uses” мне представляется именно *прямым* использованием.
* Выше Вы упомянули об «автоматичности» попадания настройки в форму ввода, где пользователь может изменять настройки интерактивно.
Отвлекаясь от моих комментариев выше по этому поводу, объясните: за счёт чего достигается автоматичность.
* Что Вы понимаете под пространством имён прецедентов. Посредством чего это
понятие поддерживается?
"не теряется наглядность совокупной диаграммы."
Удалить-- "совокупной" диаграммы системы - в целом - нет. Она очень БОЛЬШАЯ получилась бы.
"* Как произойдёт синхронизация настройки при интерактивном изменении её пользователем с активными реализациями прецедентов, использующих эту настройку? Например, открыто несколько не модальных окон редактора (являющихся реализациями соответствующих прецедентов), и пользователь интерактивно меняет настройку (в другом прецеденте), которую "отрабатывают" редакторы, в открытых окнах. На каком уровне отрабатывается такая связь? Как она задаётся средствами UML?"
Удалитьpublisher/subscriber - выводимые из связей модели
"Если Вы ввели такое ограничение, то убеждён, что это уж точно не с проста. Но это мотивация этого ограничения никак не следует из того, что Вы говорили ранее."
Удалить-- конечно не спроста.
"-- да мы это представляем себе. И не раз сталкивались. Более того у нас мета-модель не позволяет прецедентам НАПРЯМУЮ использовать друг-друга. Точнее (РЕАЛИЗАЦИЯМ прецедентов).»
УдалитьСтрелка класса ”uses” мне представляется именно *прямым* использованием."
-- "Точнее (РЕАЛИЗАЦИЯМ прецедентов)" - я не зря это написал :-) Прецеденты - друг друга напрямую - МОГУТ использовать (на уровне модели ТЗ) РЕАЛИЗАЦИИ - нет. Реализации прецедентов - это ПРОЕКТНЫЕ классы. Они реализуют прецеденты из ТЗ. Связью realization. И реализации прецедентов друг про друга ничего не знают. Друг про друга знают только прецеденты.
"Выше Вы упомянули об «автоматичности» попадания настройки в форму ввода, где пользователь может изменять настройки интерактивно.
УдалитьОтвлекаясь от моих комментариев выше по этому поводу, объясните: за счёт чего достигается автоматичность."
-- ну как минимум - строится соответствующий контрол-визуализатор для данной настройки. С соответствующим наследованием и ограничениями. Выводимыми из "типа" настройки и списка её значений.
«"не теряется наглядность совокупной диаграммы."
Удалить-- "совокупной" диаграммы системы - в целом - нет. Она очень БОЛЬШАЯ получилась бы.»
-- Это ожидалось мною изначально, да и Вы говорили об этом ранее. Но в таком случае, крайне существенным я виду вопросы навигации по диаграмме. С кодом, в целом, проблем нет. На худой конец можно воспользоваться поиском в исходных текстах, найти упоминание той или иной заинтересовавшей вещи и, анализируя связи, составить представление об архитектуре и/или сделать требуемое, основываясь на аналогичных решениях. Этот подход проверен и известно, что он работает. На каком-то этапе даже полезно ему следовать, поскольку удаётся узнать много нового относительно кода, который начинал писать сам.
Для диаграмм же эта тема не представляется проработанной. Архитектурные решения, влияющие на вид диаграмм могут очень сильно варьироваться (в одной организации, это понятно, можно стандартизовать), но какой обобщённый способ анализа Вы видите? Иными словами, как, имея диаграмму и шаблоны получить представление о том, как архитектурно связаны определение настройки и её использование в разных прецедентах? Настройку для начала нужно найти в диаграмме. Как это сделать?
Далее, если нужно изменить её интерпретацию в соответствующих прецедентах, то как я понимаю, придётся вносить изменения в шаблоны кодогенерации. Соответственно, уже к шаблонам предъявляются требования простоты.
Потом, в использовании настроек в разных прецедентах может обнаружиться много общего. Каким образом в таком случае обеспечивается повторное использование кода? Рискну предположить, что средствами того же UML. Но это опять увеличивает его связность, особенно, если принять во внимание иерархичность его организации. Не потеряется ли при этом наглядность UML?
Мои вопросы совершенно не праздные. Я имею некоторый опыт применения ARIS (от которого сейчас, по счастью, отказались), поэтому я представляю себе, что по мере усложнения модели её представление усложнялось нелинейно. Но там не было кода! А в Вашем случае он есть, да ещё и записанный в форме шаблонов. Вот и возникают у меня вопросы относительно порога входа, времени, требующегося на изучение существующего, методик и парадигм, а также затрат на ведение UML-кодо-хозяйства.
«Особенно про "нового сотрудника" - сложная тема.»
Удалить-- Если нужно, я могу рассказать как такой "новый сотрудник" будет решать задачу в нашей организации.
--расскажите.
Хотя я про "новых сотрудников" говорил не в контексте "настроек".
Нормальные люди у нас обычно втягиваются за два-три месяца. Хотя на собеседованиях я обычно говорю - "готовьтесь три-пять лет у нас отработать. Иначе - глупо".. Но это мой мнение..
Да и текучку среди программистов у нас - небольшая.
"Каким образом в таком случае обеспечивается повторное использование кода? Рискну предположить, что средствами того же UML."
Удалить-- именно так.
"Но это опять увеличивает его связность, особенно, если принять во внимание иерархичность его организации."
Удалить-- а вот тут - нет. Связность не увеличится. Шаблоны- тоже иерархичные. С ДРУГОЙ иерархией.
"Вот и возникают у меня вопросы относительно порога входа, времени, требующегося на изучение существующего, методик и парадигм, а также затрат на ведение UML-кодо-хозяйства."
Удалить-- у новых сотрудников - затрат "никаких" кроме освоения "мета-модели". Но она - интерактивна. Редактор моделей - сам тебя ведёт. Он не даст сделать что-то отличное от мета-модели. Новым сотрудникам говорят - "ну вот так устроен мир". Если в этом устройстве что-то не так - мы либо правим шаблоны, либо обучаем новых сотрудников - как это сделать самим. Второе - конечно - сложнее.
"А в Вашем случае он есть, да ещё и записанный в форме шаблонов."
Удалить-- одно уточнение. В шаблонах записан не код. А ПРИНЦИПЫ генерации кода. Это ВАЖНО.
Более того - шаблоны - могут опираться на конкретные модели, построенные на этих шаблонах.
Ну как "раскрутка компилятора".
Есть мета модель (1). На ней нарисована модель (1). Когда делаем мета-модель (") мы можем опираться на модель (1). В итоге получаем мета-модель (2) на которой делаем модель (2). И далее - по индукции.
"Когда делаем мета-модель (")" => "Когда делаем мета-модель (2)"
Удалить"Настройку для начала нужно найти в диаграмме. Как это сделать?"
Удалить-- если я правильно понял вопрос, то - функцией поиска. По стереотипу. У нас поиск - продвинутый. По многим параметрам умеет искать.
"но какой обобщённый способ анализа Вы видите?"
Удалить-- я сам бы хотел себе ответить на этот вопрос :-) но если я на него отвечу, то скорее всего - я буду работать в другой организации :-)
"Иными словами, как, имея диаграмму и шаблоны"
Удалить-- давайте только точки над i поставим. Шаблоны (мета-модель) - первичны. Модель - вторична.
"конечному" программисту - "не надо думать" о шаблонах (мета-модели). Они есть. Априори. Они для него - аксиоматика.
"Я имею некоторый опыт применения ARIS"
Удалить-- я к сожалению не знаком с ARIS.
«Ну вы уж не "демонизируйте" меня и моих коллег :-)»
УдалитьЯ, кстати, сразу понял, что это Ваши коллеги :-)
Не потому, что «всегда зрю в корень», а потому, что это очевидно даже ребёнку.
«"Важно понять, какой набор вопросов придётся решать программисту при "программировании на шаблонах"."
-- "конечному" программисту - никакие. Шаблоны уже есть. И они - обычно работают. Если не работают, то всё - сложнее.»
-- Позвольте, это как это «никакие»? Разве «конечный программист» не создаёт свои части диаграммы для описания деталей проектных решений, которые сам и создаёт? Разве он не должен, в таком случае использовать шаблоны, чтобы конкретизировать, воплотить в коде эти решения?
«"Да, получается то, что Вы обозначили как "ограничения модели" очень важны."
-- это правда. Есть модель. И есть мета-модель. Мета-модель задаёт правила создания модели. Эти правила разрабатываются отдельно. Проектно-зависимые. Я надеюсь, что я отдельно про это напишу. Хотя уже "кое-что"написал. Жаль, что я не всё "могу донести". Если бы я тыкал бы "пальцем в монитор" - было бы сильно проще. Но я - напишу.»
-- А я могу порекомендовать (не навязать, не обязать, не потребовать) Вам простой способ как понятно «потыкать пальцем». Представьте себе, что Вы решаете задачу с настройками. Покажите соответствующие (использующиеся для её понимания) модель и метамодель. Выделите на рисунках фрагменты и пронумеруйте их. «Ткните пальцем» (сошлитесь на соответствующий индекс) объясняя связь модели с метамоделью.
Насколько я понимаю, «метамодель» это сленг Ваш и Ваших коллег. Вы понимаете о чём речь, я же могу только догадываться, поскольку это нестандартная терминология, и её можно трактовать произвольно, что бесполезно.
«"Приведите примеры этих шаблонов, обозначьте, почему шаблоны необходимы в данном случае (или, почему они не нужны в нём)."
--вот тут есть скользкий момент. Они на том самом "криптованном" языке. От которого мы избавляемся.»
-- Но ведь можно же приводить эти шаблоны на некоем идеализированном языке, или на языке, на который вы переходите. С комментариями разумеется. Здесь не нужно много писать (я не ожидаю, что ради меня Вы и Ваши коллеги будете трудиться ночами — это для коллег) — достаточно просто проиллюстрировать основную идею и указать, с какими понятиями придётся работать на уровне шаблонов.
«"* Как произойдёт синхронизация настройки при интерактивном изменении её пользователем с активными реализациями прецедентов, использующих эту настройку?"
publisher/subscriber - выводимые из связей модели»
Вы говорите о выводимости. Что Вы имеете ввиду? На каком уровне производится эта «выводимость»? Я допускаю, что в диаграмме классов для настройки Вы можете предусмотреть соответствующее событие (publisher), но из чего следует, что на это событие следует «подписываться» если между объектом, определяющим настройку и прецедентом, где она потребляется в UML установлена связь использования?
Далее, что появляется в результате «вывода», о котором Вы сказали? Заготовка в шаблоне, в которую следует внести код, обеспечивающий реакцию на изменение настройки?
«"-- да мы это представляем себе. И не раз сталкивались. Более того у нас мета-модель не позволяет прецедентам НАПРЯМУЮ использовать друг-друга. Точнее (РЕАЛИЗАЦИЯМ прецедентов).»
УдалитьСтрелка класса ”uses” мне представляется именно *прямым* использованием."
-- "Точнее (РЕАЛИЗАЦИЯМ прецедентов)" - я не зря это написал :-) Прецеденты - друг друга напрямую - МОГУТ использовать (на уровне модели ТЗ) РЕАЛИЗАЦИИ - нет. Реализации прецедентов - это ПРОЕКТНЫЕ классы. Они реализуют прецеденты из ТЗ. Связью realization. И реализации прецедентов друг про друга ничего не знают. Друг про друга знают только прецеденты.»
Что Вы понимаете под реализацией прецедентов? Сказанное Вами можно понять так, что прецедент содержится на UML-модели, а реализация — это связанный с фрагментом UML-модели шаблон. Если так, то как же «не знают», если между соответствующими прецедентами установлена связь? Вы кстати, что-то говорили о пространствах имён в этой связи. Можно домыслить это как подключение соответствующих модулей в шаблон реализации модели, приводящий к появлению связи модулей в результирующем коде.
Домысливать дальше не хочу — м.б. лучше Вы внесёте ясность?
«"Но это опять увеличивает его связность, особенно, если принять во внимание иерархичность его организации."
-- а вот тут - нет. Связность не увеличится. Шаблоны- тоже иерархичные. С ДРУГОЙ иерархией.»
-- Да какая разница :-) На связность иерархичность никак не влияет. Просто у Вас она становится двумерной: помимо горизонтальной (явные стрелки), появляется ещё и вертикальная (вложенность). И разновидности иерархий, как правило, понимание не упрощают, поскольку усложняются ассоциации между связанными понятиями. Например, мне известно «это», как получить «то», если «это», скажем, элемент модели, а «то» - элемент её реализации.
Ну ладно, здесь я спор начинать не собираюсь, поскольку это может быть делом вкуса, привычки, осведомлённости, соглашений и даже технологических подходов.
«"Вот и возникают у меня вопросы относительно порога входа, времени, требующегося на изучение существующего, методик и парадигм, а также затрат на ведение UML-кодо-хозяйства."
-- у новых сотрудников - затрат "никаких" кроме освоения "мета-модели". Но она - интерактивна. Редактор моделей - сам тебя ведёт. Он не даст сделать что-то отличное от мета-модели. Новым сотрудникам говорят - "ну вот так устроен мир". Если в этом устройстве что-то не так - мы либо правим шаблоны, либо обучаем новых сотрудников - как это сделать самим. Второе - конечно - сложнее.»
-- Здесь было бы замечательно проиллюстрировать Ваши слова примером метамодели.
«"А в Вашем случае он есть, да ещё и записанный в форме шаблонов."
-- одно уточнение. В шаблонах записан не код. А ПРИНЦИПЫ генерации кода. Это ВАЖНО.»
-- Это то немногое, что мне известно :-) Я видел примеры ваших шаблонов, понимаю, что там описано то, что Вы обозначаете как «принципы генерации». Но в этих «принципах» участвуют фрагменты кода, которые «при раскрутке» формируют код результирующий.
Если же Вы стали сейчас говорить о «принципах генерации кода», то было бы замечательно увидеть хотя бы один пример с описанием «раскрутки» его в исходный код.
«"Настройку для начала нужно найти в диаграмме. Как это сделать?"
Удалить-- если я правильно понял вопрос, то - функцией поиска. По стереотипу. У нас поиск - продвинутый. По многим параметрам умеет искать.»
-- Т.е. как я понимаю, у вас реализован поиск по диаграмме, с учётом её иерархичности. Я правильно понимаю?
Только что значит «поиск по стереотипу»? Что Вы вкладываете в понятие «стереотип» здесь?
«"но какой обобщённый способ анализа Вы видите?"
-- я сам бы хотел себе ответить на этот вопрос :-) но если я на него отвечу, то скорее всего - я буду работать в другой организации :-)»
-- Это в высшей степени странно. Вероятно, Вы меня не правильно поняли.
«"Иными словами, как, имея диаграмму и шаблоны"
-- давайте только точки над i поставим. Шаблоны (мета-модель) - первичны. Модель - вторична.
"конечному" программисту - "не надо думать" о шаблонах (мета-модели). Они есть. Априори. Они для него - аксиоматика.»
-- Хорошо, а о чём ему («конечному программисту») *надо* думать? Если я правильно Вас понял, он при решении конкретных задач по проекту рисует *фрагменты* общей диаграммы UML, описывающей весь проект и связывает их с кодом. Посредством чего он осуществляет это связывание? Где он пишет код?
"а реализация — это связанный с фрагментом UML-модели шаблон."
Удалить-- Это не так. Есть UseCase. Есть UseCaseRealization. В RUP. Обо они - элементы модели.
"то было бы замечательно увидеть хотя бы один пример с описанием «раскрутки» его в исходный код."
Удалить+ spell и DoSpell
-- там много чего написано.
" Где он пишет код?"
Удалить-- в IDE.
"Что Вы вкладываете в понятие «стереотип» здесь?"
Удалить-- то же что и в остальных местах. СТЕРЕОТИП - это одно из основных понятий UML. Тут уж простите - "читайте Лармана" или Фаулера.
Стереотип - это стереотип. Краеугольный камень UML.
http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D1%80%D0%B5%D0%BE%D1%82%D0%B8%D0%BF_(UML)
Настройка это стереотип UseCaseSetting. реализатор настройки - SettingsHolder.
«"то было бы замечательно увидеть хотя бы один пример с описанием «раскрутки» его в исходный код."
Удалить+ spell и DoSpell
-- там много чего написано.»
-- К сожалению, не убеждён, что понял Вас здесь. Фрагмент "+ spell и DoSpell" у меня никаких ассоциаций не вызывает. Увы, я не могу всего знать и догадываться об очевидных вещах. Если можно - поясните, что Вы имели в виду.
«" Где он пишет код?"
-- в IDE.»
-- А как же он связывает создаваемый им в IDE код с разработанным им же фрагментом UML-диаграммы?
«"Что Вы вкладываете в понятие «стереотип» здесь?"
-- то же что и в остальных местах. СТЕРЕОТИП - это одно из основных понятий UML.»
-- Этого достаточно :-) Я знаю, что такое "стереотип" в UML.
Не понимаю только, что Вы имели ввиду, когда сказали "поиск по стереотипу", упомянув к тому же, "много параметров"?
««Особенно про "нового сотрудника" - сложная тема.»
Удалить-- Если нужно, я могу рассказать как такой "новый сотрудник" будет решать задачу в нашей организации.
--расскажите.»
-- Я представлю упрощённую схему, если появятся вопросы — я готов на них ответить.
1. Начинается всё с того, что аналитик пишет постановку, в которой излагает требования относительно новой настройки и согласует имя настройки с ответственным на проект.
2. Далее, он открывает форму ввода настроек в дизайнере, добавляет в источник данных, соответствующий настройкам новое поле, имя которого было согласовано в предыдущем пункте. Определяет тип поля и параметры его визуализации.
3. После чего постановка и форма отдаются в реализацию, как элементы задачи для программистов.
4. Программист в соответствующем модуле определяет параметр приложения, соответствующий настройке и публикует его в общем хранилище. В сущности, это создание экземпляра соответствующего класса и его настройка с указанием идентификационного имени, согласованного в первом пункте, типа и значения по-умолчанию. Хранилище — это объект, в котором хранятся параметры. Публикация — включение нового параметра в хранилище.
Посредством подписки на соответствующее событие в хранилище изменения значений параметров можно отслеживать.
Такие события происходят как при загрузке параметров из внешнего источника (например, конфигурационного файла), так и при изменении параметров интерактивно, пользователем.
5. Дальше есть варианты, как обеспечить применение настройки, для которой создан параметр в хранилище. Здесь всё зависит от того, на что эта настройка будет влиять и как она будет проявляться для пользователя. В примере с текстовым редактором достаточно подписаться на событие подготовки контейнера текстового редактора и создать объект обработчик — реализующий нужную функциональность, связанную с настройкой. В приведённом примере эта функциональность будет сводиться к своевременному (т. е. соответствующему моменту изменения параметра хранилища) изменению соответствующего свойства текстового редактора.
Собственно, работа программиста (в плане настроек) сводится к:
1. определению параметра в хранилище
2. реализации обработчика нужной функциональности для применения параметра хранилища и реакции на его изменения
Наверное, следует добавить, что относительно формы ввода параметров дополнительных действий обычно не требуется, поскольку основную работу по её изменению сделал аналитик, добавив туда соответствующий контейнер элемента управления, и низкоуровневый по отношению к проекту код, который связывает элементы хранилища с источником данных на форме ввода (упомянут в п.2).
NameRec, Вы еще тут? :) Мне кажется Шура, упускает из виду тот момент, что у нас, внутри, за много лет использования шаблонной генерации трансформировалось само понятие UML, как такового, и сейчас уже не совсем соответствует тому что принято думать о нем во внешнем мире, поэтому вы с ним как бы немного на разных языках говорите. Если Вы еще тут и Вам еще интересно, могу попробывать "перевести"
Удалить«NameRec, Вы еще тут? :)»
Удалить-- Нет, я здесь :-)
«Мне кажется Шура, упускает из виду тот момент, что у нас, внутри, за много лет использования шаблонной генерации трансформировалось само понятие UML, как такового, и сейчас уже не совсем соответствует тому что принято думать о нем во внешнем мире, поэтому вы с ним как бы немного на разных языках говорите.»
-- Да-да, он это точно упускает :-) В этом контексте забавно выглядят его отсылки к Фаулеру по поводу стереотипов UML в ситуации, когда я уже теряюсь: где стандартная терминология UML, а где ваш внутрикорпоративный сленг :-)
«Если Вы еще тут и Вам еще интересно, могу попробывать "перевести"»
-- Да, я здесь, мне интересно и с моей стороны приветствуются любые разъяснения.
В частности, мне было бы очень интересно получить разъяснения, сформулированные здесь (http://18delphi.blogspot.com/2013/09/uml_5682.html?showComment=1380240569192#c3467163963108642300)
Особенно, в части того, как "конечный программист" связывает разработанную им часть UML-модели с кодом, который со слов Александра, он создаёт в UML.
Не знаю, читали ли Вы, скажем так, не удачно опубликованное на харбре "интервью" со мной и Шурой, там много воды, имхо, но есть и полезные вещи, в частности как раз про то что мы подразумваыаем под УМЛ. Не предлагаю Вам ее читать, просто для начала приведу от туда пару цитат, что бы не чипятать текст заново. Но если вы вдруг ее уже видели, то скажите, что бы я не копировал то что вы уже прочитали. А я пока ее постараюсь найти... :)
Удалить«Не знаю, читали ли Вы, скажем так, не удачно опубликованное на харбре "интервью" со мной и Шурой»
Удалить-- Я читал интервью Всеволода Леонова (http://blogs.embarcadero.com/vsevolodleonov/2013/08/02/whyumlru/) с Александром и Максимом Крыловым.
Как я понимаю, Максим Крылов - это Вы.
Интервью читал, моё общение с Александром началось по его мотивам.
По большому счету, UML для нас лишь конкретная нотация знакомая большинству, «форма стрелочек и квадратиков», важен не она, а принцип действия, т.е. то, что мы с ним делаем и как.
УдалитьОсновная проблема использования UML в «классических» инструментах в том что, кодогенерация жестко связана с предопределенной статической метамоделью. Вы не можете (или почти не можете) изменить ни одно, ни другое. Ни изменить, ни расширить, ни поменять правила или задать новые специфические. Главное, что классики не раскрыли широкой публике, а «классические инструменты» не реализовали, это потенциал UML именно с точки зрения мета-конструирования. Создания собственных метамоделей со своей специфической кодгенерацией. И вот тут ключевую роль начинает играть понятие <>, о котором говорит Александр. Стереотип позволяет нам определить группу специфических метаклассов с привязкой к ним произвольной кодогенерации. Фактически, с помощью стереотипов, вы формируете произвольную мета-модель, которая автоматически становится вашим собственным DSL, трансформирующим квадратики в код, по любым правилам которые вы реализуете.
Собственно UML описывает у нас мета-мета-модель, т.е. правила формирования правил. Дальше мы определяем мета-модель, вводя в нее любые нужные нам понятия. Например, мы можем определить для Delphi возможность множественного наследования. Затем привязываем к этой метамодели правила преобразования ее элементов в код (или любые другие артефакты, например в документацию, вспомогательные файлы и т.д.). В примере с множественным наследованием это может быть трансформацией в одиночное наследование плюс агрегацию, но при этом так, что с точки зрения программиста это будет выглядеть именно как 100% наследование. Наконец, мы создаем реальные модели своей предметной области, но уже оперируя не тем, что нам изначально предложили «классики», а всем тем арсеналом, что мы сами придумали на мета-уровне и получаем из них готовый код произвольной сложности.
Те ВЫШЕ то что перечислял Шура, это уже не ВОБЩЕ НЕ UML, это все уже наш DSL, те все эти UseCaseSetting и тд, это уже понятия из метамодели, из которых конечный программист и конструирует приложение.
Шура ни как не привел КОНКРЕТНЫЙ пример 2на пальцах" что такое "наш юмль", я ниже попробую
А сорри, уже запостил выдержки из него. Впрочем они ключевые имено с тз того почему наш умл не умл вовсе :)
УдалитьЛан, сейчас примерчик сварганю, думаю отталкиваясь от него понятнее весь механизм будет
с конкретной метамоделью, моделью, шаблоном и кодом..
Удалить«сейчас примерчик сварганю, думаю отталкиваясь от него понятнее весь механизм будет
Удалитьс конкретной метамоделью, моделью, шаблоном и кодом..»
-- Да, это было бы ***очень интересно***.
в процессе... :)
Удалитьотвлекаться приходится, разумеется, работа, дети )
Да я не так, чтобы спешу... :-)
Удалитьок, сегодня уже не успею, но в понедельник думаю покажу... единственное, не пойму как тут имиджы прикладывать :(
УдалитьШур, мож я тебе просто матерьял скину тогда, а ты запостишь как новый пост?
УдалитьМакс, ты сам можешь пост написать. Я же тебя добавлял.
УдалитьПример порождения стереотипов. Не самый удачный. И не совсем "раскрутка". Но как уж есть.
Удалитьhttp://18delphi.blogspot.ru/2013/09/blog-post_5343.html
И ЕЩЁ РАЗ - "конечный программист" - подобное не программирует. Он только этим пользуется.
"с конкретной метамоделью, моделью, шаблоном и кодом.."
Удалить-- да, Макс. Для "выдуманного" языка :-)
"Я допускаю, что в диаграмме классов для настройки Вы можете предусмотреть соответствующее событие (publisher), но из чего следует, что на это событие следует «подписываться» если между объектом, определяющим настройку и прецедентом, где она потребляется в UML установлена связь использования?"
Удалить-- из чего следует? из стрелочки dependency - к соответствующим настройкам. Если кто-то заинтересован в знании об изменении настройки - он ставит стрелочку. И получает соответствующий код subscriber'а.
«ок, сегодня уже не успею, но в понедельник думаю покажу..»
Удалить-- Ну, пока Вы создаёте пример применения Вашей технологии разработки, не могли бы кратко обозначить: с чего Вы начали, к чему перешли, чем продолжили?
Например, Вы начали с создания мета-модели или воспользовались существующей, удалив из неё "всё лишнее"?
Отдельно и дополнительно.
ОтветитьУдалитьРазъяснения относительно ВойныИМира.
Данное слово кэмелкейсом появилось в следующем контексте:
««Хорошо. Я обязательно напишу. Хотя не все слова понял. Например "Методика применения" - это что? Инструкция как применять?»
-- Именно так. Необязательно сочинять здесь ВойнуИМир :-) Нужно указать просто, как технологически выглядит процесс добавления новой настройки.»
Не знаю как у других, я воспринимаю слово "инструкция" стандартным образом (http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F), как " документ, содержащий правила, указания или руководства, устанавливающие порядок и способ выполнения или осуществления чего-либо".
Как правило, такие документы весьма подробны, объёмны и требуют основательной подготовки для создания.
Описание методики применения в моём понимании - это несколько фраз, наводящих на мысли об ожидаемых действиях и способах применения. Это - не инструкция.
Упоминание "ВойныИМира" было призвано явно обозначить, что много текста я не требую, не прошу и не ожидаю.
Если Вас Александр, это задело - *прошу прощения*.
Просто для меня неожиданно выясняется, что мне очень непросто предсказать Вашу реакцию и реакцию местного окружения.
На будущее (к Александру не относится).
Господа! Если вам хочется что-то мне сказать - скажите это мне лично. Мой почтовый ящик указан в моём профиле (кстати, специально для этой цели). Ваши попытки морализаторства меня, откровенно говоря, не впечатляют. На всё это есть, что ответить, просто не думаю, что комментарии в данном блоге - лучшее для этого место.
Значит так.
УдалитьЯ не хочу ругаться. Ни с кем. А тем более на просторах интернета.
Я свою позицию - озвучил. Виктор (неожиданно для меня) её - расшифровал.
Давайте не будем ругаться. Учтём "претензии" и замечания друг к другу и будем конструктивно вести разговор о технологиях.
Про "усть-урюпинск" - это конечно жёстко. Я сам не ожидал. Но я знаю Виктора как адекватного, взвешенного и разумного человека. И очень спокойного. Так что раз он написал это - значит были серьёзные причины.
Про NameRec'а я в некотором роде знаю "background". Посему "прикрываю глаза" на общение "свысока". Но пожалуй не стоит этим злоупотреблять.
Надеюсь - мы собрались сюда не ругаться и не раздувать флейм, а вести дискуссию о технологиях программирования.
Посему - призываю прислушаться друг к другу. Сделать вываоды. Быть "мяхше" и корректнее.
И предлагаю считать инцидент исчерпанным.
И ещё. Для NameRec.
УдалитьЯ писал вам лично уже об этом.
Был у меня такой преподаватель.
Нечаев Анатолий Михайлович.
ОЧЕНЬ умный. Но "резкий".
И считал, что "все студенты равны" и что "всех надо строить".
На почве этого мы и не сошлись. Жаль кстати.
В итоге - я покинул ВУЗ, недоучившись.
Хотя Нечаева считаю - ЦЕННЫМ специалистом.
Вот так как-то...
Я не считаю, что я - "очень уж прав"...
Но.. Разумным людям по-моему - свойственно делать правильные выводы и из чужой неправоты тоже. Не "банальные".
Я специально это в блоге пишу. А не лично. Не потому что это message вам. Это message - всем. И мне кстати- тоже...