http://18delphi.blogspot.ru/2013/09/blog-post_1303.html?showComment=1380312709199#c6777293502412066273
"И начнёте думать, как упростить это, если "это" представляет для Вас какую-либо ценность. Я не стану рассказывать о декомпозиции, о выделении родственных сущностей и формализации связей в предметной области - Вы опять скажете, что я Вас с кем-то путаю. Но это как раз тот путь, о котором Вы говорите, что его-де "никто не знает". - Знает, Александр. Знает."
Это - ОЧЕВИДНО и ЛЕЖИТ НА ПОВЕРХНОСТИ.
Просто нужен совсем "иной UML" И совсем "иной UML-редактор".
Собственно о чём мы с Максом и толкуем.
Это если за скобки опустить необходимость "разгребания конюшен.
"Я не стану рассказывать о декомпозиции, о выделении родственных сущностей и формализации связей в предметной области" - да - не стоит.
Не то чтобы не стоит. Но я знаю про них. И регулярно занимаюсь этим.
Приведённая диаграмма была ещё "хуже".
"формализации связей в предметной области" - вот тут к сожалению - я далеко не всегда властен. Тут есть "заказчики".
И любая формализация может выйти "боком".
Я кстати писал немного об этом - http://18delphi.blogspot.ru/2013/09/blog-post_16.html
Формализация - она хороша. И я ОБЕИМИ руками за неё. Но! "Заказчики" - далеко не всегда её понимают.
Бывает - ДВЕ сущности - одинаковые. Вообще - мама родная не отличит. Но "Заказчики" хотят от них "совершенно разного поведения". По неформальным признакам. И тут - никакие формальные методы не работают.
Только если шаблонизация в терминах UML и UseCase'ов.
"И начнёте думать, как упростить это, если "это" представляет для Вас какую-либо ценность. Я не стану рассказывать о декомпозиции, о выделении родственных сущностей и формализации связей в предметной области - Вы опять скажете, что я Вас с кем-то путаю. Но это как раз тот путь, о котором Вы говорите, что его-де "никто не знает". - Знает, Александр. Знает."
Это - ОЧЕВИДНО и ЛЕЖИТ НА ПОВЕРХНОСТИ.
Просто нужен совсем "иной UML" И совсем "иной UML-редактор".
Собственно о чём мы с Максом и толкуем.
Это если за скобки опустить необходимость "разгребания конюшен.
"Я не стану рассказывать о декомпозиции, о выделении родственных сущностей и формализации связей в предметной области" - да - не стоит.
Не то чтобы не стоит. Но я знаю про них. И регулярно занимаюсь этим.
Приведённая диаграмма была ещё "хуже".
"формализации связей в предметной области" - вот тут к сожалению - я далеко не всегда властен. Тут есть "заказчики".
И любая формализация может выйти "боком".
Я кстати писал немного об этом - http://18delphi.blogspot.ru/2013/09/blog-post_16.html
Формализация - она хороша. И я ОБЕИМИ руками за неё. Но! "Заказчики" - далеко не всегда её понимают.
Бывает - ДВЕ сущности - одинаковые. Вообще - мама родная не отличит. Но "Заказчики" хотят от них "совершенно разного поведения". По неформальным признакам. И тут - никакие формальные методы не работают.
Только если шаблонизация в терминах UML и UseCase'ов.
>> Бывает - ДВЕ сущности - одинаковые. Вообще - мама родная не отличит. Но "Заказчики" хотят от них "совершенно разного поведения". По неформальным признакам.
ОтветитьУдалить----
Какие же они одинаковые, если у них разное поведение?
«Какие же они одинаковые, если у них разное поведение?»
ОтветитьУдалить-- Во многих случаях уместно говорить об использовании одной и той же сущности (или прецедента) в разных контекстах (или в других разных прецедентах). При таком подходе различия в поведении можно отразить комбинациями аспектов, отражающих детали поведения, поскольку в этих деталях может быть много общего.
Как в приведённом Александром примере ((http://18delphi.blogspot.ru/2013/09/blog-post_1303.html?showComment=1380316043510#c6070849377176454577) см. обсуждение в комментариях) с Консультациями, Документами, Оглавлениями и Печатью.