пятница, 27 сентября 2013 г.

Об "общей" модели системы

У нас система - далеко не самая сложная. Но - сложная.

Диаграмма пакетов верхнего уровня выглядит примерно (примерно - потому, что там внизу ещё примерно экран не поместился) так:



Я не знаю пока делать с этой диаграммой. Посему об "общей" модели - стоит забыть.

Если кому-то кажется, что я привёл эту диаграмму "по глупости" и "с кандачка", то он - СИЛЬНО заблуждается. Я привёл эту диаграмму ОСОЗНАННО.

Сложность и запутанность этой диаграммы ПОКАЗЫВАЕТ не сложность и запутанность UML. Она показывает РЕАЛЬНУЮ сложность РЕАЛЬНОЙ системы.

До тех пор пока эта диаграмма не была нарисована - о сложности системы - "никто не подозревал".

И таких диаграмм была уже МАССА нарисована. И на основе их анализа было проведено упрощение системы и её тотальный рефакторинг.

Тех диаграмм, что внутри.

Это же - ОБЩАЯ диаграмма всего процесса. ВСЕГО предприятия если хотите.

Да - она сложная и запутанная. Но это означает, что процесс - сложный. И что его надо упрощать. Как? Пока - никто не знает.

Если найдутся умники "говорящие фуу как сложно" - один совет - нарисуйте общую диаграмму ВАШЕГО предприятия. И посмотрите на неё. И потом только - высказывайте оценки.

И эта диаграмма НЕ бесполезна. Бесполезную работу я В ПРИНЦИПЕ стараюсь не делать. Чего и всем желаю.

59 комментариев:

  1. Да Александр...
    Как Вы любите всё запутать...
    С одной стороны, Вы говорите о преимуществах UML как графической нотации, которая (читай, по своей природе) человеку ближе, что всё нагляднее с UML и понятнее. Упоминаете диаграмму мета-модели, которая способствует навигации и способствует не только осознанию замысла, но и принятию правильных решений.
    С другой - приводите этот хичкоковский триллер, причём говорите, что весь его показать не можете, поскольку "не уместилось"...
    В итоге предлагаете забыть об "общей модели".
    А о чём тогда помнить, Александр?
    Зачем рисовать модель, которая недоступна для анализа и, в сущности, бесполезна? Как и кто использует то, что Вы показываете здесь в виде картинки?
    Этим не пользуются? Но тогда зачем это приводить здесь?
    Вы говорили о мета-модели, которая первична, модели, которая вторична. Упоминали также про мета-мета модель. Может быть, их приведёте? Хотя бы, корневой элемент в иерархии и один-два фрагмента "внтури". Уж они-то должны быть понятны? Ведь их осваивают Ваши новые сотрудники, ну и нам может быть, станет чуть более понятно...
    Далее, когда я говорил о совокупной диаграмме, мне казалось, что в контексте неоднократно упомянутой нами обоими иерархичности - понятно, что имеется ввиду вся совокупность диаграмм в их проектной иерархии.
    Такая совокупность должна быть обозрима, по ней должны быть развитые средства навигации, по меньшей мере, не уступающие существующим для кода.
    Я (и, вероятно, не только я) хотим убедиться, что ваши диаграммы - это действительно новый уровень представления, который позволяет работать меньше, а сделать - больше. Производительность труда поднять, выражаясь канцелярским языком.
    Вернусь к Вашему предложению "забыть об "общей" модели". Но с чем работает "конечный" программист? В общении с Вами у меня сложилось представление, что он работает с фрагментом диаграммы модели, со "своей" частью, или частью, в которую он вносит изменения.
    Как "конечный" программист находит этот фрагмент диаграммы для написания в IDE кода к ней? Как код увязан с диаграммой? Или там уже нет UML? Вариантов - уйма. Оперировать можно только домыслами. Я этого не люблю, потому и спрашиваю Вас прямо.
    Если вступительная часть этого поста Вас задела - извините. Но мне казалось, что не лишне Вам получить обратную связь на ту форму подачи материала, которую Вы выбрали.

    ОтветитьУдалить
    Ответы
    1. "Как Вы любите всё запутать..."

      -- наше с вами общение можно заканчивать?

      Удалить
    2. "Упоминали также про мета-мета модель. Может быть, их приведёте?"
      -- простите, но для вас - хватит и той информации, которую я УЖЕ привёл... мне так почему-то кажется...

      Удалить
    3. "Зачем рисовать модель, которая недоступна для анализа и, в сущности, бесполезна? Как и кто использует то, что Вы показываете здесь в виде картинки?
      Этим не пользуются? Но тогда зачем это приводить здесь?"
      -- простите - я считаю это - хамством. Вынужден откланяться.

      Удалить
    4. Откинув личные обиды...

      "Вы говорили о мета-модели, которая первична, модели, которая вторична. Упоминали также про мета-мета модель. Может быть, их приведёте? Хотя бы, корневой элемент в иерархии и один-два фрагмента "внтури". Уж они-то должны быть понятны?"
      -- Макс вам обещал же пример. Я думаю, что быстрее и лучше его - я не сделаю.

      Вы вроде бы сказали, что не торопитесь.

      Удалить
    5. «"Вы говорили о мета-модели, которая первична, модели, которая вторична. Упоминали также про мета-мета модель. Может быть, их приведёте? Хотя бы, корневой элемент в иерархии и один-два фрагмента "внтури". Уж они-то должны быть понятны?"
      -- Макс вам обещал же пример. Я думаю, что быстрее и лучше его - я не сделаю.

      Вы вроде бы сказали, что не торопитесь.»
      -- Всё точно. Именно так.
      Но "не тороплюсь", не значит, что не *жду с нетерпением* :-)
      На самом деле - мне действительно *очень интересно*. Мне кажется, что по крайней мере мне, удалось сдвинуться с "мёртвой точки" и несколько продвинуться "вглубь", к пониманию что и откуда у вас берётся.
      В параллельной теме Вы упомянули про "мимикрию кода" - это стало точкой опоры для меня, поскольку ранее, многое из сказанного Вами, будучи вырванным из контекста, не воспринималось мною должным образом.
      Мне кажется, что способ подачи материала очень важен, Александр. Вне контекста даже самое тривиальное утверждение будет воспринято произвольно. Т.е. истолковано. А толкования - не уровень науки и не инструмент технологии. Я отчаянно стремлюсь от этого произвола и толкований уйти. Прошу воспринимать то, что я пишу именно в этом контексте. И я далёк от мысли критиковать системы, к которым не имею отношения.

      Удалить
    6. "Мне кажется, что способ подачи материала очень важен, Александр."
      -- ну вы тожже не "гений общения" :-) хотя и меня многие "на дух не переносят"...

      Но ведь - общаемся же...

      Если вы будете конструктивно указывать на недостатки "формы" - мы все от этого выиграем...

      Удалить
    7. "В параллельной теме Вы упомянули про "мимикрию кода" - это стало точкой опоры для меня, поскольку ранее, многое из сказанного Вами, будучи вырванным из контекста, не воспринималось мною должным образом."
      -- а я ТОЛЬКО когда ВАМ это объяснил - ПОНЯЛ - НАСКОЛЬКО это важный момент.
      Так что - спасибо даже.

      Удалить
    8. " Т.е. истолковано. А толкования - не уровень науки и не инструмент технологии. Я отчаянно стремлюсь от этого произвола и толкований уйти. "
      -- ну вы - преподаватель, а я - нет. Так что - делайте скидку.

      Только не думайте, что "практик" может придумать, что-то "хуже" преподавателя. Только - объяснить не может.

      Удалить
    9. >>Но "не тороплюсь", не значит, что не *жду с нетерпением* :-)

      я уже на половину закончил )) не знаю... опубликовать как "первую часть" или уже все сразу.. просто первая без второй может не очень интересной показаться, имхо.

      Удалить
    10. То, что я увидел в черновике - это круто. Я бы - опубликовал бы.

      Удалить
    11. «я уже на половину закончил )) не знаю... опубликовать как "первую часть" или уже все сразу.. просто первая без второй может не очень интересной показаться, имхо.»
      -- Мне было бы интересно посмотреть на первую часть до того, как Вы закончите вторую :-)
      В любом случае появятся вопросы.

      Удалить
  2. «Да - она сложная и запутанная. Но это означает, что процесс - сложный.»
    -- Не только. Чаще это как раз указывает на то, что выбран неверный описательный язык.
    Приведу пример: когда Вы смотрите на чужую программу, которая неряшливо оформлена, в которой не проведена декомпозиция, в которой зашкаливает связность и обилие не очевидных зависимостей, Вы вероятно скажете: "так быть не должно".
    И начнёте думать, как упростить это, если "это" представляет для Вас какую-либо ценность. Я не стану рассказывать о декомпозиции, о выделении родственных сущностей и формализации связей в предметной области - Вы опять скажете, что я Вас с кем-то путаю. Но это как раз тот путь, о котором Вы говорите, что его-де "никто не знает". - Знает, Александр. Знает.

    «Если найдутся умники "говорящие фуу как сложно" - один совет - нарисуйте общую диаграмму ВАШЕГО предприятия. И посмотрите на неё. И потом только - высказывайте оценки.»
    -- На правах "умника", который сказал то, что Вы вольно интерпретировали как в процитированном фрагменте, скажу: не рисовал и пока не собираюсь. Есть другие методы анализа предметной области, о которых Вы, кстати, с Ваших слов, осведомлены. Более того, утверждали, что для Вас это - пройденный этап. Простите, но если этот этап "пройден", то откуда эта диаграмма, после приведения которой Вы предлагаете "забыть об "общей" модели"?

    «"Как Вы любите всё запутать..."

    -- наше с вами общение можно заканчивать?»
    -- Александр, мы в Интернете :-)
    Закончить Вы можете в любой момент - просто не отвечайте.

    «"Упоминали также про мета-мета модель. Может быть, их приведёте?"
    -- простите, но для вас - хватит и той информации, которую я УЖЕ привёл... мне так почему-то кажется...»
    -- Да, наверное, Вы правы :-)

    «"Зачем рисовать модель, которая недоступна для анализа и, в сущности, бесполезна? Как и кто использует то, что Вы показываете здесь в виде картинки?
    Этим не пользуются? Но тогда зачем это приводить здесь?"
    -- простите - я считаю это - хамством. Вынужден откланяться.»
    -- Вы не там ищите хамство, Александр. Оправдываться перед Вами я не собираюсь, я и так здесь извиняюсь больше, чем в трамвае в час пик. Произвольно трактовать что угодно Вам никто запретить не может. И откланяться - тоже. Просто не валите с больной головы на здоровую...

    ОтветитьУдалить
    Ответы
    1. ""формализации связей в предметной области" - вот тут к сожалению - я далеко не всегда властен. Тут есть "заказчики".

      И любая формализация может выйти "боком".

      Я кстати писал немного об этом - http://18delphi.blogspot.ru/2013/09/blog-post_16.html

      Формализация - она хороша. И я ОБЕИМИ руками за неё. Но! "Заказчики" - далеко не всегда её понимают.

      Бывает - ДВЕ сущности - одинаковые. Вообще - мама родная не отличит. Но "Заказчики" хотят от них "совершенно разного поведения". По неформальным признакам. И тут - никакие формальные методы не работают.

      Только если шаблонизация в терминах UML и UseCase'ов."

      Удалить
    2. "которая неряшливо оформлена, в которой не проведена декомпозиция"
      -- будем считать, что у вас такой "сленг"?

      Он кстати - неуместен.

      Пока я общался с коллегами в вашем стиле - я тоже не получал должного отклика.

      По сути - да диаграмма неряшлива, да - декомпозиция - не проведена. Но это сделано - осознанно.

      Декомпозицию - провести НЕЛЬЗЯ - поскольку это РАЗНЫЕ проекты. Тут возникает вопрос - ОРГАНИЗАЦИИ труда.

      Неряшливо - да. Можно убрать лишние стрелки и сделать красиво. Но это не уменьшит сложности САМОЙ системы.

      Удалить
    3. "Пока я общался с коллегами в вашем стиле"
      -- я тоже любил слова типа "говно-код" или "ну что вы не знаете о полиморфизме".. Поверьте - подобное ставит в тупик всё общение.

      Удалить
    4. «""формализации связей в предметной области" - вот тут к сожалению - я далеко не всегда властен. Тут есть "заказчики".

      И любая формализация может выйти "боком".

      Я кстати писал немного об этом - http://18delphi.blogspot.ru/2013/09/blog-post_16.html

      Формализация - она хороша. И я ОБЕИМИ руками за неё. Но! "Заказчики" - далеко не всегда её понимают.

      Бывает - ДВЕ сущности - одинаковые. Вообще - мама родная не отличит. Но "Заказчики" хотят от них "совершенно разного поведения". По неформальным признакам. И тут - никакие формальные методы не работают.

      Только если шаблонизация в терминах UML и UseCase'ов."»
      -- Александр, я здесь опять вырван из контекста. Я не понимаю, о чём Вы говорите.
      С одной стороны, у меня нет оснований Вам не доверять в том смысле, что есть некая проблема, которую Вы с коллегами научились решать средствами шаблонизации.
      С другой, я по нескольким проектам сталкиваюсь с подобным каждый день и ни в какой шаблонизации недостатка не испытываю.
      Есть разные подходы к решению задач. Иногда они дают результат со сходными характеристиками.
      Я не люблю говорить отвлечённо, поскольку такая мета-информация, по моему опыту *никогда* не воспринимается должным образом. Но кое-какой свет на проблемы с которыми Вы столкнулись проливает материал, на который Вы сослались (http://18delphi.blogspot.ru/2013/09/blog-post_16.html).
      Так вот, мы, столкнувшись с похожими проблемами стали их решать иным способом. Грубо утрируя, *абсолютно* разделили представление и контроллер. Эти вещи даже создают разные люди. Как - я написал в комментарии относительно нашего подхода к реализации настроек-параметров приложения.
      Но это всё отвлечённо, неконкретно, без иллюстративных примеров и той методики, которая в данном случае не инструкция, а выражаясь Вашим языком, мета-инструкция. Поэтому развивать мысль не решусь.

      Удалить
    5. не.. не.. не...
      ссылка была приведена лишь как "косвенный пример"...
      про представление и контроллер - мы тоже знаем.. и тоже используем...

      я о проблеме НА БОЛЕЕ высоком уровне...

      попробую "на пальцах" объяснить... есть прецедент "Просмотр документа" и есть прецедент "Просмотр консультации"...

      Они - ОЧЕНЬ родственные.. обладают ОБЩЕЙ функциональностью... но имеют и различия... КОНСУЛЬТАЦИЯ вообще говоря УЖЕ, чем ДОКУМЕНТ... И кажется, что Консультация должна быть предком ДОКУМЕНТА.. ну или они должны иметь ОБЩЕГО предка.. всё хорошо.. только ТРЕБОВАНИЯ меняются регулярно и стохастически... иногда вдруг говорят - давайте консультация будет ещё и обладать вот этими двумя свойствами документа.. а потом говоря - давайте эти три свойства уберём.. и так - неоднократно...и ПРЕЦЕДЕНТОВ на самом деле не ДВА, а МНОГО.. похожих... их можно сделать ОДНИМ прецедентом, но его тоже надо настраивать.. по "произволу заказчиков".. Но это непросто.. Вот мы и пилим на "кубики", а потом из кубиков собираем прецеденты. Це из Эн по Ка... И в "каждую" версию - комбинаторика - меняется... "Заказчики" - "ищут"... Надеюсь, что смог хоть, что-то объяснить...

      Удалить
    6. Контроллеров получается МНОГО и представлений - МНОГО...

      Банальная иерархия - не работает... Или её всё время "перетряхивать надо"...

      Удалить
    7. АСПЕКТОВ системы - МНОГО... и они по-разному - комбинируются...

      Есть ещё один "выход" сделать ОДИН универсальный прецедент и заставить его превращаться во всё, что хочешь.. Но это уж совсем как-то упадочно.. Хотя и выход...

      Удалить
    8. «которая неряшливо оформлена, в которой не проведена декомпозиция"
      -- будем считать, что у вас такой "сленг"?»
      -- Это был отвлечённый пример, призванный показать, как воспринимается информация, представленная в неструктурированном виде.

      «Он кстати - неуместен.»
      -- В Вашей интерпретации (переносе всего сказанного буквально и на себя лично) - безусловно.

      «По сути - да диаграмма неряшлива, да - декомпозиция - не проведена. Но это сделано - осознанно.»
      -- ?????????????!!!!!!

      «Декомпозицию - провести НЕЛЬЗЯ - поскольку это РАЗНЫЕ проекты. Тут возникает вопрос - ОРГАНИЗАЦИИ труда.»
      -- *Почему* нельзя произвести декомпозицию, даже если это разные проекты?
      Как обстоятельство существования разных проектов может препятствовать проведению функциональной и объектной декомпозиции предметной области?
      Ведь декомпозиция - суть, структурирование, чуть ли не самый первый эффективный способ ограничить субъективную сложность.

      «Неряшливо - да. Можно убрать лишние стрелки и сделать красиво. Но это не уменьшит сложности САМОЙ системы.»
      -- Сложность системы - объективна. Но она никого особенно не волнует до тех пор, пока в каждом фрагменте этой сложности не приходится иметь дело более чем с семью понятиями.
      Ведь для того, чтобы позвонить по телефону, не нужно знать "как идёт сингал", не нужно быть осведомлённым в "принципах связи", не нужно знать "кто клал кабель". В совокупности ведь это всё невероятно сложно, а на деле приходится иметь дело только с именем, смартфоном и виртуальными кнопками на нём...
      Отдельно прошу принять во внимание, что в моих словах нет ни тени, ни намёка на менторство (я Вас умоляю!), но просто для меня как-то очень уж странно слышать, что декомпозицию не проводят намеренно... Ну ладно бы это было стремление не абстрагироваться от сути при анализе, но уж не "много проектов" IMHO может быть аргументом для такого...
      Ну и ещё... По моим наблюдениям (не навязываю, можно не читать, игнорировать и вообще - послать) декомпозицию уместно проводить уже тогда, когда набор факторов, требуемых для учёта при анализе, начинает превышать обозримое количество, на что указывает, что в них становится сложно ориентироваться. Это не всегда возможно, и в этом сложность анализа, но плохая декомпозиция лучше её отсутствия, кроме того, есть признаки, указывающие на то, что она проведена неправильно. Но тогда можно вернуться в начало с учётом новых вскрывшихся обстоятельств.
      Ох... Сложно говорить отвлечённо. Ты понимаешь, о чём говоришь, а вот понимают ли тебя - очень не факт. Особенно, если норовят на рассуждения смотреть как на нравоучения. Нет их здесь. Не ищите...

      Удалить
    9. Ещё раскрою тему:
      В консультации не надо показывать оглавление. В документе -надо. В энциклопедиях - надо. В словарях - надо, но другое.
      В консультации -одна печать, В документе - другая, В энциклопедиях -третья, В словарях - опять же вторая.
      ...
      и так по каждому АСПЕКТУ прецедента... м ы ПЫТАЛИСЬ выделять иерархию, но она - сложно выделяется и меняется...

      Удалить
    10. "Как обстоятельство существования разных проектов может препятствовать проведению функциональной и объектной декомпозиции предметной области?"
      -- корневые элементы диаграммы это суть папки на файловой системе. Их моно конечно слить в одну. Но об этом тоже надо "думать". А разные папки - это разные настройки проектов. Поделил у себя на две. Свои настройки и ночную компиляцию поправил - а у коллег вылезло. И они - недовольны. Имеют право.

      Удалить
    11. Можно и мета-модель менять. Корневые элементы трансформировать. Упаковывать в "Матрёшку". Но опять же это - многих - касается.. А люди - консервативны...

      Удалить
    12. Скажем так - меняет - "один".. А укается - многим... Всей организации в пределе... Тут надо быть КРАЙНЕ осторожным...

      Удалить
    13. «попробую "на пальцах" объяснить... есть прецедент "Просмотр документа" и есть прецедент "Просмотр консультации"...

      Они - ОЧЕНЬ родственные.. обладают ОБЩЕЙ функциональностью... но имеют и различия... КОНСУЛЬТАЦИЯ вообще говоря УЖЕ, чем ДОКУМЕНТ... И кажется, что Консультация должна быть предком ДОКУМЕНТА.. ну или они должны иметь ОБЩЕГО предка.. всё хорошо.. только ТРЕБОВАНИЯ меняются регулярно и стохастически... иногда вдруг говорят - давайте консультация будет ещё и обладать вот этими двумя свойствами документа.. а потом говоря - давайте эти три свойства уберём.. и так - неоднократно...и ПРЕЦЕДЕНТОВ на самом деле не ДВА, а МНОГО.. похожих... их можно сделать ОДНИМ прецедентом, но его тоже надо настраивать.. по "произволу заказчиков".. Но это непросто.. Вот мы и пилим на "кубики", а потом из кубиков собираем прецеденты. Це из Эн по Ка... И в "каждую" версию - комбинаторика - меняется... "Заказчики" - "ищут"... Надеюсь, что смог хоть, что-то объяснить...»
      -- Смогли, если я правильно Вас понял :-)
      Ну, это то, о чём я и говорил. И подходы, кстати, очень похожи. Инструменты правда отличаются очень сильно, но метод - весьма сходен. Наверное, с тем отличием, что у нас исключительно редко проявляется наследование, гораздо чаще - динамическая композиция.

      «онтроллеров получается МНОГО и представлений - МНОГО...

      Банальная иерархия - не работает... Или её всё время "перетряхивать надо"...»
      -- Конечно не работает. Но композиция - вполне.

      «АСПЕКТОВ системы - МНОГО... и они по-разному - комбинируются...

      Есть ещё один "выход" сделать ОДИН универсальный прецедент и заставить его превращаться во всё, что хочешь.. Но это уж совсем как-то упадочно.. Хотя и выход...»
      -- Ну почему же - упадочно. Если обеспечить возможность его динамической специализации аспектами - вполне... Правда тут по ходу может оказаться, что аспект и прецедент меняются местами... Вообще же, по-моему здесь опять мы на разных языках...

      Удалить
    14. "гораздо чаще - динамическая композиция."
      -- вариант.

      Удалить
    15. "Конечно не работает. Но композиция - вполне."
      -- таки композицию применяем. А не только примеси. Но и в композиции - "Це из Эн по Ка". И там тоже UML - "помогает".

      Удалить
    16. «Ещё раскрою тему:
      В консультации не надо показывать оглавление. В документе -надо. В энциклопедиях - надо. В словарях - надо, но другое.
      В консультации -одна печать, В документе - другая, В энциклопедиях -третья, В словарях - опять же вторая.
      ...
      и так по каждому АСПЕКТУ прецедента... м ы ПЫТАЛИСЬ выделять иерархию, но она - сложно выделяется и меняется...»
      -- Да, интересно... Прям как у нас...
      В Вашем случае оглавление было бы выделено в отдельный аспект, разновидности печати - тоже. Если у разновидностей печати много общего - можно было бы выделить общего предка или агрегировать один объект.
      Далее, эти аспекты независимо (или зависимо, если нужно) комбинировались в разных вариантах использования...

      Удалить
    17. "Если обеспечить возможность его динамической специализации аспектами - вполне..."
      -- это и делаем. Когда статической, когда динамической.

      Удалить
    18. "В Вашем случае оглавление было бы выделено в отдельный аспект, разновидности печати - тоже. Если у разновидностей печати много общего - можно было бы выделить общего предка или агрегировать один объект.
      Далее, эти аспекты независимо (или зависимо, если нужно) комбинировались в разных вариантах использования..."
      -- именно так.

      Удалить
    19. "Ну почему же - упадочно"
      -- тут есть один момент - разделение труда. Разные люди работают в разных сферах. Сведи их вместе в один "мега-прецедент" - они начнут конфликтовать. Хотя бы за CVS/SVN. Ну ОЧЕНЬ грубо...

      Удалить
    20. И тут есть ещё один момент. Завтра приходит "заказчик" и говорит - "надо этот аспект убрать". Можно его "уговорить" конечно. Но он говорит (грубо говоря) - "попрут продажи". С этим - не поспоришь. Ну ладно - УБРАТЬ.. Это - "нехитро".. а если ДОБАВИТЬ? А если это и не аспект вовсе в терминах системы? Значит - надо выделять аспект.. да так, чтобы другое не разломать.. и быть готовым к тому, что завтра "заказчик" может поменять своё мнение... И так - далеко не только у нас... Я такое - от многих своих знакомых слышу...

      Удалить
    21. Это "заказчику" кажется, что убрать - "ничего не стоит"... Но мы же с вами - программисты.. Понимаем.. Но убрать - не только убрать.. А настройки переделай.. А может и данные... А тестирование проведи.. А сделай так, чтобы в соседних проектах ничего не отъехало... И т.д. и т.п.

      Удалить
    22. «И тут есть ещё один момент. Завтра приходит "заказчик" и говорит - "надо этот аспект убрать".»
      -- Убираете инициализацию соответствующего объекта-обработчика в данном контексте.

      «Это - "нехитро".. а если ДОБАВИТЬ?»
      -- Выполняете инициализацию соответствующего "паразита" в нужном контексте.

      «А если это и не аспект вовсе в терминах системы? Значит - надо выделять аспект..»
      -- Да. Но вот почему-то мне кажется, что в коде это сделать проще, чем через UML.
      Возможно, пока кажется.

      «да так, чтобы другое не разломать..»
      -- Ну, у Вас же тесты есть. У нас на них ресурсов не всегда хватает...
      Кроме того, если нужно срочно (а когда бывает по-другому?) можно временно смириться с дублированием, тем не менее, выполнив создание отдельного аспекта. Дальше нужно адаптировать существующий код, содержащий в себе элементы этого нового аспекта, заменив фрагменты на использование нового аспекта.
      Кстати, вот думаю... У нас такое происходит нечасто... Я про материал предыдущего абзаца. Наверное потому, что о потенциальном дублировании функциональности меня оперативно информируют, и рефакторинг часто опережает реальные требования к нему... Ну не всегда конечно.

      «и быть готовым к тому, что завтра "заказчик" может поменять своё мнение...»
      -- Ну да... Где-то так и случается. Впрочем сомневаюсь, что это повредит новому аспекту...

      Удалить
    23. "Ну, у Вас же тесты есть. У нас на них ресурсов не всегда хватает..."
      -- есть... в "пяти" проектах из "двадцати".

      Мы можем знать, что не разломали у себя. Но не гарантируем, что не разломали у коллег.

      Удалить
    24. "Кроме того, если нужно срочно (а когда бывает по-другому?) можно временно смириться с дублированием, тем не менее, выполнив создание отдельного аспекта. Дальше нужно адаптировать существующий код, содержащий в себе элементы этого нового аспекта, заменив фрагменты на использование нового аспекта."
      -- логично.. И так - тоже бывает.

      Удалить
    25. "Ну да... Где-то так и случается. Впрочем сомневаюсь, что это повредит новому аспекту..."
      -- не повредит конечно. Если аспект УЖЕ выделен и ОТТЕСТИРОВАН, в разных вариациях - это только на руку всей системе.

      Удалить
    26. «"Ну, у Вас же тесты есть. У нас на них ресурсов не всегда хватает..."
      -- есть... в "пяти" проектах из "двадцати".

      Мы можем знать, что не разломали у себя. Но не гарантируем, что не разломали у коллег.»
      -- Мнда... Надо дождаться всё-таки примера от Максима... :-)
      Как-то странно для меня выглядит то, что Вы сказали... Изменения в общей части обычно тестируются отдельно, если тесты системной части проходят нормально, то почему у коллег должно что-то "сломаться", если коллеги работают с протестированным кодом?

      Удалить
    27. «"Как обстоятельство существования разных проектов может препятствовать проведению функциональной и объектной декомпозиции предметной области?"
      -- корневые элементы диаграммы это суть папки на файловой системе. Их моно конечно слить в одну. Но об этом тоже надо "думать". А разные папки - это разные настройки проектов. Поделил у себя на две. Свои настройки и ночную компиляцию поправил - а у коллег вылезло. И они - недовольны. Имеют право.»
      -- Существенное дополнение... Очень интересно...

      Удалить
    28. " Мнда... Надо дождаться всё-таки примера от Максима... "
      -- вряд ли пример от Максима вам именно этот аспект прояснит. Он тестированием не занимается. Но - стоит дождаться.

      Удалить
    29. "Существенное дополнение... Очень интересно..."
      - да.. существенное.. сам не знал..

      Удалить
    30. "Как-то странно для меня выглядит то, что Вы сказали... Изменения в общей части обычно тестируются отдельно, если тесты системной части проходят нормально, то почему у коллег должно что-то "сломаться", если коллеги работают с протестированным кодом?"
      -- понимаете - у нас не TDD. а регресс-тесты и тесты прецедентов.
      Мы тестируем ошибки требования. И только "иногда" - проводим Unit-тестирование. Для особо критичных участков.

      Так что есть вероятность, что у нас НЕ сломается, а коллег сломается.

      Когда у них СЛОМАЕТСЯ - мы сделаем регресс-тест. И БОЛЬШЕ там ломаться не будет. НО это ТОЛЬКО когда ошибка уже была. А ВСЁ ПОКРЫТИЕ - мы не гарантируем. Да и не стремимся к этому. Это ОЧЕНЬ ДОРОГО.

      Удалить
    31. "В Вашем случае оглавление было бы выделено в отдельный аспект, разновидности печати - тоже. Если у разновидностей печати много общего - можно было бы выделить общего предка или агрегировать один объект."
      -- Приятно с умным человеком разговаривать.

      Удалить
  3. «"Ну почему же - упадочно"
    -- тут есть один момент - разделение труда. Разные люди работают в разных сферах. Сведи их вместе в один "мега-прецедент" - они начнут конфликтовать. Хотя бы за CVS/SVN. Ну ОЧЕНЬ грубо...»
    -- Вообще-то я не имел ввиду сваливать всё в одну кучу. Мне казалось, что можно выделить *простой* прецедент, к которому динамически можно подключать аспекты. Как это сделать в коде - я себе представляю. Как на UML - нужно подумать. Но вот тут, мне кажется, мы уже на разных языках говорим.
    Мы не оперируем в явном виде с понятиями UML - это не операционный язык для нас. У нас сильно другая терминология: объекты-автоматизации (редактор Ваш, к примеру), события в них, обработчики событий, объекты-обработчики (они же "паразиты"). Поскольку наиболее близкая аналогия - АОП, я использую её терминологию, тем более, что она пересекается с UML.
    У нас объект автоматизации практически никогда не функционирует непосредственно, ему практически всегда "помогают" специально настроенные уже упомянутые "паразиты", которые и отражают специфику прецедента в терминах UML.

    ОтветитьУдалить
    Ответы
    1. "Вообще-то я не имел ввиду сваливать всё в одну кучу. Мне казалось, что можно выделить *простой* прецедент, к которому динамически можно подключать аспекты."
      -- это - да. Не сваливать в кучу, а подключать.

      Удалить
    2. "Как это сделать в коде - я себе представляю. Как на UML - нужно подумать. Но вот тут, мне кажется, мы уже на разных языках говорим."
      -- на UML - ещё проще. Ну по крайней мере - для меня.

      Удалить
    3. "У нас объект автоматизации практически никогда не функционирует непосредственно, ему практически всегда "помогают" специально настроенные уже упомянутые "паразиты", которые и отражают специфику прецедента в терминах UML."
      -- логично. У нас - тоже. Я не зря про "контрольные точки" писал. Тут - http://18delphi.blogspot.ru/2013/04/blog-post_6244.html. Там правда про тестирование. Но мы эту технику и для программирования используем.

      Удалить
    4. Правда от "событий" (Event'ов) мы стараемся уходить. Используем что-то вроде publisher/subscriber или strategy.

      Удалить
    5. «-- логично. У нас - тоже. Я не зря про "контрольные точки" писал. Тут - http://18delphi.blogspot.ru/2013/04/blog-post_6244.html. Там правда про тестирование. Но мы эту технику и для программирования используем.»
      -- Вероятно, под "контрольными точками" Вы понимаете места подключения аспектов...

      Удалить
    6. "Вероятно, под "контрольными точками" Вы понимаете места подключения аспектов..."
      -- именно!
      Просто про контрольные точки я узнал раньше, чем про АСПЕКТЫ. И сам - "придумал" их в программировании. А потом оказалось, что "всё придумано до нас"..

      Удалить
    7. Понимаете - это ведь вы такой УМНЫЙ.
      И про аспекты знаете и про примеси. Многие ведь не знают "зачем виртуальность конструктору"..

      Это - горькая правда :-(

      Удалить
  4. Про "сложность и запутанность"..

    Во-первых: я перерисовал эту дуаграммму
    Во-вторых: я теперь понимаю как "такие диаграммы рисовать проще".
    В-третьих: У меня есть понимание "как надо упростить UML (вернее его "конкретную реализацию") чтобы таких "монстров" не было".

    ОтветитьУдалить
  5. http://programmingmindstream.blogspot.ru/2015/11/1187-delphi.html

    "Да Александр...
    Как Вы любите всё запутать...
    С одной стороны, Вы говорите о преимуществах UML как графической нотации, которая (читай, по своей природе) человеку ближе, что всё нагляднее с UML и понятнее. Упоминаете диаграмму мета-модели, которая способствует навигации и способствует не только осознанию замысла, но и принятию правильных решений.
    С другой - приводите этот хичкоковский триллер, причём говорите, что весь его показать не можете, поскольку "не уместилось"..."

    Я многое пересмотрел:

    "Ну и свою концепцию матрёшки - я с тех пор сильно пересмотрел. Теперь в моём понимании это скорее не "матрёшка", а набор карт. Разного масштаба. Слово "разного" - ключевое.

    Карты разного масштаба, которые "слабо связаны" с другими картами. Особенно с картами другого масштаба.

    С выделением "граничных слоёв" для места "сшивок карт".

    Чтобы была не ОДНА общая модель системы, а чтобы она развалилась на множество СЛАБОСВЯЗАННЫХ моделей."

    ОтветитьУдалить
    Ответы
    1. Я многое пересмотрел...
      -- Не убеждён, что понял Вас, Александр...
      На мой взгляд, отличие "матрёшки" от "множества слабосвязанных моделей" сводится только к замене композиции на агрегацию, или другой вид связи.
      Ещё сложнее мне понять, когда Вы говорите о выделении "граничных слоёв".
      Свою точку зрения я изложил выше - перечитал немного, и пока себе самому мне возразить нечего, по крайней мере в части операционного языка.
      Поделюсь - в последнее время мне приходится сталкиваться с диаграммами чаще, чем это было в два года назад, и те проблемы, на которые я указал тогда, никуда неделись. Чем сложнее диаграмма, тем сложнее с ней работать. Хорошая диаграмма - это маленькая диаграмма, которая иллюстрирует идею. на может попасть в документацию, иногда она может жить действительно долго, но генерировать по ней код... Я бы не стал.
      Но я с интересом наблюдаю за Вашей работой, и вполне позитивно ссылаюсь на Вас на занятиях со студентами, приводя примеры былоо широкого применения UML, чем мне казалось бы уместным. В любом случае, люди должны знать, что идея непрерывной генерации кода в соответствии с графической нотацией не утратила актуальность, хотя бы, как альтернативное мейнстриму направление.
      Вместе с тем, я считаю, что основным предметом приложения сил программиста является код, а место всего остального (и диаграмм в частности) - облегчать, упрощать управление этим кодом. Среди задач управления осоняком стоит тема документирования архитектуры - вот здесь UML (и прочие нотации) могут существенным образом помочь. Но только в том случае, если диаграммы не будут перегружены деталями. Тогда они и актуальность сохранят дольше.
      Чем глубже детализация - тем сложнее диаграмма. Даже если в ней будет не так много сущностей и отношений, одними стереотипами можно существенно перегрузить модель. А как обойтись без расширения базового UML, если требуется поддерживать семейства разновидностей связей? Получается ещё один язык, но его применение только повышает порог входа, да и сопровождать это эффективно можно только в случае, если не отдаляться от темы.
      "Масла в огонь" подливает и этот материал - спасибо, кстати, что опубликовали. ПМСМ, обозначенная проблема - суть, прямое следствие непрерывной (т.е. повторяющейся, систематической) генерации кода, отвечающего за бизнес-логику, того, что код перестаёт быть первоисточником, но исполняется ведь всегда код! Отсюда и справедливые опасения за то, как бы чего не утратило работоспособность.
      Помочь могут тесты, но всего ведь не протестируешь... 100% покрытие - удел небольших проектов, да и создание тестов - затратная вещь, а также то, за что клиент платить не захочет.
      Разумеется, прошу считать всё вышесказанным, моим глубоко личным мнением.

      Удалить
    2. Извиняюсь за массу опечаток, тем не менее надеюсь, что смысл не пострадал.

      Удалить