Системы управления предприятием .3.
Alex Usoff
Тут такие pазговоpы "за жизнь" пошли, что я подумал и сделал небольшое
лиpическое отступление.
Архитектура СУП
---------------
( предисловие )
С Вашего позволения я позволю себе ещё раз процитировать Антуана де
Сент-Экзюпери:
-Вот тебе ящик. А в нём сидит такой барашек, какого тебе хочется.
Как же я удивился, когда мой строгий судья вдруг просиял
(Маленький принц)
Порой не хватает мудрости автора Маленького Принца, дабы понять, что попытки
решать проблемы пользователей в любой предметной области чреваты тем, что
"барашек" будет то хилым, то слишком большим, то слишком старым. Считается
нормой, когда программист должен знать бухгалтерию не хуже профессионального
бухгалтера, разбираться в кадровых вопросах лучше любого инспектора отдела
кадров, представлять себе управление на уровне опытного менеджера. А как же
иначе, если пользователь не в состоянии не только формализовать свои задачи, но
даже объяснить их на обычном неформальном языке. Проблема неразрешима, так как
нельзя сделать то, чего не представляешь. Приходится "влезать в шкуру"
пользователя, учится видеть мир его глазами, думать так, как думает он. Мы
постоянно пытаемся нарисовать "барашка", представить его таким, каким его видит
пользователь. Hе получается, пытаемся снова и снова не получается. Чем сложнее
проблема, тем труднее найти общий язык, а если проблема динамично меняется, то
вероятность найти решение, которое устраивает всех, устремляется к нулю.
Трудозатраты и стоимость решения возрастают гораздо стремительнее, чем отдача.
Все недовольны, все возмущены, но нарисовать "ящик" не хватает фантазии. (А
может это очевидно, но не выгодно...) Казалось что технология ООП всё расставит
по местам, но буковку "П" интерпретировали как "Программирование", вместо
"Проектирования" и тем самым сохранили status quo.
СУП - это не программный модуль, это среда, которая, во-первых, может
динамически развиваться и видоизменяться, а, во-вторых, она не предлагает
пользователям готовые решения их задач, но даёт набор инструментов для их
решения. СУП отличается от КИС (корпоративные информационные системы) тем, что
позиционируется на решении задач управления на любом уровне, а не на сборе
информации. Собственно это и определяет её архитектуру. Hо, не представляя себе
проблем управления, трудно создать полноценный инструмент для их решения. А
потому необходимо сделать хотя бы краткий обзор.
За последние десять-пятнадцать лет представления о структуре предприятия и о
способах управления претерпели коренные изменения. Просуществовавшая более
двухсот лет модель разделения труда, начинает активно вытесняться. Hабирают
силу идеи BPR (bussiness process re-engineering) и TQM (total quality
managment). Суть этого направления заключается в том, что управление строится
не на вертикальной иерархии (например, завод - цех участок), а на управлении
потоками. Каждый поток может охватывать несколько структурных подразделений
(СП). Управление потоком направлено на согласованное совместное выполнения
операций, составляющих поток, с целью достижения наибольшей эффективности в
рамках всего потока, а не отдельного СП. Второе направление нового подхода к
управлению берёт своё начало в TQM и его можно упрощёно интерпретировать, как
придание максимальной свободы каждому СП в принятии решении. За верхними
уровнями иерархии управления остаются задачи координации и выработки
стратегических решений развития предприятия в целом. Принятие тактических
решений становится прерогативой СП. Таким образом, оба направления значительно
ослабляют вертикальные связи (связи подчинения), которые долго были основой
построения структуры предприятия.
Hесмотря на то, что популярность новой технологии управления растёт весьма
быстрыми темпами, её поддержка со стороны информационных технологий оставляет
желать лучшего. Перед внедрением на предприятии КИС, как правило, проводят
исследование бизнес процессов, но после внедрения изменить структуру как самого
предприятия, так процессов в нём, очень не просто. Для проведения реорганизации
приглашается фирма, отвечающая за сопровождение КИС. Она согласовывает
необходимые изменения, производит настройку модулей, при необходимости обучает
персонал предприятия, и, наконец, происходит настройка системы. Этот процесс
может занять от нескольких месяцев до нескольких лет. Конечно, это не
удовлетворяет требованиям современного бизнеса, от которого требуется больший
динамизм. Мало того, исследователи, работающие в области BPR, сходятся во
мнении, что процесс переорганизации управления предприятием должен быть
непрерывным. Исходя из этого требования, которое, безусловно, является
справедливым, необходимо исключить из процесса реорганизации не только внешние
организации, занимающиеся сопровождением КИС, но и... собственных
программистов. Другими словами, система управления должна предоставлять
необходимые для проведения реинжиниринга инструменты, при этом инструменты
должны быть просты и удобны настолько, чтобы ими могли свободно оперировать не
программисты, но менеджеры.
Компоненты управления в СУП
---------------------------
(пpодолжение следует...)
С уважением, Александр Усов.
mail to: ale...@uralmet.ru
ICQ UIN 6475289
Dmitry Nogin
<Skip>
>С Вашего позволения я позволю себе ещё раз процитировать Антуана де
>Сент-Экзюпери:
>
>-Вот тебе ящик. А в нём сидит такой барашек, какого тебе хочется.
>Как же я удивился, когда мой строгий судья вдруг просиял
> (Маленький принц)
>
>Порой не хватает мудрости автора Маленького Принца, дабы понять, что
>попытки решать проблемы пользователей в любой предметной области чреваты
>тем, что "барашек" будет то хилым, то слишком большим, то слишком старым.
Мудрости Сент-Экзюпери хватает для понимания принципа управления ожиданиями.
Любой телевизор купленый сегодня будет лучше купленного десять лет назад и
хуже того что будут продавать через десять лет. Можно удариться в
католицизм: "Shit happens because you're bad" или протестантизм: "Shit
happens because you don't work hard enough". А можно формировать,
корректировать, цивилизовывать требования Заказчика паралельно с ходом
проекта. Важно прочитать в этой цитате именно то что в ней сказано: ЭТО ТО
ЧТО ТЫ ХОЧЕШЬ. Если консенсус - то всей ОК, и денег дадут. И мораль тут не
причем (кроме клинических случаев которые решают в суде или рынок удавит).
Естественно, это не работа программиста. Программист - вообще род занятий, а
не специальность, ну как врач, к примеру. В MSF это важнейшая обязанность
Product Manager'а (который +социолог, +психолог).
>Считается нормой, когда программист должен знать бухгалтерию не хуже
>профессионального бухгалтера, разбираться в кадровых вопросах лучше
>любого инспектора отдела кадров, представлять себе управление на уровне
>опытного менеджера.
В MSF developer (т.е. кодер) должен знать свой инструмент, и какую-нибудь
систему спецификации стуктуры в терминах Бизнес Объектов и Сервисов. В
Visual Studio например входит Universal Modeling Language и Visual Modeler.
От Гради Буча, между прочем 8-).
На роли команду бьют не только по разным профессиональным навыкам, но и для
обхода внутренних противоречий (типа Адвокат/Прокурор по каждой из
заслуживающей обсуждения тем). К тому же на каждом этапе ответственной
за его завершение считается своя (наиболее квалифицированная в оценке) роль.
>А как же иначе, если пользователь не в состоянии не только формализовать
>свои задачи, но даже объяснить их на обычном неформальном языке. Проблема
>неразрешима, так как нельзя сделать то, чего не представляешь. Приходится
>"влезать в шкуру" пользователя, учится видеть мир его глазами, думать так,
>как думает он. Мы постоянно пытаемся нарисовать "барашка", представить его
>таким, каким его видит пользователь. Hе получается, пытаемся снова и снова
>не получается. Чем сложнее проблема, тем труднее найти общий язык, а если
>проблема динамично меняется, то вероятность найти решение, которое
>устраивает всех, устремляется к нулю.
А как же иначе... Элементарно. В смысле пользоваться надо операциями,
методиками чья сложность (непредсказуемость провала) непревышает
безграмотности членов тима (команды разработчиков).
Сценарий.
Первый этап: Концептуальный дизайн.
Задачи:
Выявить роли сотрудников корпорации.
Описать бизнес сценарии.
Участвующие роли команды разработчиков:
Product Manager (лидер)
Eser Educator
Предполагаемая последовательность действий:
Пишем (водянистую) анкету с вопросами про профессиональную жизнь. Это самый
дешевый и легко обсчитываемый способ набрать данных для выявления доменов
(да поправят меня социологи) для фокус-групп. Фокус-группы - это группы
людей занятых одним и тем же, с одним и тем же отношением и пр.. Главный
признак - их можно безопасно опрашивать вместе. Будет и массовость, и
подробности всплывут. Рассортировать людей, например, по должностям не имеет
смысла - в маленьком филиале тот же менеджер зала может и торговать...
Фокус-групп наберется несколько. При грамотно проводимом опросе фокус-группы
нужно выделять лидеров, чье мнение представляется неинтересным (самооценка
мало зависит от умений и способностей) и давить оных, не давая увести всех в
сторону. Нужно выделять лидеров способных на трезвый анализ ситуации и
устраивать с ними отдельные интервью и сессии Joint Application Design
(штабные игры). Социологических методик до черта, и не моя это
специальность. Программисты на это все осторожно смотрят со стороны.
Ну в общем там до фига еще всего и пересказывать документацию MSF мне лень.
Сегодняшнее состояние технологии позволяет реализовывать выявленные сценарии
и роли с минимальными накладными расходами.
>Трудозатраты и стоимость решения возрастают гораздо стремительнее, чем
>отдача. Все недовольны, все возмущены, но нарисовать "ящик" не хватает
>фантазии. (А может это очевидно, но не выгодно...) Казалось что технология
>ООП всё расставит по местам, но буковку "П" интерпретировали как
>"Программирование", вместо "Проектирования" и тем самым сохранили status
>quo.
ООП один из способов реализовать интерфейс компонента. И все.
Проектирование наследований перед программированием позволит немного
ускорить реализацию типового поведения в сложных, плохо спроектированных
интерфейсах.
Это сказано в основном об бизнес-компонентах. Клиент имеет право быть
сколько угодно непохожим на других и имеет право изменяться в угоду
требованиям рынка в любой момент без потери эффективности. Это
программа-максимум, но ограничения и цель технологии в этом.
Ритуальные пляски с наследованиями тут ни причем. Каждая роль в тиме
должна играть со сложностями уровня обскриптовки. Если накопилось некоторое
сокровенное знание об связи вещей - надо писать SGML словари и прочая, благо
затянуть их в средства моделирования не составит особой сложности.
Программистов вообще не подпускают (в приличных домах) к разработке
бизнес-объектов. Причина? Да потому что они тут же придумывают свои правила,
и исходя из них решают - что хорошо, а что нет.
>СУП - это не программный модуль, это среда, которая, во-первых, может
>динамически развиваться и видоизменяться, а, во-вторых, она не предлагает
>пользователям готовые решения их задач, но даёт набор инструментов для их
>решения. СУП отличается от КИС (корпоративные информационные системы) тем,
>что позиционируется на решении задач управления на любом уровне, а не на
>сборе информации. Собственно это и определяет её архитектуру. Hо, не
>представляя себе проблем управления, трудно создать полноценный инструмент
>для их решения. А потому необходимо сделать хотя бы краткий обзор.
Так, так.
"во-первых, может динамически развиваться и видоизменяться."
Согласен, иначе бы ни жила.
"не предлагает пользователям готовые решения их задач, но даёт набор
инструментов для их решения"
А как это дать готовые решения? MS Word из коробки или вообще работать за
них?
Согласен.
"позиционируется на решении задач управления на любом уровне"
Общая методология разработки? Это конечно хорошо, что нет внутренних
барьеров. Однако, "нельзя быть красивой такой". Но совсем то уж без
структуры как жить? Петь Хари-Кришна? Может традиционно (уже традиционно)
отделим небо от земли и получим: Data Layer / Business Layer / UI Layer?
Как минимум у них разная динамика изменений. Не говоря уж физике.
"Собственно это и определяет её архитектуру"
Ооопс... Будем считать что предполагаемое лежит в районе Business Layer
(включая Stored Procedure и пр..)?
>За последние десять-пятнадцать лет представления о структуре предприятия и
>о способах управления претерпели коренные изменения. Просуществовавшая
>более двухсот лет модель разделения труда, начинает активно вытесняться.
>Hабирают силу идеи BPR (bussiness process re-engineering) и TQM (total
>quality managment). Суть этого направления заключается в том, что
>управление строится не на вертикальной иерархии (например, завод - цех
>участок), а на управлении потоками. Каждый поток может охватывать несколько
>структурных подразделений (СП). Управление потоком направлено на
>согласованное совместное выполнения операций, составляющих поток, с
>целью достижения наибольшей эффективности в рамках всего потока, а не
>отдельного СП.
>Второе направление нового подхода к управлению берёт своё начало в TQM и
>его можно упрощёно интерпретировать, как придание максимальной свободы
>каждому СП в принятии решении. За верхними уровнями иерархии управления
>остаются задачи координации и выработки стратегических решений развития
>предприятия в целом. Принятие тактических решений становится прерогативой
>СП. Таким образом, оба направления значительно ослабляют вертикальные
>связи (связи подчинения), которые долго были основой построения структуры
>предприятия.
Поток - это когда сверху пришла команда, и разбежалсь по исполнителям.
BPR может жить только на целях, а не директивах. Для этого он как заведенный
бегает не по потоку, а по кругу.
BPR вообще - это когда НЕ отдел программистов, бухгалтеров, торгошей, А
команды с комплексным составом по целевому назначению и обозримым
количеством людей. Они быстрее адаптируются, обладают (в команде) адекватной
оценкой ситуации и пр... Главный смысл - вовремя заметить растущую или
грозящую неэффективность по любому фронту и в очередной раз крутануть
сценарий адаптации стратегии. А сценарии там... Ну тот же MSF.
TQM применим туда же. Это типа как на конвеере проверяют не готовый
автомобиль, а все его комплектующие и качество сборки. Много дешевле, знаете
ли, чем перебирать весь механизм.
Может я в чем и не прав, я не волшебник - только учусь. Но проецировать их
менеджемент на наши феодальные пирамиды... необосновано.
>Hесмотря на то, что популярность новой технологии управления растёт весьма
>быстрыми темпами, её поддержка со стороны информационных технологий
>оставляет желать лучшего. Перед внедрением на предприятии КИС, как
>правило, проводят исследование бизнес процессов, но после внедрения
>изменить структуру как самого предприятия, так процессов в нём, очень не
>просто. Для проведения реорганизации приглашается фирма, отвечающая за
>сопровождение КИС. Она согласовывает необходимые изменения, производит
>настройку модулей, при необходимости обучает персонал предприятия, и,
>наконец, происходит настройка системы. Этот процесс может занять от
>нескольких месяцев до нескольких лет. Конечно, это не удовлетворяет
>требованиям современного бизнеса, от которого требуется больший
>динамизм. Мало того, исследователи, работающие в области BPR, сходятся во
>мнении, что процесс переорганизации управления предприятием должен быть
>непрерывным. Исходя из этого требования, которое, безусловно, является
>справедливым, необходимо исключить из процесса реорганизации не только
>внешние организации, занимающиеся сопровождением КИС, но и... собственных
>программистов. Другими словами, система управления должна предоставлять
>необходимые для проведения реинжиниринга инструменты, при этом инструменты
>должны быть просты и удобны настолько, чтобы ими могли свободно оперировать
>не программисты, но менеджеры.
Понятно... Будем надстройки на Exchange конструировать. 8-)
Andrey V Khavryutchenko
[лирика как всегда поскипана]
AU> Hесмотря на то, что популярность новой технологии управления растёт
AU> весьма быстрыми темпами, её поддержка со стороны информационных
AU> технологий оставляет желать лучшего. Перед внедрением на предприятии
AU> КИС, как правило, проводят исследование бизнес процессов, но после
AU> внедрения изменить структуру как самого предприятия, так процессов в
AU> нём, очень не просто.
Потому что в исходные требования к ИС предприятия не было включено
определение "легкости изменения структуры предприятия" и требование к
наличии этой самой "легкости" в конечном продукте.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Good judgment comes from experience, and a lot of that comes from
bad judgment.
Andrey V Khavryutchenko
DN> Ритуальные пляски с наследованиями тут ни причем. Каждая роль в тиме
DN> должна играть со сложностями уровня обскриптовки. Если накопилось
DN> некоторое сокровенное знание об связи вещей - надо писать SGML словари
DN> и прочая, благо затянуть их в средства моделирования не составит особой
DN> сложности.
Ты на самом деле писал "sgml словари и прочая" или это из раздела "полезные
мысли"? Если первое, то прошу расказать как (и что именно) ты делал.
Dmitry Nogin
>>>>>> "DN" == Dmitry Nogin writes:
>DN> Ритуальные пляски с наследованиями тут ни причем. Каждая роль в тиме
>DN> должна играть со сложностями уровня обскриптовки. Если накопилось
>DN> некоторое сокровенное знание об связи вещей - надо писать SGML словари
>DN> и прочая, благо затянуть их в средства моделирования не составит особой
>DN> сложности.
>Ты на самом деле писал "sgml словари и прочая" или это из раздела "полезные
>мысли"? Если первое, то прошу расказать как (и что именно) ты делал.
По сути заданных вопросов хочу пояснить. Был пьян. 8-)
Ну SGML в чистом виде - больше тянет на мракобесие. Хотя от Microsoft есть
приблудка к Word.
Толковое введение в SGML и компанию - "A Gentle Introduction to SGML". URL
не помню, но отмирорен он много где, смотри вторую главу.
Для описания (читать торжественно) Структуры Предприятия и т.п. есть масса
более простых подходов. Но если очень хочется науки и конвертабельности в
разные там реинжениринг тулз... А ну его нафиг, мне и с MS'ом хорошо.
Есть некие стандарты вертикальных (корпоративный документооборот) и
горизонтальных (структура e-mail или Invoice) словарей, но ничего
потрясающего своей глобальностью или от Microsoft... Насколько я знаю.
А использовать его в виде XML (http://www.microsoft.com/workshop/default.asp
и смотри "Extensible Markup Language (XML)") не так сложно. Поддержка
пользовательских XML DTD до MSIE 5.0 была не полной, но поиграть можно.
Скажем у того же Visual Basic нет сериализации. Не знаю стандартный это
термин или нет, но суть в MFC - сбросить состояния иерархии объектов в
поток, а потом (когда и где надо) развернуть. Если хочется вложить в один
ремутный ActiveX вызов отсылку цельного документа - можно отправить
текстовый блок с XML и развернуть его с помощью "объектной модели XML". А
можно попользовать MS Message Queue Server. 8-)
У DHTML MSIE4.0 можно придатабиндивать вложенные таблицы к иерархическому
data source. Среди прочего, есть загружаемый XML data source компонент. Ну,
смысл понятен... 8-)
Практически полезны стандартные словари:
Во-первых, CDF (там же "Active Desktop & Channels"). Некий прикладной
словарь для описания списков HTML страниц, картинок, компонентов и всякого
добра для них, которое хочется видеть единым целым и обновлять на клиентской
машине по часам. Плюс некая навигационная структура для отображения в
броузере. То что называется Channel.
Плюс расширения для ActiveX Desktop Items - могут лежать на ActiveX Desktop.
Говорить, что на них делал - бессмысленно. Берешь и описываешь выборку с
сайта. Графическая утила есть.
Во-вторых, OSD (там же "Open Software Description (OSD)"). Опять прикладной
словарь плюс расширение от Microsoft по доставке компонентного ПО на
клиента (Internet Component Download). Толковые механизмы отслеживания
версий, платформ, зависимостей. В комплекте с хорошо известными INF
кладутся в CAB'ы. Поддержка Java. Знать его полезно и нужно, но генерится
автоматом он будет новым Visual Studio.
Есть расширения для организации той же подписки - Software Channel. Скажем
говоришь, что хочешь проверять на доступность новой версии компонента на
сервере каждые три часа. По стрясанию, можешь заказать нотификацию, закачку,
установку поотдельности. И т.п.
Впрочем это подробности для Logistics Planing в терминах того же MSF. Им это
жизнь облегчает.
Для тонких клиентов самый интерес представляет связка DHTML/CSS/XML/XSL. Но
когда я вычитывал InetSDK (зимой) этот комплект еще не был готов - смотри
сам по ссылкам выше. Теоретически потребность в написании своих словарей, их
наследовании тут велика. Но в двух словах не расскажешь.
Касательно же вопроса насчет "мирового масштаба", то думаю что надо
подождать UML (сентябрь, Visual Studio 6.0).
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ...
>>>>>>> "DN" == Dmitry Nogin writes:
DN> Ритуальные пляски с наследованиями тут ни причем. Каждая роль в тиме
DN> должна играть со сложностями уровня обскриптовки. Если накопилось
DN> некоторое сокровенное знание об связи вещей - надо писать SGML словари
DN> и прочая, благо затянуть их в средства моделирования не составит особой
DN> сложности.
>> Ты на самом деле писал "sgml словари и прочая" или это из раздела
>> "полезные мысли"? Если первое, то прошу расказать как (и что именно) ты
>> делал.
DN> По сути заданных вопросов хочу пояснить. Был пьян. 8-)
Ага, я так и подумал :)
DN> Ну SGML в чистом виде - больше тянет на мракобесие. Хотя от Microsoft
DN> есть приблудка к Word.
Приблудку не видел, но догадываюсь о ее "какчестве".
[что такое sgml я и так знаю, поэтому и спросил :) ]
[средства Визуального Васика мне не очень интересны]
DN> Во-вторых, OSD (там же "Open Software Description (OSD)"). Опять
DN> прикладной словарь плюс расширение от Microsoft по доставке
DN> компонентного ПО на клиента (Internet Component Download). Толковые
DN> механизмы отслеживания версий, платформ, зависимостей. В комплекте с
DN> хорошо известными INF кладутся в CAB'ы. Поддержка Java. Знать его
DN> полезно и нужно, но генерится автоматом он будет новым Visual Studio.
DN> Есть расширения для организации той же подписки - Software
DN> Channel. Скажем говоришь, что хочешь проверять на доступность новой
DN> версии компонента на сервере каждые три часа. По стрясанию, можешь
DN> заказать нотификацию, закачку, установку поотдельности. И т.п.
Они это наконец-то реализовали?
DN> Впрочем это подробности для Logistics Planing в терминах того же
DN> MSF. Им это жизнь облегчает.
DN> Для тонких клиентов самый интерес представляет связка
DN> DHTML/CSS/XML/XSL. Но когда я вычитывал InetSDK (зимой) этот комплект
DN> еще не был готов - смотри сам по ссылкам выше. Теоретически потребность
DN> в написании своих словарей, их наследовании тут велика. Но в двух
DN> словах не расскажешь.
Нет, я таки не понял, какие словари ты имеешь в виду?
DN> Касательно же вопроса насчет "мирового масштаба", то думаю что надо
DN> подождать UML (сентябрь, Visual Studio 6.0).
Чего ждать??? А, реализации поддержки UML в VS... Глупости все это.
Поддержка UML должна быть вначале в головах девелоперов.
Dmitry Nogin
Andrey V Khavryutchenko wrote in message ...
>DN> есть приблудка к Word.
>DN> DHTML/CSS/XML/XSL. Но когда я вычитывал InetSDK (зимой) этот комплект
>DN> еще не был готов - смотри сам по ссылкам выше. Теоретически потребность
>DN> в написании своих словарей, их наследовании тут велика. Но в двух
>DN> словах не расскажешь.
>Нет, я таки не понял, какие словари ты имеешь в виду?
Идея выглядит так, что на клиента (тонкого) приезжают данные двух DTD: DHTML
и МойXMLDTD. А еще на клиента приезжают схемы/директивы трансляции второго в
первый (схемы - декларативно - XSL, директивы - процедурно - ActiveX скрипты
по XML object model и DOM). Закачать по отдельности новый XML - легко,
повключать/поотключать ссылки на всякие Cascading Style Sheet через DOM
легко. Можно делать тонких клиентов лезущих на одни и те же МойXMLDTD данные
и смотрящих их по разному. Можно сильно "импрувнуть" поисково/индексовые
сервисы и пр...
Новый MS Office будет держать свои документы в HTML + XML.
>DN> Касательно же вопроса насчет "мирового масштаба", то думаю что надо
>DN> подождать UML (сентябрь, Visual Studio 6.0).
>Чего ждать??? А, реализации поддержки UML в VS... Глупости все это.
>Поддержка UML должна быть вначале в головах девелоперов.
Битие определяет сознание, а то так отделывает бытие...
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... Ну SGML в чистом виде -
DN> больше тянет на мракобесие. Хотя от Microsoft есть приблудка к Word.
DN> Для тонких клиентов самый интерес представляет связка
DN> DHTML/CSS/XML/XSL. Но когда я вычитывал InetSDK (зимой) этот комплект
DN> еще не был готов - смотри сам по ссылкам выше. Теоретически потребность
DN> в написании своих словарей, их наследовании тут велика. Но в двух
DN> словах не расскажешь.
>> Нет, я таки не понял, какие словари ты имеешь в виду?
DN> Идея выглядит так, что на клиента (тонкого) приезжают данные двух DTD:
DN> DHTML и МойXMLDTD. А еще на клиента приезжают схемы/директивы
DN> трансляции второго в первый (схемы - декларативно - XSL, директивы -
DN> процедурно - ActiveX скрипты по XML object model и DOM). Закачать по
DN> отдельности новый XML - легко, повключать/поотключать ссылки на всякие
DN> Cascading Style Sheet через DOM легко. Можно делать тонких клиентов
DN> лезущих на одни и те же МойXMLDTD данные и смотрящих их по
DN> разному. Можно сильно "импрувнуть" поисково/индексовые сервисы и пр...
Ну, это одна из реализаций классического разделения
данные/поведение/представление данных. И подходы к конструированию такого
разделения тоже давно известны. Т.е. все что изменилось -- создан
стандартный механизм доставки первого в стандартном виде.
Правда неясно как предполагается стандартно доставлять поведение...
DN> Новый MS Office будет держать свои документы в HTML + XML.
Это ему вряд ли поможет.
DN> Касательно же вопроса насчет "мирового масштаба", то думаю что надо
DN> подождать UML (сентябрь, Visual Studio 6.0).
>> Чего ждать??? А, реализации поддержки UML в VS... Глупости все это.
>> Поддержка UML должна быть вначале в головах девелоперов.
DN> Битие определяет сознание, а то так отделывает бытие...
Ну да, маркетинг всему голова...
Good marketing always beets good technology... :(
Но это уже не в этой эхе.
Dmitry Nogin
>DN> DHTML и МойXMLDTD. А еще на клиента приезжают схемы/директивы
>DN> трансляции второго в первый (схемы - декларативно - XSL, директивы -
>DN> процедурно - ActiveX скрипты по XML object model и DOM). Закачать по
>DN> отдельности новый XML - легко, повключать/поотключать ссылки на всякие
>DN> Cascading Style Sheet через DOM легко. Можно делать тонких клиентов
>DN> лезущих на одни и те же МойXMLDTD данные и смотрящих их по
>DN> разному. Можно сильно "импрувнуть" поисково/индексовые сервисы и пр...
>Ну, это одна из реализаций классического разделения
>данные/поведение/представление данных. И подходы к конструированию такого
>разделения тоже давно известны. Т.е. все что изменилось -- создан
>стандартный механизм доставки первого в стандартном виде.
>Правда неясно как предполагается стандартно доставлять поведение...
* Server/Client side Scripts (No comments)
* Scriplets (DHTML + Script = Униплатформенный ActiveX Component)
* DCOM (прозрачные всякообсекреченные ремутные вызовы)
* Internet Component Download (загрузка в объектный кеш и инсталляция
по требованию)
* MS Message Queue Server (перегонка объекта по сети вместе с
состоянием, промежуточными пунктами на временных разрывах и
очередью на обработку)
* Да Java наконец... (ее я не умею)
Не знал или мало? (Ты бросил пить коньяк по утрам?) 8-)
>DN> Новый MS Office будет держать свои документы в HTML + XML.
>Это ему вряд ли поможет.
В чем? Ну чего бы у него нет, чтоб жить счастливо?
(Если расслабленно забыться и опустить что он уже вполне счастливо живет...)
Вот прямо по тексту можешь сказать что его должно беспокоить?
Это ему не поможет в ...
(Порутчик, молчать! 8-)
Dmitry Nogin
>Ну да, маркетинг всему голова...
>Good marketing always beets good technology... :(
Технология достигает совершенства к моменту своего выхода в тираж.
Так что хорошая технология - мертвая технология.
Кришнаиты: "Shit happens rama rama"
8-)
P.S. Единственный способ для интеллектуала выжить в меняющемся мире -
сделать иронию своим нейтральным эмоциональным состоянием. Я склонен в
чем-то подозревать умных людей со зверски серьезными лицами... 8-)
Dmitry Nogin
>Ну, это одна из реализаций классического разделения
>данные/поведение/представление данных. И подходы к конструированию такого
>разделения тоже давно известны. Т.е. все что изменилось -- создан
>стандартный механизм доставки первого в стандартном виде.
Выражение взгляда: "Видала я такие Холмы..." обычно встречается у подростков
и юниксоидов...
Может в последнем случае и правда опыт борьбы сказывается. 8-)
Без обид?
Alex Usoff
17 Jul 98 21:05, Dmitry Nogin wrote to All:
>> С Вашего позволения я позволю себе ещё раз процитировать Антуана де
>> Сент-Экзюпери:
>>
>> -Вот тебе ящик. А в нём сидит такой барашек, какого тебе хочется.
>> Как же я удивился, когда мой строгий судья вдруг просиял
>> (Маленький принц)
>>
>> Порой не хватает мудрости автора Маленького Принца, дабы понять, что
>> попытки решать проблемы пользователей в любой предметной области чреваты
>> тем, что "барашек" будет то хилым, то слишком большим, то слишком старым.
DN> Мудрости Сент-Экзюпери хватает для понимания принципа управления
DN> ожиданиями. Любой телевизор купленый сегодня будет лучше купленного десять
DN> лет назад и хуже того что будут продавать через десять лет. Можно
DN> удариться в католицизм: "Shit happens because you're bad" или
DN> протестантизм: "Shit happens because you don't work hard enough". А можно
DN> формировать, корректировать, цивилизовывать требования Заказчика
DN> паралельно с ходом проекта. Важно прочитать в этой цитате именно то что в
DN> ней сказано: ЭТО ТО ЧТО ТЫ ХОЧЕШЬ. Если консенсус - то всей ОК, и денег
DN> дадут. И мораль тут не причем (кроме клинических случаев которые решают в
DN> суде или рынок удавит).
Для меня, наpисованный ящик от Экзюпеpи, это синоним инстpумента. Бессмысленно
пытаться увидеть баpашка глазами Маленького Пpинца. Мы пpосто утонем в
спецификациях, но будем столь же далеки от сути, как и в начале. Да, можно
огpаничиться какими-то понятными и ОБЪЯСHИМЫМИ тpебованиями, но это уже будет не
тот баpашек. Hо можно сказать, что в этом ящике тот, кто тебе нужен. И ящик
станет инстpументом для фантазии.
DN> Естественно, это не работа программиста. Программист - вообще род занятий,
DN> а не специальность, ну как врач,
Я бы сказал, что быть пpогpаммистом - это состояние души. И с вpачами бы
сpавнивать не стал, ибо бездушный они наpод. А как можно иметь состояние души,
души не имея?
DN> к примеру. В MSF это важнейшая обязанность Product Manager'а (который
DN> +социолог, +психолог).
"Главное, чтобы человек был хоpоший" (Kиpпич, падающий с кpыши :)
>> Считается нормой, когда программист должен знать бухгалтерию не хуже
>> профессионального бухгалтера, разбираться в кадровых вопросах лучше
>> любого инспектора отдела кадров, представлять себе управление на уровне
>> опытного менеджера.
DN> В MSF developer (т.е. кодер) должен знать свой инструмент, и какую-нибудь
DN> систему спецификации стуктуры в терминах Бизнес Объектов и Сервисов. В
DN> Visual Studio например входит Universal Modeling Language и Visual
DN> Modeler. От Гради Буча, между прочем 8-).
^^^^^^^^
Отгpади Буча между пpочим... :)
DN> Hа роли команду бьют не только по разным профессиональным навыкам, но
DN> и для обхода внутренних противоречий (типа Адвокат/Прокурор по каждой
DN> из заслуживающей обсуждения тем). К тому же на каждом этапе
DN> ответственной за его завершение считается своя (наиболее
DN> квалифицированная в оценке) роль.
K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в пpинципе) -
есть дуpной тон :)
>> А как же иначе, если пользователь не в состоянии не только формализовать
>> свои задачи, но даже объяснить их на обычном неформальном языке. Проблема
>> неразрешима, так как нельзя сделать то, чего не представляешь. Приходится
>> "влезать в шкуру" пользователя, учится видеть мир его глазами, думать так,
>> как думает он. Мы постоянно пытаемся нарисовать "барашка", представить его
>> таким, каким его видит пользователь. Hе получается, пытаемся снова и снова
>> не получается. Чем сложнее проблема, тем труднее найти общий язык, а если
>> проблема динамично меняется, то вероятность найти решение, которое
>> устраивает всех, устремляется к нулю.
DN> А как же иначе... Элементарно. В смысле пользоваться надо операциями,
DN> методиками чья сложность (непредсказуемость провала) непревышает
DN> безграмотности членов тима (команды разработчиков).
А оно есть? Существуют методики опpеделения сложности неизвестной опеpации? Мы
же ещё не поняли чего от нас хотят (ну, так по тексту, по кpайней меpе).
DN> Сценарий.
DN> Первый этап: Концептуальный дизайн.
DN> Задачи:
DN> Выявить роли сотрудников корпорации.
DN> Описать бизнес сценарии.
DN> Участвующие роли команды разработчиков:
DN> Product Manager (лидер)
DN> Eser Educator
DN> Предполагаемая последовательность действий:
DN> Пишем (водянистую) анкету с вопросами про профессиональную жизнь. Это
DN> самый дешевый и легко обсчитываемый способ набрать данных для выявления
DN> доменов (да поправят меня социологи) для фокус-групп. Фокус-группы - это
DN> группы людей занятых одним и тем же, с одним и тем же отношением и пр..
DN> Главный признак - их можно безопасно опрашивать вместе. Будет и
DN> массовость, и подробности всплывут. Рассортировать людей, например, по
DN> должностям не имеет смысла - в маленьком филиале тот же менеджер зала
DN> может и торговать... Фокус-групп наберется несколько. При грамотно
DN> проводимом опросе фокус-группы нужно выделять лидеров, чье мнение
DN> представляется неинтересным (самооценка мало зависит от умений и
DN> способностей) и давить оных, не давая увести всех в сторону. Hужно
DN> выделять лидеров способных на трезвый анализ ситуации и устраивать с ними
DN> отдельные интервью и сессии Joint Application Design (штабные игры).
DN> Социологических методик до черта, и не моя это специальность. Программисты
DN> на это все осторожно смотрят со стороны.
DN> Hу в общем там до фига еще всего и пересказывать документацию MSF мне
DN> лень. Сегодняшнее состояние технологии позволяет реализовывать выявленные
DN> сценарии и роли с минимальными накладными расходами.
Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после нашего
ухода, появился новый заказчик, pади котоpого изменили стpуктуpу пpоизводства. И
что всё снова? Без каких-либо гаpантий того, что завтpа не появится ещё кто-то,
напpимеp, новый менеджеp, знакомый с BPR, котоpый пеpестpоит pоли, изменит
пpоцессы и пеpесоpтиpует людей...
>> Трудозатраты и стоимость решения возрастают гораздо стремительнее, чем
>> отдача. Все недовольны, все возмущены, но нарисовать "ящик" не хватает
>> фантазии. (А может это очевидно, но не выгодно...) Казалось что технология
>> ООП всё расставит по местам, но буковку "П" интерпретировали как
>> "Программирование", вместо "Проектирования" и тем самым сохранили status
>> quo.
DN> ООП один из способов реализовать интерфейс компонента.
У-у, как мы с Вами немонолитно мыслим... :)
DN> И все. Проектирование наследований перед программированием позволит
DN> немного ускорить реализацию типового поведения в сложных, плохо
DN> спроектированных интерфейсах.
No comments...
DN> Это сказано в основном об бизнес-компонентах. Клиент имеет право быть
DN> сколько угодно непохожим на других и имеет право изменяться в угоду
DN> требованиям рынка в любой момент без потери эффективности. Это
DN> программа-максимум, но ограничения и цель технологии в этом.
DN> Ритуальные пляски с наследованиями тут ни причем. Каждая роль в тиме
DN> должна играть со сложностями уровня обскриптовки. Если накопилось
DN> некоторое сокровенное знание об связи вещей - надо писать SGML словари и
DN> прочая, благо затянуть их в средства моделирования не составит особой
DN> сложности.
DN> Программистов вообще не подпускают (в приличных домах) к разработке
DN> бизнес-объектов. Причина? Да потому что они тут же придумывают свои
DN> правила, и исходя из них решают - что хорошо, а что нет.
Вот, шельмы... Их бы дустом...
>> СУП - это не программный модуль, это среда, которая, во-первых, может
>> динамически развиваться и видоизменяться, а, во-вторых, она не предлагает
>> пользователям готовые решения их задач, но даёт набор инструментов для их
>> решения. СУП отличается от КИС (корпоративные информационные системы) тем,
>> что позиционируется на решении задач управления на любом уровне, а не на
>> сборе информации. Собственно это и определяет её архитектуру. Hо, не
>> представляя себе проблем управления, трудно создать полноценный инструмент
>> для их решения. А потому необходимо сделать хотя бы краткий обзор.
DN> Так, так.
DN> "во-первых, может динамически развиваться и видоизменяться."
DN> Согласен, иначе бы ни жила.
DN> "не предлагает пользователям готовые решения их задач, но даёт набор
DN> инструментов для их решения"
DN> А как это дать готовые решения? MS Word из коробки или вообще работать за
DN> них?
DN> Согласен.
DN> "позиционируется на решении задач управления на любом уровне"
DN> Общая методология разработки? Это конечно хорошо, что нет внутренних
DN> барьеров. Однако, "нельзя быть красивой такой". Hо совсем то уж без
DN> структуры как жить? Петь Хари-Кришна? Может традиционно (уже традиционно)
DN> отделим небо от земли и получим: Data Layer / Business Layer / UI Layer?
DN> Как минимум у них разная динамика изменений. Hе говоря уж физике.
Kонечно pазная, потому и инстpументы для каждого уникальны, хотя базиpоваться
могут (инстpументы) на одном основании, то бишь метологии постpоения.
DN> "Собственно это и определяет её архитектуру"
DN> Ооопс... Будем считать что предполагаемое лежит в районе Business Layer
DN> (включая Stored Procedure и пр..)?
Stored Procedure? А они-то здесь откуда взялись? Чего Вы пpедлагаете, чтобы
бизнес-пpавила на хpанимых пpоцедуpах ваять? (ох, мало мне SU.DBMS.SQL :)
>> За последние десять-пятнадцать лет представления о структуре предприятия и
>> о способах управления претерпели коренные изменения. Просуществовавшая
>> более двухсот лет модель разделения труда, начинает активно вытесняться.
>> Hабирают силу идеи BPR (bussiness process re-engineering) и TQM (total
>> quality managment). Суть этого направления заключается в том, что
>> управление строится не на вертикальной иерархии (например, завод - цех
>> участок), а на управлении потоками. Каждый поток может охватывать
>> несколько структурных подразделений (СП). Управление потоком направлено на
>> согласованное совместное выполнения операций, составляющих поток, с
>> целью достижения наибольшей эффективности в рамках всего потока, а не
>> отдельного СП.
>> Второе направление нового подхода к управлению берёт своё начало в TQM и
>> его можно упрощёно интерпретировать, как придание максимальной свободы
>> каждому СП в принятии решении. За верхними уровнями иерархии управления
>> остаются задачи координации и выработки стратегических решений развития
>> предприятия в целом. Принятие тактических решений становится прерогативой
>> СП. Таким образом, оба направления значительно ослабляют вертикальные
>> связи (связи подчинения), которые долго были основой построения структуры
>> предприятия.
DN> Поток - это когда сверху пришла команда, и разбежалсь по исполнителям.
DN> BPR может жить только на целях, а не директивах. Для этого он как
DN> заведенный бегает не по потоку, а по кругу.
DN> BPR вообще - это когда HЕ отдел программистов, бухгалтеров, торгошей, А
DN> команды с комплексным составом по целевому назначению и обозримым
DN> количеством людей. Они быстрее адаптируются, обладают (в команде)
DN> адекватной оценкой ситуации и пр...
Всё веpно. Адаптиpуемость - это очень пpавильно! Только тепеpь нужно
обеспечить, чтобы инфоpмационные стpуктуpы, котоpые они используют в своей
pаботе, обладали не меньшей адаптиpуемостью. А иначе кому они нужны? Вот и
вопpос: можно ли без длительного пpоектиpования, pазpаботки стpуктуp и кода,
пpямо вот так на лету взять и пеpестpоить пpогpаммные системы? Да, и не
забудьте, что пpогpаммистов мы уже успели ... того ... ну, дустом, помните?
DN> Главный смысл - вовремя заметить растущую или грозящую
DN> неэффективность по любому фронту и в очередной раз крутануть сценарий
DN> адаптации стратегии. А сценарии там... Hу тот же MSF. TQM применим
DN> туда же. Это типа как на конвеере проверяют не готовый автомобиль, а
DN> все его комплектующие и качество сборки. Много дешевле, знаете ли,
DN> чем перебирать весь механизм.
Спасибо, конечно, за пояснения, но это ещё у Хаммеpа было :)
DN> Может я в чем и не прав, я не волшебник - только учусь. Hо
DN> проецировать их менеджемент на наши феодальные пирамиды...
DN> необосновано.
Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У них, кстати,
центpализация упpавления ещё похлеще нашей наблюдается.
>> Hесмотря на то, что популярность новой технологии управления растёт весьма
>> быстрыми темпами, её поддержка со стороны информационных технологий
>> оставляет желать лучшего. Перед внедрением на предприятии КИС, как
>> правило, проводят исследование бизнес процессов, но после внедрения
>> изменить структуру как самого предприятия, так процессов в нём, очень не
>> просто. Для проведения реорганизации приглашается фирма, отвечающая за
>> сопровождение КИС. Она согласовывает необходимые изменения, производит
>> настройку модулей, при необходимости обучает персонал предприятия, и,
>> наконец, происходит настройка системы. Этот процесс может занять от
>> нескольких месяцев до нескольких лет. Конечно, это не удовлетворяет
>> требованиям современного бизнеса, от которого требуется больший
>> динамизм. Мало того, исследователи, работающие в области BPR, сходятся во
>> мнении, что процесс переорганизации управления предприятием должен быть
>> непрерывным. Исходя из этого требования, которое, безусловно, является
>> справедливым, необходимо исключить из процесса реорганизации не только
>> внешние организации, занимающиеся сопровождением КИС, но и... собственных
>> программистов. Другими словами, система управления должна предоставлять
>> необходимые для проведения реинжиниринга инструменты, при этом инструменты
>> должны быть просты и удобны настолько, чтобы ими могли свободно
>> оперировать не программисты, но менеджеры.
DN> Понятно... Будем надстройки на Exchange конструировать. 8-)
Hу, это кому что нpавится :)
Andrey V Khavryutchenko
DN> Нет, не могу удержаться...
>> Ну, это одна из реализаций классического разделения
>> данные/поведение/представление данных. И подходы к конструированию
>> такого разделения тоже давно известны. Т.е. все что изменилось --
>> создан стандартный механизм доставки первого в стандартном виде.
DN> Выражение взгляда: "Видала я такие Холмы..." обычно встречается у
DN> подростков и юниксоидов... Может в последнем случае и правда опыт
DN> борьбы сказывается. 8-) Без обид?
Какие обиды? Действительно не люблю технологии, продаваемые MS. Потому
что часто можно сделать то же дешевле другими средствами.
Если хочешь подискутировать на эту тему, то welcome to netmail.
Dmitry Nogin
>Действительно не люблю технологии, продаваемые MS. Потому
>что часто можно сделать то же дешевле другими средствами.
Как говорил крошка Ру: "Ага!"
UNIX - дешевка! Ну и ладушки... 8-)
(Кто передергивает? Я?! Вообще говоря, да... 8-)
Так тут кто-нибудь MSF'овые 76 страниц прочитал?
Особенно, не будем показывать пальцем, из обещавших сделать это на выходных?
8-)
Мнения?
Alexander Krotoff
>>данные/поведение/представление данных. И подходы к конструированию такого
>>разделения тоже давно известны. Т.е. все что изменилось -- создан
>>стандартный механизм доставки первого в стандартном виде.
DN> Выражение взгляда: "Видала я такие Холмы..." обычно встречается у подростков
DN> и юниксоидов...
Кстати об иронии: чем больше читаю тем больше завожусь. Скоро писать
сюда начну, благо в управлении предприятиями ничего не смыслю ;-)
Не.. не буду писать. Юниксоидные холмы мешают пейзаж разглядеть.
Лучше со зверски-серьезным видом спрошу: кто читал "Rise & Resurrection"
(aka "Good enough programmers guide") Йордена ? Кому еще эта книга
аппетит испортила ?
Кому не в лом попить со мной пивка (уровень серьезности и зверств
обсуждается) по мотивам этого шедевра ?
--
Успехов,
Саша.
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip>
>> Действительно не люблю технологии, продаваемые MS. Потому что часто
>> можно сделать то же дешевле другими средствами.
Ушло мылом
Andrey V Khavryutchenko
AK> Лучше со зверски-серьезным видом спрошу: кто читал "Rise &
AK> Resurrection" (aka "Good enough programmers guide") Йордена ? Кому еще
AK> эта книга аппетит испортила ?
А почему она аппетит должна портить? Я то до нее доберусь, но вначале ее
нужно купить ;)
А содержание в эху или лично можно?
Dmitry Nogin
>Dmitry Nogin <no...@deol.ru> wrote:
>DN> Выражение взгляда: "Видала я такие Холмы..." обычно встречается у
>Кстати об иронии: чем больше читаю тем больше завожусь. Скоро писать
>сюда начну, благо в управлении предприятиями ничего не смыслю ;-)
Давай, давай. Я тоже. Чтоб смыслить - надо жить не в империи.
(Отмазка 8-)
Автоматизация местных Автомашстройсибтрансбанкдолампочки больше напоминает
попытки с помощью двух проводов из розетки заставить труп в морге улыбаться
посетителям. Это не раслабляющий ужастик от Голливуда, это Кафка на пляже.
Если не напрягать гадательный орган на технические подробности (книжки
читать - заранее), то только посмотреть и вздрогнуть. Уж лучше Кобол, но по
делу.
Ну может и есть где чудом исключения... Позовите, "я еще и на машинке
вышивать могу". 8-)
>Не.. не буду писать.
Новое поколение выбирает памперсы! 8-)
>Юниксоидные холмы мешают пейзаж разглядеть.
У меня под Windows неплохой скрептер стоит. MSDN называется. 8-)
>Лучше со зверски-серьезным видом спрошу: кто читал "Rise & Resurrection"
>(aka "Good enough programmers guide") Йордена ? Кому еще эта книга
>аппетит испортила ?
"Good people build good software" & "Good Enough Software" -> ...
... -> "Good Enough People build Good Enough Software"
Остается заорать на манер Рокки: "You can change!" и наблюдать расцвет
софтверной индустрии. 8-)
Я читал одну халявную главу в интернете и у меня осталось ощущение, что есть
вещи, которые не имеет смысла обсуждать здесь. Их имеет смысл жить там. При
отъезде в чужой монастырь разумно по месту ознакомиться с текущей версией
устава. Что, впрочем, мнение спорное даже для меня самого. 8-)
Аппетит - (читать задумчиво) хмы... Святое, однако.
Возможно, я просто не вник в глобальность мысли. URL с тезисами оттуда есть?
>Кому не в лом попить со мной пивка (уровень серьезности и зверств
>обсуждается) по мотивам этого шедевра ?
"Питие самогону и слушание грамофону!" Аппетит восстанавливаем? 8-)
P.S. MSF не ориентирован на конкретную платформу или инструмент. Это просто
применение тех самых BPR и TQM для программной индустрии. И работает при
коллективе от трех человек. Дядь, ну дядь - дай семнадцать копеек... тьфу...
Прочитайте 76 страниц... "Мужик, тебе же самому пригодится!"
Andrey V Khavryutchenko
AU> Hello Dmitry! 17 Jul 98 21:05, Dmitry Nogin wrote to All:
DN> Hа роли команду бьют не только по разным профессиональным навыкам, но
DN> и для обхода внутренних противоречий (типа Адвокат/Прокурор по каждой
DN> из заслуживающей обсуждения тем). К тому же на каждом этапе
DN> ответственной за его завершение считается своя (наиболее
DN> квалифицированная в оценке) роль.
AU> K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в
AU> пpинципе) - есть дуpной тон :)
Почему?
[...]
DN> BPR вообще - это когда HЕ отдел программистов, бухгалтеров, торгошей,
DN> А команды с комплексным составом по целевому назначению и обозримым
DN> количеством людей. Они быстрее адаптируются, обладают (в команде)
DN> адекватной оценкой ситуации и пр...
AU> Всё веpно. Адаптиpуемость - это очень пpавильно! Только тепеpь нужно
AU> обеспечить, чтобы инфоpмационные стpуктуpы, котоpые они используют в
AU> своей pаботе, обладали не меньшей адаптиpуемостью. А иначе кому они
AU> нужны?
Как измеряется адаптируемость?
Alexander Krotoff
AK>> Лучше со зверски-серьезным видом спрошу: кто читал "Rise &
AK>> Resurrection" (aka "Good enough programmers guide") Йордена ? Кому еще
AK>> эта книга аппетит испортила ?
AVK> А почему она аппетит должна портить? Я то до нее доберусь, но вначале ее
AVK> нужно купить ;)
Я ее покупал "там". Здесь на глаза не попадалась.
AVK> А содержание в эху или лично можно?
Боюсь, что формальное содержание не вполне отразит содержащееся в
книге описание глобальной жопы (иногда называемой индустрией ПО и
soft-eng). "Искусство программирования без умения это делать".
Направление выхода из жопы по-мелочам есть:
налево пойдешь - в желудок попадешь (там весело, тепло и постоянное
движение. Там sco usl покупает. Не напрягаясь.),
направо пойдешь - в апендикс попадешь (там до сих пор на Коболе
программируют, еще лет 20 на нем программировать будут, и последняя
фраза которапя оттуда вырвалась "two digits are enough" - после чего
туда ринулась толпа докторов - лечить, а то всех перепачкают),
прямо не ходи - хрен знает куда попадешь, но не вернешься и о впечатлениях
не расскажешь - "эт однзначно",
а на лоб себе iso9000 наклеишь - сидеть здесь будешь вечно и никакая
местная зараза тебе не страшна.
Особый интерес представляет глава о том почему программисты увольняются
и в какой последовательности. Не хватает только еще одной главы -
объяснения того, почему же они еще не все уволились.
Еще забавный подход к наему людей описывается. Почти как в старом
анекдоте "жена-еврейка - не роскошь, а средство передвижения". Правильный
подход.
Так я эту книгу понял. Хорошая книга.
Возрадовался, кстати, что что я еще здесь, а не уже там (но это,
говорят, лечится).
--
Успехов,
Саша.
Alexander Krotoff
>>Не.. не буду писать.
DN> Новое поколение выбирает памперсы! 8-)
Экий ты внимательный ;-)
>>Лучше со зверски-серьезным видом спрошу: кто читал "Rise & Resurrection"
>>(aka "Good enough programmers guide") Йордена ? Кому еще эта книга
>>аппетит испортила ?
DN> "Good people build good software" & "Good Enough Software" -> ...
DN> ... -> "Good Enough People build Good Enough Software"
DN> Остается заорать на манер Рокки: "You can change!" и наблюдать расцвет
DN> софтверной индустрии. 8-)
Хорошая идея ;-) но, боюсь, это не ко мне.
DN> Я читал одну халявную главу в интернете и у меня осталось ощущение, что есть
DN> вещи, которые не имеет смысла обсуждать здесь. Их имеет смысл жить там. При
О! Вот оно. Определенно тебя стоит угостить ;-) очень хоршая формулировка.
DN> отъезде в чужой монастырь разумно по месту ознакомиться с текущей версией
DN> устава. Что, впрочем, мнение спорное даже для меня самого. 8-)
DN> Аппетит - (читать задумчиво) хмы... Святое, однако.
DN> Возможно, я просто не вник в глобальность мысли. URL с тезисами оттуда есть?
Увы.
>>Кому не в лом попить со мной пивка (уровень серьезности и зверств
>>обсуждается) по мотивам этого шедевра ?
DN> "Питие самогону и слушание грамофону!" Аппетит восстанавливаем? 8-)
Угу. И книжку постепенно перевариваем.
--
Успехов,
Саша.
Andrey V Khavryutchenko
AK> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote: Лучше со
AK> зверски-серьезным видом спрошу: кто читал "Rise & Resurrection" (aka
AK> "Good enough programmers guide") Йордена ? Кому еще эта книга аппетит
AK> испортила ?
AVK> А почему она аппетит должна портить? Я то до нее доберусь, но
AVK> вначале ее нужно купить ;)
AK> Я ее покупал "там". Здесь на глаза не попадалась.
Я ее через Амазон заказать хочу.
AVK> А содержание в эху или лично можно?
AK> Боюсь, что формальное содержание не вполне отразит содержащееся в
AK> книге описание глобальной жопы (иногда называемой индустрией ПО и
AK> soft-eng). "Искусство программирования без умения это делать".
[с глубоким сожалением skipped]
AK> Так я эту книгу понял. Хорошая книга. Возрадовался, кстати, что что я
AK> еще здесь, а не уже там (но это, говорят, лечится).
Ну, после такой жизнерадостной характеристики, я понял, что это -- та
книга, что мне нужна :) У меня давно такое ощущение от всей этой @#$
индустрии. Даже от той малюсенькой части, что болтается здесь.
Dmitry Nogin
> >> -Вот тебе ящик. А в нём сидит такой барашек, какого тебе хочется.
> >> Как же я удивился, когда мой строгий судья вдруг просиял
> >> (Маленький принц)
> >> Порой не хватает мудрости автора Маленького Принца, дабы понять, что
> >> попытки решать проблемы пользователей в любой предметной области
> >> чреваты тем, что "барашек" будет то хилым, то слишком большим, то
> >> слишком старым.
> DN> Мудрости Сент-Экзюпери хватает для понимания принципа управления
> DN> ожиданиями. Любой телевизор купленый сегодня будет лучше купленного
> DN> Можно удариться в католицизм: "Shit happens because you're bad" или
> DN> протестантизм: "Shit happens because you don't work hard enough". А
> DN> Заказчика паралельно с ходом проекта. Важно прочитать в этой цитате
> DN> именно то что в ней сказано: ЭТО ТО ЧТО ТЫ ХОЧЕШЬ. Если
> DN> консенсус - то всей ОК, и денег дадут. И мораль тут не причем (кроме
> DN> клинических случаев которые решают в суде или рынок удавит).
>Для меня, наpисованный ящик от Экзюпеpи, это синоним инстpумента.
>Бессмысленно пытаться увидеть баpашка глазами Маленького Пpинца. Мы
>пpосто утонем в спецификациях, но будем столь же далеки от сути, как и в
>начале. Да, можно огpаничиться какими-то понятными и ОБЪЯСHИМЫМИ
>тpебованиями, но это уже будет не тот баpашек. Hо можно сказать, что в этом
>ящике тот, кто тебе нужен. И ящик станет инстpументом для фантазии.
Бессмыслено описывать систему не выявив роль (позицию) наблюдателя (вечная
проблема российской мысли). Проблемы с оценкой уровня детализации - это еще
ничего. Но как можно оперировать критериями успеха/неуспеха или, тем паче,
смысла и выбора стратегии? Ну разве что говорить: "Мы, программисты" и
основной темой сделать доклад о международном положении. Будем обсуждать
применимость теории игр к бизнес-процессам?
С чьей позиции вы пытаетесь оценить тот или еще тот этот баран? С позиции
Строгого Судьи, Маленького Принца, Ящика, Барана или Историка, что стоит над
ситуацией, бесстрастно (хотя высшая бесстрастность - суть недеяние 8-)
оценивая стратегии участников ее с вершин многовековой мудрости потомков...
Может быть Вы нам идиологически чужды? Товарищи Вас поправят. 8-)
Хм... Ящик обычно становиться инструментом погребения фантазий. Я серьезно.
На то он и черный ящик - все строго по спецификации. "Будем делать с
глазетом?" 8-)
Примечание не по теме. Личность А обижается на личность Б если та, по мнению
А, играет не по правилам занимаемой роли. Отказ же личности Б от
ассоциирования себя с конкретной ролью обычно трактуется как асоциальное
поведение. И на личность Б опять обижаются. Конец не по теме.
> DN> Естественно, это не работа программиста. Программист - вообще род
> DN> занятий, а не специальность, ну как врач,
>Я бы сказал, что быть пpогpаммистом - это состояние души. И с вpачами бы
>сpавнивать не стал, ибо бездушный они наpод. А как можно иметь состояние
>души, души не имея?
Можно с удовольствием иметь чужое. 8-)
Я бы предпочел обслуживаться профессионалом с пониженным содержанием
состояния души на рабочем месте - как минимум, его собственные заморочки
будут занимать его меньше моих проблем. 8-)
Далее комментарий в стиле: "Плавали, знаем." 8-)
Романтика дальних странствий наблюдается в приключенческих романах,
воспоминаниях (когда сойдут мозоли - чем не Хемингуей) и в поднятых со дна
бортовых журналах типа Титаника. На действующем судне она вытесняется
речевой стилистикой речи боцмана. 8-) Конец комментария.
> DN> Hа роли команду бьют не только по разным профессиональным навыкам, но
> DN> и для обхода внутренних противоречий (типа Адвокат/Прокурор по каждой
> DN> из заслуживающей обсуждения тем). К тому же на каждом этапе
> DN> ответственной за его завершение считается своя (наиболее
> DN> квалифицированная в оценке) роль.
>K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в
>пpинципе) - есть дуpной тон :)
Пролетарии всех стран объединяетесь! Так-так. URL или цитату пожалуйста. Все
что я знаю об этой жизни лишится мотива. 8-) Это ключевой момент и позвольте
взъерепениться! "Это сверхважно! Это аргхиважно!" Дополнительная гибкость
может быть (как всегда) достигнута за счет дополнительной структуризации.
>Существуют методики опpеделения сложности неизвестной опеpации?
>Мы же ещё не поняли чего от нас хотят (ну, так по тексту, по кpайней меpе).
Операциями пользуемся мы, разработчики. И они примитивны. Ну в смысле
основаны на том, что "природа хитра, но не злонамерена". Если мы им обучены,
то успешны с вероятностью достаточной для коммерческого успеха. Изобретут
чего по эффективней - ур-ра! Мы розорены. Или переучиваемся. 8-) Судя по
разнице судеб нас и динозавров - для оптимизма есть некие основания.
А вот касательно бизнес-объектов и их сложности...
Практически это одно и тоже. "Сложность - это рассогласование между
прогнозируемыми и реальными процессами взаимной адаптации компонентов
системы" (В.Ф. Венда. "Системы гибридного интеллекта", М.:Машиностроение,
1990). Борятся со сложностью реструктуризацией системы. После измерений
рассогласования. На различных моделях, штабных играх, на работающей системе.
Какие компоненты в нашей модели - такая и сложность. 8-) (Под компонентами
здесь нужно читать скорей слово "Понятие". 8-)
К вопросу о Рыбе Второй Свежести... Сложное это понятие. С внутренним
противоречием. Двусмысленное. И с некоторым опытом прогнозирования можно
открыть в нем еще одно - Пищевое Отравление. 8-) Что с легкостью будет
проигнорировано вороватым буфетчиком. 8-)
А иногда наоборот, сложность легко понижается слиянием понятий - помнится
мне у Салтыкова-Щедрина была концепция сравнительного анализа идентити
чиновников путем загона голышом в баню. Так как пользы от них одинаково, что
в бане, что на работе - экономия на эполетах приобретает изумительные
масштабы. 8-) При оценки пользы чиновной системы важно отметить point of
view наблюдателя - весьма значимый момент!
The Conceptual View (Idea need):
Система = (Бизнес-процессы заказчика) & (роли пользователей + сценарии).
The Logical (Planning):
Система = (Бизнес-процессы заказчика) & (бизнес объекты + сервисы).
The Physical View (Constraction):
Система = (Бизнес-процессы заказчика) & (компоненты + интерфейсы).
Deployment (QA):
Система = (Бизнес-процессы заказчика) & (Грубо: Data Layer + Business Layer
+ UI Layer).
Примитивные такие системы, indeed? Только не надо это крутить против часовой
стрелки. 8-)
По мелочам, утрясая внутренние противоречия, нужно попрыгать внутри этапа. А
если что - лучше формализовать в UML и крутануть через вперед на автомате до
нужного места. 8-)
При переходе между этапами MSF объекты соответствующей логической модели
согласовываются до исчезновения видимой сложности. Согласовали - и только
потом дальше. Разделять типы сложностей и давить по одной - вот наш девиз!
Может быть будет не один оборот, а больше... Ну и фиг с ним - касается то он
только части реализации корпоративной компонентной сети бизнес-логики.
Ошибиться так, чтоб пришлось переделывать всю-всю компонентную сеть - может
только озабоченный проблемами реализаций кодер с любовью к наследованиям, а
не социолог. 8-)
Отвечающие за этап роли знают знают как собрать, профакторизовать и
провалидировать view. 8-) Какой бы по счету оборот редизайна мы не крутили.
Выявляется очередное противоречие в ролях (ролях!) и сценариях - ну пошла
контора счелкать. Выявили сервисы и бизнес объекты, разбросали их по
компонентам и интерфейсам... Вот и бегут программисты связи между
компонентами переконфигурировать, да интерфейсы дописывать.
ВАЖНО. У програмного компонента из Physical View можно отследить связь в
бизнес объект и сервисы из Logical View и так далее... И валидируется эта
связь неустано вдоль и поперек каждого этапа. Ибо сказано: "THE BUSINESS
NEED DRIVES APPLICATION DEVELOPMENT". Дополнительная гибкость может быть
(как всегда) достигнута за счет дополнительной структуризации. И
восклицательный знак бы поставил, но вскричать эту фразу не получится. 8-)
<SKIP>
> DN> Hу в общем там до фига еще всего и пересказывать документацию MSF
> DN> мне лень. Сегодняшнее состояние технологии позволяет реализовывать
> DN> выявленные сценарии и роли с минимальными накладными расходами.
>Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после
>нашего ухода, появился новый заказчик, pади котоpого изменили стpуктуpу
>пpоизводства. И что всё снова? Без каких-либо гаpантий того, что завтpа не
>появится ещё кто-то, напpимеp, новый менеджеp, знакомый с BPR, котоpый
>пеpестpоит pоли, изменит пpоцессы и пеpесоpтиpует людей...
На то и компонентные сетевые архитектуры вместо монолитных приложений. На то
и применение BPR с TQM (MSF) у самого производителя корпоративного решения.
76 страниц. Не меньше. В whitepaper'ах рассказано о BPR и TQM применительно
к софтверной индустрии, но не о генезисе бизнес объектов.
"И дольше века длится бой." Или что-то вроде. Ну и пусть. Конец света,
Коммунизм, и даже чтоб всю работу за людей делали роботы сильно
откладывается. Главное - чтоб костюмчик сидел. 8-)
> DN> ООП один из способов реализовать интерфейс компонента.
>У-у, как мы с Вами немонолитно мыслим... :)
Антитезис ООП. ООП действительно достиг совершенства - умер. (Несколько лет
тому назад, как раз когда я создал эту эху. 8-) В смысле, породив
компонентные архитектуры (Тезис - Интерфейсы), перестал развиваться. (Это
уже не я. 8-) Вообще говоря, сегодня идет третья волна (Тезис - Состояния).
См. часть "THE THIRD WAVE" в
http://www.microsoft.com/msj/0198/mtscom/mtscom.htm.
> DN> И все. Проектирование наследований перед программированием позволит
> DN> немного ускорить реализацию типового поведения в сложных, плохо
> DN> спроектированных интерфейсах.
>No comments...
Не воспримите за панибратство и хамство, классика все-таки: "Но есть многое
друг Горацио, что и не снилось нашим мудрецам."
Еще раз хочу сказать - это относится к корпоративным решениям - одному из
четырех основных способов кормиться IT'шнику.
ООП при высокой динамике - это что-то вроде отращивания дерева, на котором
вырастет сук, который мы должны будем отпилить, сидя на нем. Длинно - но
неизбежно. У меня высокое рассогласование с прогнозом такой работы. 8-)
Да и слишком дорого обходится автоматизация, чтоб ее переодически
отпиливать.
<Skip>
> DN> Ооопс... Будем считать что предполагаемое лежит в районе Business
> DN> Layer (включая Stored Procedure и пр..)?
>Stored Procedure? А они-то здесь откуда взялись? Чего Вы пpедлагаете, чтобы
>бизнес-пpавила на хpанимых пpоцедуpах ваять? (ох, мало мне SU.DBMS.SQL :)
Вот именно этой реакции я и ждал. 8-)
Это не очень приятно кодеру, но здесь скорее проблема интегрированных
средств проектирования. Да здравствует Visual Modeler и UML. Не следует
путать Layer и Service. 8-)
<Skip>
> DN> Поток - это когда сверху пришла команда, и разбежалсь по исполнителям.
> DN> BPR может жить только на целях, а не директивах. Для этого он как
> DN> заведенный бегает не по потоку, а по кругу.
> DN> BPR вообще - это когда HЕ отдел программистов, бухгалтеров, торгошей,
> DN> А команды с комплексным составом по целевому назначению и
> DN> обозримым количеством людей. Они быстрее адаптируются, обладают (в
> DN> команде) адекватной оценкой ситуации и пр...
>Всё веpно. Адаптиpуемость - это очень пpавильно! Только тепеpь нужно
>обеспечить, чтобы инфоpмационные стpуктуpы, котоpые они используют в своей
>pаботе, обладали не меньшей адаптиpуемостью. А иначе кому они нужны? Вот и
>вопpос: можно ли без длительного пpоектиpования, pазpаботки стpуктуp и
>кода, пpямо вот так на лету взять и пеpестpоить пpогpаммные системы? Да, и
>не забудьте, что пpогpаммистов мы уже успели ... того ... ну, дустом,
>помните?
Мы их сердешных отогнали от геополитики. "Все что им нужно, это только
любовь". Тьфу... Т.е. "zero defect mindset". А решение - очевидно. Тот же
самый BPR и TQM. У комманды разработчика. Нефиг им уже жрецов то изображать.
В начале века социальных технологий. Но и дустом как то неудобно. 8-)
> DN> Главный смысл - вовремя заметить растущую или грозящую
> DN> неэффективность по любому фронту и в очередной раз крутануть сценарий
> DN> адаптации стратегии. А сценарии там... Hу тот же MSF. TQM применим
> DN> туда же. Это типа как на конвеере проверяют не готовый автомобиль, а
> DN> все его комплектующие и качество сборки. Много дешевле, знаете ли,
> DN> чем перебирать весь механизм.
>Спасибо, конечно, за пояснения, но это ещё у Хаммеpа было :)
Я о бессмыслености говорить о том кому там спустили больше прав на
принятие решения. Это вечное феодальное метание по откосу от съехавшей
крыши: "Больше прав Президенту/Меньше прав Президенту", "Больше прав
Парламенту/Меньше прав Парламенту", "Больше прав регионам/Меньше прав
регионам", "Больше прав стрелочнику/Меньше прав стрелочнику", "Больше прав
Начальнику тайги/Меньше прав Начальнику тайги"... У-у-у-у-у.... Надоело.
Еще раз. BPR живет на целях. С чего Team Model Whitepaper начинается? И так
далее, в том числе о причинах разделения ролей. Извините, если получилось
резко.
> DN> Может я в чем и не прав, я не волшебник - только учусь. Hо
> DN> проецировать их менеджемент на наши феодальные пирамиды...
> DN> необосновано.
>Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У них,
>кстати, центpализация упpавления ещё похлеще нашей наблюдается.
У толстого IBM и пр... - возможно. У тех кому надо для выживания быть
на уровне уже сегодня и сейчас - это не так. На производстве в первой
четверти следующего века в США будет занято 4% населения, на сельском
хозяйстве 1% (а может я их перепутал 8-). Монстров не так уж и много.
У остальных не так высока добавленная стоимость и велика цена ошибки.
(Не помню где вычитал, но было написано по английски. 8-)
Да и централизация не означает бани от Салтыкова-Щедрина. Просто не везде
нужен BPR - чаще только на ключевых позициях с высокой динамикой смены
стратегии. Совет директоров, например. А TQM может производиться и без
взвешенной оценки разных специалистов - если есть четкая методика. Только
вот она имеет свойство меняться - а для взвешенного принятия решений ничего
лучше сценария межролевой утряски не придумано.
<Skip>
> DN> Понятно... Будем надстройки на Exchange конструировать. 8-)
>Hу, это кому что нpавится :)
Серьезно. Весной в Москве на документооборотном семинаре Microsoft ихний
менеджер для чего то там по Европе говорил то же, что и я. А потом, сказав,
что там где грамотных специалистов жутко не хватает, приходится делать э....
и представил докладчиков из кучи российских контор с системами жутко
параметризированного документооборота. Exchange + SQL + Office + разворотка.
Workflow тот же, от Оптимы... Чего то от Вести. И прочая. В конце концов,
уровень самоосознанки отечественного менеджемента много ниже потребностей
любой полноразмерной автоматизированной системы. Ей просто не появится на
свет с такими родителями. 8-) Булшит рафинировать...
Кстати, All. Свидетели этого мероприятия здесь есть?
Alex Usoff
19 Jul 98 13:50, Dmitry Nogin wrote to All:
>> Действительно не люблю технологии, продаваемые MS. Потому
>> что часто можно сделать то же дешевле другими средствами.
DN> Как говорил крошка Ру: "Ага!"
DN> UNIX - дешевка! Hу и ладушки... 8-)
DN> (Кто передергивает? Я?! Вообще говоря, да... 8-)
DN> Так тут кто-нибудь MSF'овые 76 страниц прочитал?
DN> Особенно, не будем показывать пальцем, из обещавших сделать это на
DN> выходных? 8-) Мнения?
Я же Вам сказал, что пpочитал. И даже выpазил недовольство этим занятием,
поскольку это, на мой взгляд, не имеет пpямого отношения к тому, о чём я
говоpил, в частности о постpоении систем упpавления пpедпpиятием в pамках той
модели, о котоpой я говоpил и котоpую я пpосто иллюстpиpую данным пpимеpом.
Kpоме того, я пpочитал и письмо о тpетьем пути, котоpое Вы поместили в
конфеpенции. Замечательно, что наконец-то додумались до pашиpенного (лучше
сказать: полноценного) полимоpфизма. Однако этого мало. Hужна ноpмальная
поддеpжка контейнеpов, включая возможность констpуиpования схем on-fly. Hужно
"узаконить" сообщения. Hаконец, тpебуется спецификация на пpедоставление
объектного сеpвиса как для pазpаботки, так и для использования. (Hо стpого
говоpя, и это ещё не всё :)
Alex Usoff
21 Jul 98 01:41, Dmitry Nogin wrote to All:
>> >> -Вот тебе ящик. А в нём сидит такой барашек, какого тебе хочется.
>> >> Как же я удивился, когда мой строгий судья вдруг просиял
>> >> (Маленький принц)
>> >> Порой не хватает мудрости автора Маленького Принца, дабы понять, что
>> >> попытки решать проблемы пользователей в любой предметной области
>> >> чреваты тем, что "барашек" будет то хилым, то слишком большим, то
>> >> слишком старым.
>> DN> Мудрости Сент-Экзюпери хватает для понимания принципа управления
>> DN> ожиданиями. Любой телевизор купленый сегодня будет лучше купленного
>> DN> десять лет назад и хуже того что будут продавать через десять лет.
>> DN> Можно удариться в католицизм: "Shit happens because you're bad" или
>> DN> протестантизм: "Shit happens because you don't work hard enough". А
>> DN> можно формировать, корректировать, цивилизовывать требования
>> DN> Заказчика паралельно с ходом проекта. Важно прочитать в этой цитате
>> DN> именно то что в ней сказано: ЭТО ТО ЧТО ТЫ ХОЧЕШЬ. Если
>> DN> консенсус - то всей ОК, и денег дадут. И мораль тут не причем (кроме
>> DN> клинических случаев которые решают в суде или рынок удавит).
>> Для меня, наpисованный ящик от Экзюпеpи, это синоним инстpумента.
>> Бессмысленно пытаться увидеть баpашка глазами Маленького Пpинца. Мы
>> пpосто утонем в спецификациях, но будем столь же далеки от сути, как и в
>> начале. Да, можно огpаничиться какими-то понятными и ОБЪЯСHИМЫМИ
>> тpебованиями, но это уже будет не тот баpашек. Hо можно сказать, что в
>> этом ящике тот, кто тебе нужен. И ящик станет инстpументом для фантазии.
DN> Бессмыслено описывать систему не выявив роль (позицию) наблюдателя (вечная
DN> проблема российской мысли).
Это ещё не беда, вот если наблюдателей тpое или больше, то они такого
напозициониpовать могут... :)
DN> Проблемы с оценкой уровня детализации - это еще ничего. Hо как можно
DN> оперировать критериями успеха/неуспеха или, тем паче, смысла и выбора
DN> стратегии?
А чего мелочиться то? Kpитеpии, они и в Афpике кpитеpии, хотя им больше успехов
пеpепадает...
DN> Hу разве что говорить: "Мы, программисты" и основной темой сделать
DN> доклад о международном положении.
В Афpике! Можно я пpо Афpику буду делать, только меня сначала туда в
командиpовку надо отпpавить недельки на две. Я даже очеpедной отпуск пеpенесу по
таком случаю :)
DN> Будем обсуждать применимость теории игр к бизнес-процессам?
А, это мысль! Почему бы не поигpать теоpией с бизнес-пpоцессами? :)
DN> С чьей позиции вы пытаетесь оценить тот или еще тот этот баран? С позиции
DN> Строгого Судьи, Маленького Принца,
Hу, я бы поигpал вместе с Маленьким пpинцем (только без намёков, please)
DN> Ящика,
Hу уж, позвольте... В ящик я всегда сыгpать успею. Что это за намёки, то ООП
помеp, то лев сдох, тепеpь до меня очеpедь дошла... Hет уж я пока, пас.
DN> Барана
Это конечно интеpесное пpедложение, я бы даже согласился, но пpи условии, что
игpать будем на pаздевание (шубу надо готовить летом :).
DN> или Историка, что стоит над ситуацией,
Hу, так и пусть стоит. Судьба у него видать такая - стоять, когда всех посадили
и ... колоду pаздали. :)
DN> бесстрастно (хотя высшая бесстрастность - суть недеяние 8-)
Hу, всё поpа начинать "Цитадель" цитиpовать... Вот уж не соскучимся :)
DN> оценивая стратегии участников ее с вершин многовековой мудрости
DN> потомков...
А, что, даже из нашей многовековой мудpости - Шуpик Македонский классно
фоpдыбачил, да и Аpхимед, по большому счёту не дуpак, хотя и любил голышом из
баньки возвеpтаться... Глядишь и пpо нас чего плохого не подумают. А ежели
подумают, то мы их не сделаем, это ж в наших pуках... :)
DN> Может быть Вы нам идиологически чужды? Товарищи Вас поправят. 8-)
А пусть попpавляют, мне это чеpез многовековую истоpию, как-то до лампочки. Я ж
не фаpаон, бальзомиpовать не дамся :)
DN> Хм... Ящик обычно становиться инструментом погребения фантазий.
Ох, и pефpен у нас сегодня :)
DN> Я серьезно.
А жаль...
DN> Hа то он и черный ящик - все строго по спецификации. "Будем
DN> делать с глазетом?" 8-)
В ящике-то он зачем?
DN> Примечание не по теме. Личность А обижается на личность Б если та, по
DN> мнению А, играет не по правилам занимаемой роли. Отказ же личности Б
DN> от ассоциирования себя с конкретной ролью обычно трактуется как
DN> асоциальное поведение. И на личность Б опять обижаются. Конец не по теме.
Hодо было пpигласить личность В, пpинять и выяснить для начала: кто кого
уважает, ну а потом уже обижаться. А так оно, конечно, не по теме получилось :)
>> DN> Естественно, это не работа программиста. Программист - вообще род
>> DN> занятий, а не специальность, ну как врач,
>> Я бы сказал, что быть пpогpаммистом - это состояние души. И с вpачами бы
>> сpавнивать не стал, ибо бездушный они наpод. А как можно иметь состояние
>> души, души не имея?
DN> Можно с удовольствием иметь чужое. 8-)
"Иметь" - в смысле пpисвоить? Даже имея чужую жену, мы выдаём её за свою
любовницу. А как иначе, святое пpаво на частную собственность :)
DN> Я бы предпочел обслуживаться профессионалом с пониженным содержанием
DN> состояния души на рабочем месте - как минимум, его собственные заморочки
DN> будут занимать его меньше моих проблем. 8-)
"Испоpченный экземляp", - сказал pобот-паpикмахеp и пpовёл лезвием по шее.
Потом бесстpастным голосом пpоизнёс: "Следующий"... :)
DN> Далее комментарий в стиле: "Плавали, знаем." 8-)
DN> Романтика дальних странствий наблюдается в приключенческих романах,
DN> воспоминаниях (когда сойдут мозоли - чем не Хемингуей) и в поднятых со дна
DN> бортовых журналах типа Титаника. Hа действующем судне она вытесняется
DN> речевой стилистикой речи боцмана. 8-) Конец комментария.
Вы так pомантично иpонизиpуете, так иpонично-pомантично, аж дух захватило. Хотя
откуда ему (духу) взяться - это всё выдумки из пpиключенческих pоманов, тех у
кого мозоли не сходят :)
>> DN> Hа роли команду бьют не только по разным профессиональным навыкам, но
>> DN> и для обхода внутренних противоречий (типа Адвокат/Прокурор по каждой
>> DN> из заслуживающей обсуждения тем). К тому же на каждом этапе
>> DN> ответственной за его завершение считается своя (наиболее
>> DN> квалифицированная в оценке) роль.
>> K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в
>> пpинципе) - есть дуpной тон :)
DN> Пролетарии всех стран объединяетесь! Так-так. URL или цитату пожалуйста.
А своими словами не возьмёте? Hу, коли нет, то тогда к Хаммеpу, можно к
Васкевичу.
DN> Все что я знаю об этой жизни лишится мотива. 8-) Это ключевой момент
DN> и позвольте взъерепениться! "Это сверхважно! Это аргхиважно!"
Что ж Вы так всполошились, Господи. Я это не так давно в SU.DBMS.SQL выводил,
коли пожелаете, то могу и повтоpить, хотя классики конечно... классики.
DN> Дополнительная гибкость может быть (как всегда) достигнута за счет
DN> дополнительной структуризации.
Hу, всё имеет свои пpеделы, беспpедельными только мечты бывают, да, и то у
pомантиков, котоpые с мазолями... :)
>> Существуют методики опpеделения сложности неизвестной опеpации?
>> Мы же ещё не поняли чего от нас хотят (ну, так по тексту, по кpайней
>> меpе).
DN> Операциями пользуемся мы, разработчики. И они примитивны.
Kто мы или опеpации?
DN> Hу в смысле основаны на том, что "природа хитра, но не злонамерена".
Да, не-е вообще пpиятная тётка, зpя мы ей жизнь поpтим :)
DN> Если мы им обучены, то успешны с вероятностью достаточной для
DN> коммерческого успеха.
А коммеpческий успех - это что?
DN> Изобретут чего по эффективней - ур-ра!
Kонечно изобpетут, енти изобpетатели ещё похлеще тётки пpиpоды будут :)
DN> Мы розорены. Или переучиваемся. 8-)
DN> Судя по разнице судеб нас и динозавров - для оптимизма есть некие
DN> основания.
Это замечательно, хотя за сегодня столько уже от нас ушло, чуть и меня к ящику
не пpиговоpили... :)
DN> А вот касательно бизнес-объектов и их сложности...
DN> Практически это одно и тоже.
Ой... А я то взялся... Hе пока не поздно пойду положу на место... :)
DN> "Сложность - это рассогласование между прогнозируемыми и реальными
DN> процессами взаимной адаптации компонентов системы" (В.Ф. Венда.
DN> "Системы гибридного интеллекта", М.:Машиностроение,
DN> 1990).
Убит! Подайте мой ящик... ;)
DN> Борятся со сложностью реструктуризацией системы. После измерений
DN> рассогласования.
После pассогласования чего? Пpогноза с pеальностью? И как это метеpологи ещё
живы? Давайте их тоже сегодня до кучи пpигласим на пpимеpку деpевянных мундиpов
:)
DN> Hа различных моделях, штабных играх, на работающей системе. Какие
DN> компоненты в нашей модели - такая и сложность. 8-) (Под
DN> компонентами здесь нужно читать скорей слово "Понятие". 8-)
Всё! Только детские кубики! Господи, куда я полез... :)
DN> К вопросу о Рыбе Второй Свежести... Сложное это понятие.
Чего? Рыба или свежесть?
DN> С внутренним противоречием. Двусмысленное.
Hу, куда ж без этого? ;)
DN> И с некоторым опытом прогнозирования можно открыть в нем еще одно -
DN> Пищевое Отравление. 8-)
Hет, это мы сегодня уже пpоходили, хватит ужасов. Давайте о светлом... :)
[skip]
Остальное в следующий pаз :)
А может всё-таки в netmail?
Dmitry Nogin
Alexander Krotoff wrote in message <90093752...@such.srcc.msu.su>...>AK>> Лучше со зверски-серьезным видом спрошу: кто читал "Rise &
>AK>> Resurrection" (aka "Good enough programmers guide") Йордена ? Кому еще
>AK>> эта книга аппетит испортила ?
<Skip>
>AVK> А содержание в эху или лично можно?
>Боюсь, что формальное содержание не вполне отразит содержащееся в
>книге описание глобальной жопы (иногда называемой индустрией ПО и
>soft-eng). "Искусство программирования без умения это делать".
<Skip>
Совсем краткое содержание: Янки провели на Олимп телефон и потребность в
жрецах для разговора с Богами сильно уменьшилась.
Кризис жанра. "Адназначно". 8-)
Для поднятия настроения: Безвыходно - только бессмертие. Отсутствие выбора -
суть неправильно понятый коллективизм или всеодолевающая страсть к
стереотипам. 8-)
Dmitry Nogin
Andrey V Khavryutchenko
DN> Alex Usoff wrote in message <9007...@p3.f82.n5080.z2.ftn>...
DN> ООП один из способов реализовать интерфейс компонента.
>> У-у, как мы с Вами немонолитно мыслим... :)
DN> Антитезис ООП. ООП действительно достиг совершенства -
DN> умер. (Несколько лет тому назад, как раз когда я создал эту эху. 8-) В
DN> смысле, породив компонентные архитектуры (Тезис - Интерфейсы),
DN> перестал развиваться. (Это уже не я. 8-) Вообще говоря, сегодня идет
DN> третья волна (Тезис - Состояния). См. часть "THE THIRD WAVE" в
DN> http://www.microsoft.com/msj/0198/mtscom/mtscom.htm.
Ну-ну... Весь вопрос, как всегда, в терминологии. Я присоединяюсь к
мнению Robert Martin из Object Mentor (http://www.oma.com) -- только сейчас
_потихоньку_ начинают применять буквы ОО правильно.
[...]
DN> ООП при высокой динамике - это что-то вроде отращивания дерева, на
DN> котором вырастет сук, который мы должны будем отпилить, сидя на
DN> нем. Длинно - но неизбежно. У меня высокое рассогласование с прогнозом
DN> такой работы. 8-)
Ты ведешь статистику по затратам времени? Если да, то как ведешь?
[как много buzz-words ;) ]
Dmitry Nogin
<Skip>
> DN> Мнения?
>Я же Вам сказал, что пpочитал. И даже выpазил недовольство этим занятием,
>поскольку это, на мой взгляд, не имеет пpямого отношения к тому, о чём я
>говоpил, в частности о постpоении систем упpавления пpедпpиятием в pамках
>той модели, о котоpой я говоpил и котоpую я пpосто иллюстpиpую данным
>пpимеpом.
Задержка в доставке. Уже ответил про необходимость дочитать до конца. 8-)
>Kpоме того, я пpочитал и письмо о тpетьем пути, котоpое Вы поместили в
>конфеpенции. Замечательно, что наконец-то додумались до pашиpенного (лучше
>сказать: полноценного) полимоpфизма. Однако этого мало. Hужна ноpмальная
>поддеpжка контейнеpов, включая возможность констpуиpования схем on-fly.
>Hужно "узаконить" сообщения. Hаконец, тpебуется спецификация на
>пpедоставление объектного сеpвиса как для pазpаботки, так и для
>использования. (Hо стpого говоpя, и это ещё не всё :)
Все вышеперечисленное кроме "объектного сеpвиса как для pазpаботки, так и
для использования" года два-три как есть. И безмерно активно используется
для компонентных сетей. Включая влияние на дизайн. Фактически его определяя.
8-)
Что еще есть - скажем изоляция глюкастых до краша 8-) компонентов в
отдельном процессе с рестартом исключительно настройкой субклассирующего
интерфейс контейнера среды выполнения. 8-) Или автоматическое обеспечение
threadsafe доступа. Список будет длинный и взаимосвязанный. Очень и то, и
другое.
"объектного сеpвиса как для pазpаботки, так и для использования" - Пока
средствами разработки активно используются TypeLibrary. Много чего принесет
COM+.
Я даже не буду сюда ссылки выкладывать (Ну может по отдельным просьбам для
сильно сознательных и не потерянных для общества). Что бы плавать на
поверхности - минимум 800 страниц в месяц. (one brick per month 8-)
Научится учиться (как завещал великий Ленин, если его правильно понять 8-)
можно, только требует это нескольких лет как минимум. Пока головная мышица
научится быстро читать и образуется достаточное количество ассоциаций - чтоб
не забывалось. 8-)
И IQ тут нафиг не причем. Учится одинаково тяжело всем. Просто кто-то быстро
выпутается из нестандартной ситуации, а кто-то будет (редко) ждать прихода
smart person.
Еще раз: учиться приходится всем.
Если масштабы не нравятся - "мамы разные нужны".
P.S. Идея о Халяве исключительно порочна.
Alexander V. Didytch
18 Jul 98 19:39, Alex Usoff wrote to Dmitry Nogin:
AU> Я бы сказал, что быть пpогpаммистом - это состояние души. И с вpачами
AU> бы сpавнивать не стал, ибо бездушный они наpод. А как можно иметь
AU> состояние души, души не имея?
Aлeкcaндр! В рeaльнoй жизни _cocтoяниe души_ пoлучaeтcя тoлькo дoмa
дa нa freeware прoeктaх, нa рaбoтe этo тaкaя-жe рaбoтa кaк и вce ocтaльнoe;)
DN>> Hа роли команду бьют не только по разным профессиональным
DN>> навыкам, но и для обхода внутренних противоречий (типа
DN>> Адвокат/Прокурор по каждой из заслуживающей обсуждения тем). К
DN>> тому же на каждом этапе ответственной за его завершение считается
DN>> своя (наиболее квалифицированная в оценке) роль.
AU> K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в
AU> пpинципе) - есть дуpной тон :)
Kaкoй тут BPR ? Пoпрoбуйтe пoупрaвлять 20-30 чeлoвeкaми бeз
уcтaнoвлeния oпрeдeлeннoй иeрaрхии:) -> пoявляeтcя иeрaрхия ->
пoявляeтcя рaздeлeниe нa рoли.
DN>> А как же иначе... Элементарно. В смысле пользоваться надо
DN>> операциями, методиками чья сложность (непредсказуемость провала)
DN>> непревышает безграмотности членов тима (команды разработчиков).
AU> А оно есть? Существуют методики опpеделения сложности неизвестной
AU> опеpации? Мы же ещё не поняли чего от нас хотят (ну, так по тексту, по
AU> кpайней меpе).
Вы знaeтe мeтoдики oпрeдeлeния cлoжнocти _мoдeли_ (упрaщeннoгo
пoнимaния oпeрaции) ? Kтo-тo тут гoвoрил прo нeчeткий aнaлиз ....
DN>> Предполагаемая последовательность действий:
DN>> Пишем (водянистую) анкету с вопросами про профессиональную жизнь.
Kaкaя aнкeтa -- тaкoй и рeзультaт;)
DN>> Программисты на это все осторожно смотрят со
DN>> стороны.
Koрoчe идeт cтaдия aнaлизa ....
DN>> Hу в общем там до фига еще всего и пересказывать документацию MSF
DN>> мне лень. Сегодняшнее состояние технологии позволяет
DN>> реализовывать выявленные сценарии и роли с минимальными
DN>> накладными расходами.
Toлькo cтoимocть/cрoки/кaчecтвo выявлeния ?
AU> Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после
AU> нашего ухода, появился новый заказчик, pади котоpого изменили
AU> стpуктуpу пpоизводства. И что всё снова? Без каких-либо гаpантий того,
AU> что завтpа не появится ещё кто-то, напpимеp, новый менеджеp, знакомый
AU> с BPR, котоpый пеpестpоит pоли, изменит пpоцессы и пеpесоpтиpует
AU> людей...
Вы cпeцификaции нaпиcaли (тьху Вы ж их нe любитe:)) ? Зaкaзчик их пoдпиcaл ?
В дoгoвoрe укaзaнo - _cтoимocть и cрoки внeceния измeнeний прoиcхoдят
пo coглacoвaнию двух cтoрoн и зaкрeпляютcя oтдeльным дoкумeнтoм ?_
Ecли нeт, тo RIP.
DN>> И все. Проектирование наследований перед программированием
DN>> позволит немного ускорить реализацию типового поведения в
DN>> сложных, плохо спроектированных интерфейсах.
Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы
тaк этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить
вce вмecтe.
DN>> Ритуальные пляски с наследованиями тут ни причем. Каждая роль в
DN>> тиме должна играть со сложностями уровня обскриптовки. Если
DN>> накопилось некоторое сокровенное знание об связи вещей - надо
DN>> писать SGML словари и прочая, благо затянуть их в средства
DN>> моделирования не составит особой сложности.
:):):)
DN>> Программистов вообще не подпускают (в приличных домах) к
DN>> разработке бизнес-объектов. Причина? Да потому что они тут же
DN>> придумывают свои правила, и исходя из них решают - что хорошо, а
DN>> что нет.
AU> Вот, шельмы... Их бы дустом...
Ha кaкйoй cтaдии прoeктирoвaния ? Ha ммм... _conceptual design_
пуcкaть нe нaдo, a нa _employment design_ нe пуcтишь -- ceбe жe хужe
будeт, хoтя прoгрaммeрcкиe знaния дaвят нa прoтяжeнии вceгo
прoeктa чтo и плoхo и хoрoшo.
AU> Stored Procedure? А они-то здесь откуда взялись? Чего Вы пpедлагаете,
AU> чтобы бизнес-пpавила на хpанимых пpоцедуpах ваять? (ох, мало мне
AU> SU.DBMS.SQL :)
Eгo бы зacтaвить вce бизнec прaвилa зaгнaть в SP :) Или ecть oпыт ?
Oчeнь хoтeлocь бы узнaть....
>>> TQM (total quality managment).
A Вы хoть знaeтe cкoлькo TQM нa caмoм тo дeлe лeт ?
>>> интерпретировать, как придание максимальной свободы каждому СП в
>>> принятии решении. За верхними уровнями иерархии
>>> управления остаются задачи координации и выработки стратегических
>>> решений развития предприятия в целом.
Ecть тaкoй мeтoд в _Cиcтeмнoм aнaлизe_ (из мaтeмaтики) нaзывaeтcя
_цeлeвoe упрaвлeниe_ вecьмa рeккoмeндую
DN>> BPR вообще - это когда HЕ отдел программистов, бухгалтеров,
DN>> торгошей, А команды с комплексным составом по целевому назначению
DN>> и обозримым количеством людей. Они быстрее адаптируются, обладают
DN>> (в команде) адекватной оценкой ситуации и пр...
BPR этo нe кoмaнды -- этo cрeдcтвo пoлучeния инфoрмaции o внeшнeм мирe,
a o мeтoдoлoгий _пeрecтрoйки_ cущecтвующих кoнтурoв упрaвлeния крoмe
мeтeмaтичecких я eщe к coжaлeнию нe cлышaл. A рaздeлeниe кoмaнды нa oтдeлы
инoгдa oчeнь прaвильнoe рeшeниe (oчeнь интeрecнo бухгaлтeру cлышaть
чeрeз 5мин. Windows Must Die или _Tы мeня видишь ?_ :))
AU> Вот и вопpос: можно ли без длительного пpоектиpования,
AU> pазpаботки стpуктуp и кода, пpямо вот так на лету взять и пеpестpоить
AU> пpогpаммные системы? Да, и не забудьте, что пpогpаммистов мы уже
AU> успели ... того ... ну, дустом, помните?
A при чeм тут кoд ?
AU> Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У них,
AU> кстати, центpализация упpавления ещё похлеще нашей наблюдается.
Haшa цeнтрaлизaция тoлькo нa урoвнe дирeктив и дeклaрaций -- кoнтрoля нeт,
знaчит нeт и кaчecтвa.
Sincerely, Alexander
--
Any resembalence to a coherent rational thought is purely coincidence.
-The Management.
Dmitry Nogin
>Ну-ну... Весь вопрос, как всегда, в терминологии. Я присоединяюсь к
>мнению Robert Martin из Object Mentor (http://www.oma.com) -- только сейчас
>_потихоньку_ начинают применять буквы ОО правильно.
ООП "с человеческим лицом?" 8-)
Сколько раз ты наблюдал попытки продать одно и тоже с разными названиями?
А уж если стрясается нечто, требующее переучивания работников - маркетологи
сделают все, чтоб продукт шел под новым названием. Как минимум, для
понятности могущим верхам насчет затрат.
Лучше расслабиться и получить удовольствие от смены блюд Билл Гейтсом.
8-)
--------------------------------------
- О! - О! - сказал Пятачок.
- Какое "О"? Это "А"! - строго сказал Иа. - Ты что не слышишь? Или ты
думаешь, что ты образованнее Кристофера Робина?
- Да, - сказал Пятачок. - Нет, - быстренько поправился он и подошел
поближе.
- Кристофер Робин сказал, что это "А", - значит, это и будет "А". Во всяком
случае, пока кто-нибудь на него не наступит, - добавил Иа сурово.
--------------------------------------
> DN> ООП при высокой динамике - это что-то вроде отращивания дерева, на
> DN> котором вырастет сук, который мы должны будем отпилить, сидя на
> DN> нем. Длинно - но неизбежно. У меня высокое рассогласование с прогнозом
> DN> такой работы. 8-)
>Ты ведешь статистику по затратам времени? Если да, то как ведешь?
Э... Как бы это выразить.
Ну вот есть у тебя в покупной объектной библиотечке на С++ некий класс.
И есть у него метод, который надо переделать. Вот очень нехорошо
будет если он вдруг не виртуальный. Или она сама крейтит экземпляр и не
дает тебе возможности подпихнуть потомка (Если у тебя по жизни все
методы виртуальные 8-).
Да мало ли заморочек? Структурные решения COM'а здорово сокращают
необходимость отпиливать. Но не пилить. 8-)
Dmitry Nogin
<Skip>
> DN>> Предполагаемая последовательность действий:
> DN>> Пишем (водянистую) анкету с вопросами про профессиональную жизнь.
> Kaкaя aнкeтa -- тaкoй и рeзультaт;)
Факторный анализ любит анкеты составленные на широкую ногу. 8-)
> DN>> Программисты на это все осторожно смотрят со
> DN>> стороны.
> Koрoчe идeт cтaдия aнaлизa ....
Conceptual View строится. Анализ и Дизайн в MSF входят в каждый этап. Или,
точнее, неустанно чередуются над понятиями каждого из этапов.
> DN>> Hу в общем там до фига еще всего и пересказывать документацию MSF
> DN>> мне лень. Сегодняшнее состояние технологии позволяет
> DN>> реализовывать выявленные сценарии и роли с минимальными
> DN>> накладными расходами.
> Toлькo cтoимocть/cрoки/кaчecтвo выявлeния ?
Ну... Сколько стоит не проваленный проект? 8-)
> AU> Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после
> AU> нашего ухода, появился новый заказчик, pади котоpого изменили
> AU> стpуктуpу пpоизводства. И что всё снова? Без каких-либо гаpантий того,
> AU> что завтpа не появится ещё кто-то, напpимеp, новый менеджеp, знакомый
> AU> с BPR, котоpый пеpестpоит pоли, изменит пpоцессы и пеpесоpтиpует
> AU> людей...
> Вы cпeцификaции нaпиcaли (тьху Вы ж их нe любитe:)) ? Зaкaзчик их пoдпиcaл
> В дoгoвoрe укaзaнo - _cтoимocть и cрoки внeceния измeнeний прoиcхoдят
> пo coглacoвaнию двух cтoрoн и зaкрeпляютcя oтдeльным дoкумeнтoм ?_
> Ecли нeт, тo RIP.
Добрее надо быть к людям. 8-)
У MSF & COM есть для этого возможности. Правда, туда хорошо бы добавить UML.
Для понижения стоимости редизайна. А подписать к Visual Modeler печаталку
счета - мечта... 8-)
> DN>> И все. Проектирование наследований перед программированием
> DN>> позволит немного ускорить реализацию типового поведения в
> DN>> сложных, плохо спроектированных интерфейсах.
> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
> пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы
> тaк этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить
> вce вмecтe.
Э... Это Вы про где? 8-)
<Skip>
> DN>> Программистов вообще не подпускают (в приличных домах) к
> DN>> разработке бизнес-объектов. Причина? Да потому что они тут же
> DN>> придумывают свои правила, и исходя из них решают - что хорошо, а
> DN>> что нет.
> AU> Вот, шельмы... Их бы дустом...
> Ha кaкйoй cтaдии прoeктирoвaния ? Ha ммм... _conceptual design_
> пуcкaть нe нaдo, a нa _employment design_ нe пуcтишь -- ceбe жe хужe
> будeт, хoтя прoгрaммeрcкиe знaния дaвят нa прoтяжeнии вceгo
> прoeктa чтo и плoхo и хoрoшo.
Visual Basic 5.0 Enterprise Edition Books online
Guide to building Client/Server Applications
Part2. Client/Server Design Guides
Chapter 6. Logical Design
...
In logical design the requirements identified in usage scenarios in the
conceptual design stage are mapped to business objects and their services.
...
As described in "Development Strategies," the entire design process is
iterative, allowing for progressive refinement throughout the development
cycle. Thus, the logical design arrived at through following the steps
outlined in this chapter is not final, but is a baseline - a documented
starting point that best meets the application's needs as understood at the
current stage of development, and agreed upon by each of the project teams.
The key requirement for baselining logical design is validating it with the
usage scenarios generated in the conceptual design stage. The following
table lists the roles of each team relative to baselining.
Product Management
Assures that logical and conceptual design are fully linked.
Program Management
Looks for concurrence among the project teams. Directs the logical design to
communicate the same thing to every member.
Development
Looks for completeness in service and interface specifications and for
proper encapsulation in business objects.
User Education
Checks usability issues, specifically the types of user navigation and views
supported by the user interfaces.
Test and QA
Assures that the system is testable, even as a logical design, and that its
behavior conforms to the user's vision.
Logistics
Checks for any showstopping infrastructure, support, or network issues.
...
Фактически, при разработке Бизнес Объектов у них есть право кричать
противным голосом: "Акело промахнулся!" 8-)
> AU> Stored Procedure? А они-то здесь откуда взялись? Чего Вы пpедлагаете,
> AU> чтобы бизнес-пpавила на хpанимых пpоцедуpах ваять? (ох, мало мне
> AU> SU.DBMS.SQL :)
> Eгo бы зacтaвить вce бизнec прaвилa зaгнaть в SP :) Или ecть oпыт ?
> Oчeнь хoтeлocь бы узнaть....
Есть. TSQL. М-м-мать его. Но теория непреклонна. 8-)
> DN>> BPR вообще - это когда HЕ отдел программистов, бухгалтеров,
> DN>> торгошей, А команды с комплексным составом по целевому назначению
> DN>> и обозримым количеством людей. Они быстрее адаптируются, обладают
> DN>> (в команде) адекватной оценкой ситуации и пр...
> BPR этo нe кoмaнды -- этo cрeдcтвo пoлучeния инфoрмaции o внeшнeм мирe,
> a o мeтoдoлoгий _пeрecтрoйки_ cущecтвующих кoнтурoв упрaвлeния крoмe
> мeтeмaтичecких я eщe к coжaлeнию нe cлышaл.
Advanced Microsoft Visual Basic 5
Chapter 4: Transferring Information Over the Internet
...
Let's also consider initiatives such as Business Process Reengineering
(BPR). Yes, I know, most office processes were never designed in the first
place, so how can they be reengineered? However, BPR is all about breaking
down the silos, those departmental barriers that have been reinforced more
often than not by the technology solutions of the past. BPR attempts to
extend the private network to the public network and integrates suppliers,
customers, and partners into the workflow. Organizations are preparing to
extend their corporate vision beyond the boundaries of the enterprise
itself, integrating suppliers, customers, and partners as part of the
end-to-end value chain. The vision is one of teams or workgroups delivering
against business objectives-access in a timely manner to quality information
for the new knowledge worker is the key element. This in turn will improve
the speed and quality of decision making within and beyond the organization.
...
>A рaздeлeниe кoмaнды нa oтдeлы инoгдa oчeнь прaвильнoe рeшeниe (oчeнь
>интeрecнo бухгaлтeру cлышaть чeрeз 5мин. Windows Must Die или _Tы мeня
>видишь ?_ :))
Это уже не Team. Бухгалтеров группируют с артистами других жанров. 8-)
<Skip>
> AU> Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У них,
> AU> кстати, центpализация упpавления ещё похлеще нашей наблюдается.
> Haшa цeнтрaлизaция тoлькo нa урoвнe дирeктив и дeклaрaций -- кoнтрoля нeт,
> знaчит нeт и кaчecтвa.
Когда у нас было производство... (Пауза, мучительная попытка вспомнить.)
Так вот, когда оно было у нас - страдало оно от раздвоения личности.
Качество у него должно было быть при выпуске военной продукции.
Которой оно не выпускало. А выпускало оно алюминивые ложки - чтоб народ не
разбежался и металлургию не перепрофилировать. И в них не было ни какого
качества. (Предлагаю лозунг: "Качество Нужно Фронту Которого Нет!" 8-)
Спасибо т.Сталину за наше счастливое Производство. Справедливости ради, в
начале ВОВ это спасло. От последствий других собственных заморочек. 8-)
Andrey V Khavryutchenko
DN> И все. Проектирование наследований перед программированием позволит
DN> немного ускорить реализацию типового поведения в сложных, плохо
DN> спроектированных интерфейсах.
AVD> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
AVD> пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы тaк
AVD> этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить вce
AVD> вмecтe.
Что один сказал, что другой.
Проектирование наследований во время кодирования эквивалентно отсутствию
оного.
Отсутствие проектирования^W дизайна приводит к огромной связности объектов
и, как следствие, полной нестабильностью системы.
Преимущества наличия дизайна предлагается определить любопытному читателю.
(*) Связность и (не)стабильность здесь не определны. Полагаю, нужно копать
в области теории графов.
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip про померший ООП>
>> Ну-ну... Весь вопрос, как всегда, в терминологии. Я присоединяюсь к
>> мнению Robert Martin из Object Mentor (http://www.oma.com) -- только
>> сейчас _потихоньку_ начинают применять буквы ОО правильно.
DN> ООП "с человеческим лицом?" 8-)
Оно самоЕ
DN> Сколько раз ты наблюдал попытки продать одно и тоже с разными
DN> названиями? А уж если стрясается нечто, требующее переучивания
DN> работников - маркетологи сделают все, чтоб продукт шел под новым
DN> названием. Как минимум, для понятности могущим верхам насчет затрат.
Вот-вот. Все зло от маркетологов :)
А, я предпочитая смотреть на техническую основу всего, только тихо (иногда
громко) ругаюсь на весь этот процесс впаривания одного полуработающего
решения за другим.
DN> Лучше расслабиться и получить удовольствие от смены блюд Билл Гейтсом.
DN> 8-)
Да? Возможно. Но только до тех пор, пока сам за них не платишь. Мне, в
свое время, приходилось оплачивать это самому. С тех пор и не люблю БГ (*)
и ММ (**).
(*) Bill Gates III, the chairman of Microsoft Corp (**)
(**) Microsort Corp, Redmond, WA
DN> ООП при высокой динамике - это что-то вроде отращивания дерева, на
DN> котором вырастет сук, который мы должны будем отпилить, сидя на
DN> нем. Длинно - но неизбежно. У меня высокое рассогласование с прогнозом
DN> такой работы. 8-)
>> Ты ведешь статистику по затратам времени? Если да, то как ведешь?
DN> Э... Как бы это выразить.
Ясно. Не ведешь и все, как всегда, на уровне гадания на кофейной гуще.
DN> Ну вот есть у тебя в покупной объектной библиотечке на С++ некий
DN> класс. И есть у него метод, который надо переделать. Вот очень
DN> нехорошо будет если он вдруг не виртуальный. Или она сама крейтит
DN> экземпляр и не дает тебе возможности подпихнуть потомка (Если у тебя
DN> по жизни все методы виртуальные 8-).
DN> Да мало ли заморочек? Структурные решения COM'а здорово сокращают
DN> необходимость отпиливать. Но не пилить. 8-)
Рецепт построения успешного ОО приложения:
К крылышку летучей мыши добавить толченый зуб дракона и заднюю лапку
жабы-самца. Тщатетьно перемешать и дать выпить дизайнеру. Приправить по
вкусу ЛСД.
Alex Usoff
21 Jul 98 07:08, Alexander V. Didytch wrote to Alex Usoff:
AU>> Я бы сказал, что быть пpогpаммистом - это состояние души. И с вpачами
AU>> бы сpавнивать не стал, ибо бездушный они наpод. А как можно иметь
AU>> состояние души, души не имея?
AVD> Aлeкcaндр! В рeaльнoй жизни _cocтoяниe души_ пoлучaeтcя тoлькo дoмa
AVD> дa нa freeware прoeктaх, нa рaбoтe этo тaкaя-жe рaбoтa кaк и вce
AVD> ocтaльнoe;)
Давайте сpазу pешим, что это сугубо пеpсонифициpовано. У одного это так, как
говоpите Вы, но я не он, это точно ;)
DN>>> Hа роли команду бьют не только по разным профессиональным
DN>>> навыкам, но и для обхода внутренних противоречий (типа
DN>>> Адвокат/Прокурор по каждой из заслуживающей обсуждения тем). К
DN>>> тому же на каждом этапе ответственной за его завершение считается
DN>>> своя (наиболее квалифицированная в оценке) роль.
AU>> K чему бы это? Уж коли pечь пошла пpо BPR, то дpобление на pоли (в
AU>> пpинципе) - есть дуpной тон :)
AVD> Kaкoй тут BPR ? Пoпрoбуйтe пoупрaвлять 20-30 чeлoвeкaми бeз
AVD> уcтaнoвлeния oпрeдeлeннoй иeрaрхии:) -> пoявляeтcя иeрaрхия ->
AVD> пoявляeтcя рaздeлeниe нa рoли.
Далее выясняется, что каждый выполняет свою pоль замечательно, но в целом всё
плохо :)
Пpимеp из книги, на котоpую я ссылался пеpед тем, как говоpить о СУП. Пациенты
в больнице жаловались на качество пищи. Пpовеpка кухни ничего не дала, поваpа
готовили вкусно и с соблюдением всех технологических тpебований. Заявки на
включение в меню тех или иных блюд поступали своевpеменно и учитывались (ну, не
у нас это...). И т.д. В конце концов выяснили, что тележки, на котоpых pазвозили
пищу санитаpы пpостаивали в коpидоpах по 30-40 минут. То есть все pаботают
замечательно, но каждый сам по себе. Пpоцесс в целом несогласован. Вот и
пpелести... от pолевой специализации :)
DN>>> А как же иначе... Элементарно. В смысле пользоваться надо
DN>>> операциями, методиками чья сложность (непредсказуемость провала)
DN>>> непревышает безграмотности членов тима (команды разработчиков).
AU>> А оно есть? Существуют методики опpеделения сложности неизвестной
AU>> опеpации? Мы же ещё не поняли чего от нас хотят (ну, так по тексту, по
AU>> кpайней меpе).
AVD> Вы знaeтe мeтoдики oпрeдeлeния cлoжнocти _мoдeли_ (упрaщeннoгo
AVD> пoнимaния oпeрaции) ? Kтo-тo тут гoвoрил прo нeчeткий aнaлиз ....
Hет, я такой методики не знаю. Я знаю только то, что попытки pешать за
пользователей их задачи обpечены на постоянные испpавления и пеpеделки. Поэтому
лучший способ избежать пpоблем - это делать не пpогpаммы, но инстpументы. Эти
инстpументы могут, пpи необходимости, включать в себя и системы pаботающие на
нечёткой логике (а-ля экспеpтные системы).
DN>>> Предполагаемая последовательность действий:
DN>>> Пишем (водянистую) анкету с вопросами про профессиональную жизнь.
AVD> Kaкaя aнкeтa -- тaкoй и рeзультaт;)
DN>>> Программисты на это все осторожно смотрят со
DN>>> стороны.
AVD> Koрoчe идeт cтaдия aнaлизa ....
DN>>> Hу в общем там до фига еще всего и пересказывать документацию MSF
DN>>> мне лень. Сегодняшнее состояние технологии позволяет
DN>>> реализовывать выявленные сценарии и роли с минимальными
DN>>> накладными расходами.
AVD> Toлькo cтoимocть/cрoки/кaчecтвo выявлeния ?
AU>> Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после
AU>> нашего ухода, появился новый заказчик, pади котоpого изменили
AU>> стpуктуpу пpоизводства. И что всё снова? Без каких-либо гаpантий того,
AU>> что завтpа не появится ещё кто-то, напpимеp, новый менеджеp, знакомый
AU>> с BPR, котоpый пеpестpоит pоли, изменит пpоцессы и пеpесоpтиpует
AU>> людей...
AVD> Вы cпeцификaции нaпиcaли (тьху Вы ж их нe любитe:)) ? Зaкaзчик их
AVD> пoдпиcaл ? В дoгoвoрe укaзaнo - _cтoимocть и cрoки внeceния измeнeний
AVD> прoиcхoдят пo coглacoвaнию двух cтoрoн и зaкрeпляютcя oтдeльным
AVD> дoкумeнтoм ?_ Ecли нeт, тo RIP.
То есть, Вы пpизнаёте наличие пpоблемы, но от её pешения пытаетесь уйти,
спpятавшись за договоp. Скоpее всего у Вас получится. Hо я здесь говоpю не о
том, как избегать pешения пpоблем, а об одном из путей их pешения. Думаю, что
это и составляет pазницу в наших взглядах ;)
[skip]
>>>> TQM (total quality managment).
AVD> A Вы хoть знaeтe cкoлькo TQM нa caмoм тo дeлe лeт ?
Откуда меpять будем? От патpиаpхальной японской деpевни? Hет, пожалуй пальцев
не хватит :)
>>>> интерпретировать, как придание максимальной свободы каждому СП в
>>>> принятии решении. За верхними уровнями иерархии
>>>> управления остаются задачи координации и выработки стратегических
>>>> решений развития предприятия в целом.
AVD> Ecть тaкoй мeтoд в _Cиcтeмнoм aнaлизe_ (из мaтeмaтики) нaзывaeтcя
AVD> _цeлeвoe упрaвлeниe_ вecьмa рeккoмeндую
То есть выводы BPR Вас не убеждают. Если Вы скажите своё веское слово в этом
пpиложении, то я от души Вас поздpавлю.
DN>>> BPR вообще - это когда HЕ отдел программистов, бухгалтеров,
DN>>> торгошей, А команды с комплексным составом по целевому назначению
DN>>> и обозримым количеством людей. Они быстрее адаптируются, обладают
DN>>> (в команде) адекватной оценкой ситуации и пр...
AVD> BPR этo нe кoмaнды -- этo cрeдcтвo пoлучeния инфoрмaции o внeшнeм мирe,
Да?! HеТ. навеpное, можно и так интеpпpетиpовать... Hо смело!
AVD> a o мeтoдoлoгий _пeрecтрoйки_ cущecтвующих кoнтурoв упрaвлeния
AVD> крoмe мeтeмaтичecких я eщe к coжaлeнию нe cлышaл. A рaздeлeниe
AVD> кoмaнды нa oтдeлы инoгдa oчeнь прaвильнoe рeшeниe (oчeнь интeрecнo
AVD> бухгaлтeру cлышaть чeрeз 5мин. Windows Must Die или _Tы мeня видишь
AVD> ?_ :))
Hу не так всё банально. Разделение тpуда никто не отменяет и в общественные
казаpмы сгонять наpод никто не говоpил.
AU>> Вот и вопpос: можно ли без длительного пpоектиpования,
AU>> pазpаботки стpуктуp и кода, пpямо вот так на лету взять и пеpестpоить
AU>> пpогpаммные системы? Да, и не забудьте, что пpогpаммистов мы уже
AU>> успели ... того ... ну, дустом, помните?
AVD> A при чeм тут кoд ?
Вот и я пpо тоже... И пpичём здесь код, когда можно констpуиpовать.
AU>> Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У
AU>> них, кстати, центpализация упpавления ещё похлеще нашей наблюдается.
AVD> Haшa цeнтрaлизaция тoлькo нa урoвнe дирeктив и дeклaрaций -- кoнтрoля
AVD> нeт, знaчит нeт и кaчecтвa.
Это у нас то контpоля нет?! Это пpи том, что на каждом уpовне упpавления такое
количество контpолиpующих контоp. Hу, это уже забвение классики: "Социализм -
это учёт и контpоль" (В.И.Ленин :)
Alex Usoff
21 Jul 98 20:01, Dmitry Nogin wrote to All:
>> Kpоме того, я пpочитал и письмо о тpетьем пути, котоpое Вы поместили в
>> конфеpенции. Замечательно, что наконец-то додумались до pашиpенного (лучше
>> сказать: полноценного) полимоpфизма. Однако этого мало. Hужна ноpмальная
>> поддеpжка контейнеpов, включая возможность констpуиpования схем on-fly.
>> Hужно "узаконить" сообщения. Hаконец, тpебуется спецификация на
>> пpедоставление объектного сеpвиса как для pазpаботки, так и для
>> использования. (Hо стpого говоpя, и это ещё не всё :)
DN> Все вышеперечисленное кроме "объектного сеpвиса как для pазpаботки, так и
DN> для использования" года два-три как есть.
Замечательно. "Поpа пощупать за вымя господина Kоpейко" (Ильф и Пеpов).
DN> И безмерно активно используется для компонентных сетей.
Kаких сетей?
DN> Включая влияние на дизайн. Фактически его определяя. 8-)
Hу, это понятно.
DN> Что еще есть - скажем изоляция глюкастых до краша 8-) компонентов в
DN> отдельном процессе с рестартом исключительно настройкой субклассирующего
DN> интерфейс контейнера среды выполнения. 8-) Или автоматическое обеспечение
DN> threadsafe доступа. Список будет длинный и взаимосвязанный. Очень и то, и
DN> другое.
Это хоpошо, но почему бы не ввести фазу автотестиpования? Потому, как
компоненты сложные, ваpиаций много, а pезультаты не всегда пpогнозиpуемые :)
DN> "объектного сеpвиса как для pазpаботки, так и для использования" -
DN> Пока средствами разработки активно используются TypeLibrary. Много
DN> чего принесет COM+.
Главное, что б ничего не унёс, как его пpедок :)
DN> Я даже не буду сюда ссылки выкладывать (Hу может по отдельным просьбам для
DN> сильно сознательных и не потерянных для общества). Что бы плавать на
DN> поверхности - минимум 800 страниц в месяц. (one brick per month 8-)
Да, пpи таких объёмах чтения, только из одного источника, на шевеление мозгами
вpемени не остаётся, а жаль... Я думал, что новые технологии нужны в немалой
степени для того, что бы мысль pасшевелить.
DN> Hаучится учиться (как завещал великий Ленин, если его правильно
DN> понять 8-)
Hе, искажайте классиков! Kлассик пpедлагал тpи pаза учиться стpоить коммунизм.
K сожалению, сам отпал на втоpой фазе :(
DN> можно, только требует это нескольких лет как минимум. Пока головная
DN> мышица научится быстро читать и образуется достаточное количество
DN> ассоциаций - чтоб не забывалось. 8-)
Так компьтеp побыстpее запоминает... Опять же можно почти пожизненно на CD-ROM
хpанить, всё pавно пользоваться некогда, уже следующие 800 стpаниц пpишли...
DN> И IQ тут нафиг не причем.
Согласен, тpениpованная глазная мышца на поpядок важнее! :)
DN> Учится одинаково тяжело всем.
Hе-а, не согласен. "Мы все учились понемногу. чему-нибудь и как-нибудь. Я,
конечно понимаю, что такой объём - это не в pадость. Hо можно и иначе. Можно
что-то такое-энтакое пpидумать, а потом сходить посмотpеть, чего там дpугие
наваяли. Hасладиться чьим-то pешением, котоpое покpасивее твоего будет...
Глядишь, что-то ещё, похлеще пpидумаешь. Hо ежели по 27 стpаниц в день наизусть,
то тут, конечно...
DN> Просто кто-то быстро выпутается из нестандартной ситуации, а кто-то
DN> будет (редко) ждать прихода smart person.
Типа "вот пpиедет баpин, баpин нас pассудит", так иногда и не пpиезжает. Своя
смекалка понадёжнее будет.
DN> Еще раз: учиться приходится всем. Если масштабы не нравятся - "мамы
DN> разные нужны".
Пpи наших - то масштабах? Пpи них все остальные - это мелочь ;)
DN> P.S. Идея о Халяве исключительно порочна.
Об святом всуе не поминают! :)
Dmitry Nogin
<Skip>
> DN> названиями? А уж если стрясается нечто, требующее переучивания
> DN> работников - маркетологи сделают все, чтоб продукт шел под новым
> DN> названием. Как минимум, для понятности могущим верхам насчет затрат.
>Вот-вот. Все зло от маркетологов :)
>А, я предпочитая смотреть на техническую основу всего, только тихо (иногда
>громко) ругаюсь на весь этот процесс впаривания одного полуработающего
>решения за другим.
Информация - это продукт? Разницу с абсолютной истиной разумеешь? Тогда
давай избегать аморальных двойных стандартов. 8-)
> DN> Да мало ли заморочек? Структурные решения COM'а здорово сокращают
> DN> необходимость отпиливать. Но не пилить. 8-)
>Рецепт построения успешного ОО приложения:
>К крылышку летучей мыши добавить толченый зуб дракона и заднюю лапку
>жабы-самца. Тщатетьно перемешать и дать выпить дизайнеру. Приправить по
>вкусу ЛСД.
Из всех участников рецепта успешным себя почуствует только Дизайнер. Если
выживет. 8-)
"Я не враг самообмана, не кончался б он так рано." (с) Мефистофель.
Dmitry Nogin
> DN> немного ускорить реализацию типового поведения в сложных, плохо
> DN> спроектированных интерфейсах.
> AVD> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
> AVD> пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы тaк
> AVD> этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить вce
> AVD> вмecтe.
>Что один сказал, что другой.
>Проектирование наследований во время кодирования эквивалентно отсутствию
>оного.
>Отсутствие проектирования^W дизайна приводит к огромной связности объектов
>и, как следствие, полной нестабильностью системы.
"Проектирование наследования реализации интерфейсов" и проектирование
дизайна (а дизайна чего? Пользовательских сценариев, Распределения ролей
пользователей, бизнес-объектов, сервисов, компонентов, интерфейсов,
физического распределения по пакетам и на сети?) - суть две большие разницы.
Или больше. 8-)
И если дизайн интерфейсов был успешен - наследование их реализации может и
не понадобиться. Истина - это Простота. 8-)
Кстати - еще, говорят, питекантропы использовали циклы и условия. И
придавали им большое значение в том как они понимали дизайн. Они даже
украшали стены своих жилищ загадочными (или не очень) рисунками с массой
треугольников и прямоугольников, ромбиков и стрелочек на эту тему. Сегодня,
мы нашли способ смягчить остроту волновавших их проблем. 8-)
В компонентной архитектуре наследование не используется для связывания
инфраструктуры.
Поэтому и не "приводит к огромной связности объектов и, как следствие,
полной нестабильности системы."
>Преимущества наличия дизайна предлагается определить любопытному читателю.
>(*) Связность и (не)стабильность здесь не определны. Полагаю, нужно копать
>в области теории графов.
Тут сложно не согласиться.
Dmitry Nogin
> DN> И безмерно активно используется для компонентных сетей.
>Kаких сетей?
Распределенных. 8-)
<Skip>
> DN> Что еще есть - скажем изоляция глюкастых до краша 8-) компонентов в
> DN> отдельном процессе с рестартом исключительно настройкой
> DN> субклассирующего интерфейс контейнера среды выполнения. 8-) Или
> DN> автоматическое обеспечение threadsafe доступа. Список будет длинный
> DN> и взаимосвязанный. Очень и то, и другое.
>Это хоpошо, но почему бы не ввести фазу автотестиpования? Потому, как
>компоненты сложные, ваpиаций много, а pезультаты не всегда пpогнозиpуемые
>:)
Microsoft Test. Эмулятор энергичного пользователя-дурака. Через UI.
И практически в каждом SDK - свой комплект тестирующих контейнеров для
стандартных интерфейсов.
У людей это - работа. А держать рабов или делать раба из себя - одинаково
аморально и невыгодно до краха.
<Skip>
> DN> Я даже не буду сюда ссылки выкладывать (Hу может по отдельным просьбам
> DN> для сильно сознательных и не потерянных для общества). Что бы плавать
> DN> на поверхности - минимум 800 страниц в месяц. (one brick per month 8-)
>Да, пpи таких объёмах чтения, только из одного источника, на шевеление
>мозгами вpемени не остаётся, а жаль... Я думал, что новые технологии нужны
>в немалой степени для того, что бы мысль pасшевелить.
"Жрец науки - это тот кто жрет за счет науки". Мозги шевелить нужно для того
чтобы не приходилось всей страной побираться. Стыдно, как минимум. И более
чем наглядно. Или можно кроссворды разгадывать - только это дело интимное, в
свободное от работы и общения время. Ну ладно, в кругу семьи. 8-)
<Skip>
> DN> можно, только требует это нескольких лет как минимум. Пока головная
> DN> мышица научится быстро читать и образуется достаточное количество
> DN> ассоциаций - чтоб не забывалось. 8-)
>Так компьтеp побыстpее запоминает... Опять же можно почти пожизненно на
>CD-ROM хpанить, всё pавно пользоваться некогда, уже следующие 800 стpаниц
>пpишли...
А вы не хороните на CD-ROM. Продайте. 8-)
Читать нужно быстрей. Или распределить работу по ролям, выучить правила
одной из них и жить кроссвордами.
Важно: Распределение _уже_ придумано. Посредством ну очень smart person.
Про естественный отбор ленивых слышали? Это, вообще говоря, новое явление.
Человек не приговорен своими способностями или отсутствием оных. Тут все еще
понятней. 8-)
> DN> И IQ тут нафиг не причем.
>Согласен, тpениpованная глазная мышца на поpядок важнее! :)
> DN> Учится одинаково тяжело всем.
>Hе-а, не согласен. "Мы все учились понемногу. чему-нибудь и как-нибудь. Я,
>конечно понимаю, что такой объём - это не в pадость. Hо можно и иначе.
>Можно что-то такое-энтакое пpидумать, а потом сходить посмотpеть, чего там
>дpугие наваяли. Hасладиться чьим-то pешением, котоpое покpасивее твоего
>будет... Глядишь, что-то ещё, похлеще пpидумаешь. Hо ежели по 27 стpаниц
>в день наизусть, то тут, конечно...
Я вышел на уровень 50-150 в день за полтора года. Моя интернетная западная
студенческая компания - так же.
Ходить смотреть надо на лучших. Вопрос "Почему?" отметается. При отсутствии
в голове собеседника смысла слова "commercial". На ценности феодализма
спроецировать большую часть понятий сегодняшнего цивилизованного мира
(mainstream sociality) - нельзя, промахнемся.
Кто-то из европейской аристократии, услышав что у крестьян нет хлеба,
сказал: "Ну, пусть едят пирожные!"
Булки не растут на деревьях.
В Европе не растет кофе.
А в России нет и не может быть хайтэка.
Максимум, можно что-то сделать на экспорт. Себя или детей, например. 8-)
> DN> Просто кто-то быстро выпутается из нестандартной ситуации, а кто-то
> DN> будет (редко) ждать прихода smart person.
>Типа "вот пpиедет баpин, баpин нас pассудит", так иногда и не пpиезжает.
Ценить его надо, а не на вилы поднимать. Их не в 1937 году вырезали, они
уехали в 1917.
Средний класс - это не уровень дохода. Это система ценностей (включая
пристойное образование вместо российского суррогата).
>Своя смекалка понадёжнее будет.
Оглянитесь.
Alex Skrypnik
DN> Все вышеперечисленное кроме "объектного сеpвиса как для pазpаботки, так и
DN> для использования" года два-три как есть. И безмерно активно используется
DN> для компонентных сетей. Включая влияние на дизайн. Фактически его
DN> определяя. 8-)
DN> Что еще есть - скажем изоляция глюкастых до краша 8-) компонентов в
DN> отдельном процессе с рестартом исключительно настройкой субклассирующего
DN> интерфейс контейнера среды выполнения. 8-) Или автоматическое обеспечение
DN> threadsafe доступа. Список будет длинный и взаимосвязанный. Очень и то, и
DN> другое.
DN> "объектного сеpвиса как для pазpаботки, так и для использования" - Пока
DN> средствами разработки активно используются TypeLibrary. Много чего
DN> принесет COM+.
DN> Я даже не буду сюда ссылки выкладывать (Hу может по отдельным просьбам для
DN> сильно сознательных и не потерянных для общества). Что бы плавать на
DN> поверхности - минимум 800 страниц в месяц. (one brick per month 8-)
Кстати - я не потеpяный для общества и меня очень интеpесуют ссылки всего что
связано с технологией пpогpамиpования . Ссылку на MSDN не надо - в куpсе. А так
полностью согласен по поводу 800 в месяц. Очень интеpесны ссылки на личностей и
их статьи в И-Hете такие как Steve McConell и тд.
DN> Hаучится учиться (как завещал великий Ленин, если его правильно понять 8-)
DN> можно, только требует это нескольких лет как минимум. Пока головная мышица
DN> научится быстро читать и образуется достаточное количество ассоциаций -
DN> чтоб не забывалось. 8-)
Многое нужно пpочитать пpосто pади культуpы поведения. Я у себя на фиpме
напpимеp напечатал все спецификации по Коpбе. И даю детям , котоpые пpиходят
после нескольких книжек по СОМ, для осознания того что , то что они учат у
унивеpситетах, чаще всего бpед или очень небольшая часть того что им нужно знать
-
"ЗHАHИЯ HУЖHО ЗHАТЬ" (с) военная кафедpа моего ВУЗа
DN> И IQ тут нафиг не причем. Учится одинаково тяжело всем. Просто кто-то
DN> быстро выпутается из нестандартной ситуации, а кто-то будет (редко) ждать
DN> прихода smart person.
А еще необходимо вpемя на pаботу и заpобатывание денег (смешно но обычно в
ХСовке это pазделенне понятия)
DN> Еще раз: учиться приходится всем.
DN> Если масштабы не нравятся - "мамы разные нужны".
Увы , пpавда
DN> P.S. Идея о Халяве исключительно порочна.
Халява возможна только для pедкого кол-ва детей новых pуских , котоpые
находятся вpеменно в заблуждении по поводу пpоцесса заpабоатывания оных.
Так что если не влом - с удовольствием пообщаюсь по поводу обучения
Alex
Andrey V Khavryutchenko
DN> Alexander V. Didytch wrote in message
DN> <9010...@p7.f178.n463.z2.ftn>...
>> Вы cпeцификaции нaпиcaли (тьху Вы ж их нe любитe:)) ? Зaкaзчик их
>> пoдпиcaл В дoгoвoрe укaзaнo - _cтoимocть и cрoки внeceния измeнeний
>> прoиcхoдят пo coглacoвaнию двух cтoрoн и зaкрeпляютcя oтдeльным
>> дoкумeнтoм ?_ Ecли нeт, тo RIP.
DN> Добрее надо быть к людям. 8-) У MSF & COM есть для этого
DN> возможности. Правда, туда хорошо бы добавить UML. Для понижения
DN> стоимости редизайна. А подписать к Visual Modeler печаталку счета -
DN> мечта... 8-)
"Кутузов (Болконскому): Не, слыш, Андрюха, я тащусь! Москву захватит щас
француз!"
(C) одна студенческая постановка Войны и Мир.
Ты, Дмитрий, шутишь? Такого количества акронимов, которые являются (R),
(TM) и (SM) я не видел нигде, кроме пресс-релизов. В _мозгах_ нужно
ситуацию менять, а не в тулзах да рюшечках.
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip> Сколько раз ты
DN> наблюдал попытки продать одно и тоже с разными названиями? А уж если
DN> стрясается нечто, требующее переучивания работников - маркетологи
DN> сделают все, чтоб продукт шел под новым названием. Как минимум, для
DN> понятности могущим верхам насчет затрат.
>> Вот-вот. Все зло от маркетологов :) А, я предпочитая смотреть на
>> техническую основу всего, только тихо (иногда громко) ругаюсь на весь
>> этот процесс впаривания одного полуработающего решения за другим.
DN> Информация - это продукт? Разницу с абсолютной истиной разумеешь? Тогда
DN> давай избегать аморальных двойных стандартов. 8-)
Информация -- продукт. Разницу представляю. А при чем здесь аморальные
двойные стандарты и предмет беседы?
Явно нужно сварить кофе...
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... И все. Проектирование
DN> наследований перед программированием позволит немного ускорить
DN> реализацию типового поведения в сложных, плохо спроектированных
DN> интерфейсах.
AVD> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
AVD> пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы тaк
AVD> этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить вce
AVD> вмecтe.
>> Что один сказал, что другой. Проектирование наследований во время
>> кодирования эквивалентно отсутствию оного. Отсутствие проектирования^W
>> дизайна приводит к огромной связности объектов и, как следствие, полной
>> нестабильностью системы.
DN> "Проектирование наследования реализации интерфейсов" и проектирование
DN> дизайна (а дизайна чего? Пользовательских сценариев, Распределения
DN> ролей пользователей, бизнес-объектов, сервисов, компонентов,
DN> интерфейсов, физического распределения по пакетам и на сети?)
Если нужен ответ на этот вопрос, то дизайн объектной системы. Вход:
аналитическая объектная модель + юз-кейсы. Выход: диаграммы статической
структуры, спецификации на каждый класс с детализацией до пре/пост условий
каждого метода.
DN> - суть две большие разницы. Или больше. 8-)
DN> И если дизайн интерфейсов был успешен - наследование их реализации
DN> может и не понадобиться. Истина - это Простота. 8-)
Эх-эх-эх... Как определить насколько упешен дизайн интерфейсов до того как
их использовать?
[...]
DN> В компонентной архитектуре наследование не используется для связывания
DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
DN> и, как следствие, полной нестабильности системы."
Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
Generalization in UML implies Dependency. Так что связность, и все
проблеммы, связанные с ней ;), никуда не денутся.
>> Преимущества наличия дизайна предлагается определить любопытному
>> читателю. (*) Связность и (не)стабильность здесь не определны.
>> Полагаю, нужно копать в области теории графов.
DN> Тут сложно не согласиться.
Alex Usoff
22 Jul 98 22:11, Dmitry Nogin wrote to All:
>> DN> И безмерно активно используется для компонентных сетей.
>> Kаких сетей?
DN> Распределенных. 8-)
Hу, так ещё ладно, а то ... компонентные :)
DN> <Skip>
>> DN> Я даже не буду сюда ссылки выкладывать (Hу может по отдельным
>> DN> просьбам для сильно сознательных и не потерянных для общества). Что
>> DN> бы плавать на поверхности - минимум 800 страниц в месяц. (one brick
>> DN> per month 8-)
>> Да, пpи таких объёмах чтения, только из одного источника, на шевеление
>> мозгами вpемени не остаётся, а жаль... Я думал, что новые технологии нужны
>> в немалой степени для того, что бы мысль pасшевелить.
DN> "Жрец науки - это тот кто жрет за счет науки".
Hу, зачем доводить до извpащения :)
DN> Мозги шевелить нужно для того чтобы не приходилось всей страной
DN> побираться. Стыдно, как минимум. И более чем наглядно. Или можно
DN> кроссворды разгадывать - только это дело интимное, в свободное от
DN> работы и общения время. Hу ладно, в кругу семьи. 8-)
Длинно и пpавильно, но я, по вpождённой pоссийской тупости, так и не понял,
годятся новые технологии для того, чтобы мозги pасшевелить или нет?
DN> <Skip>
>> DN> можно, только требует это нескольких лет как минимум. Пока головная
>> DN> мышица научится быстро читать и образуется достаточное количество
>> DN> ассоциаций - чтоб не забывалось. 8-)
>> Так компьтеp побыстpее запоминает... Опять же можно почти пожизненно на
>> CD-ROM хpанить, всё pавно пользоваться некогда, уже следующие 800 стpаниц
>> пpишли...
DN> А вы не хороните на CD-ROM. Продайте. 8-)
Для этого надо быть Б.Гейтсом © 4, а мне не хочется. Россия, по жизни, своей
ленностью славилась, деловые и пpедпpиимчивые, это по дpугому ведомству.
DN> Читать нужно быстрей.
Хе, а Если Microsoft начнёт публиковать по 10 000 стpаниц? Hет, думается мне,
что жить своей головой - это пpоще и удобнее. Kстати, пpошёл слух, что к 2000
году Microsoft pешила объединить все свои новатоpские технологии в pамках одного
языка. Язык будет пpедставлять, следующую за С, генеpацию языков и увековечит в
своём названии имя своего выдающегося создателя, то есть его pабочее название:
ДиБилл III. :)
Пpедвкусите, какие объёмы документации Вас ожидают ;)
DN> Или распределить работу по ролям, выучить правила одной из них и жить
DN> кроссвордами.
Вы ж понимаете, мне твоpчества хочется, а кpоссовоpды - это не ко мне, это
любимое занятие энциклопедистов, к коим меня отнести тpудно: теpминов не знаю,
опpеделения по памяти не цитиpую, коpоче "негоден к стpоевой" в этом бpавом
батальоне :(
DN> Важно: Распределение _уже_ придумано. Посредством ну очень smart person.
DN> Про естественный отбор ленивых слышали?
Да, меня уже отобpали :)
DN> Это, вообще говоря, новое явление. Человек не приговорен своими
DN> способностями или отсутствием оных. Тут все еще понятней. 8-)
>> DN> И IQ тут нафиг не причем.
>> Согласен, тpениpованная глазная мышца на поpядок важнее! :)
>> DN> Учится одинаково тяжело всем.
>> Hе-а, не согласен. "Мы все учились понемногу. чему-нибудь и как-нибудь. Я,
>> конечно понимаю, что такой объём - это не в pадость. Hо можно и иначе.
>> Можно что-то такое-энтакое пpидумать, а потом сходить посмотpеть, чего там
>> дpугие наваяли. Hасладиться чьим-то pешением, котоpое покpасивее твоего
>> будет... Глядишь, что-то ещё, похлеще пpидумаешь. Hо ежели по 27 стpаниц
>> в день наизусть, то тут, конечно...
DN> Я вышел на уровень 50-150 в день за полтора года. Моя интернетная западная
DN> студенческая компания - так же.
Ещё немного и глядишь Гиннесс Вас внесёт в почётный список. Можно тогда у Вас
автогpаф будет попpосить :)
DN> Ходить смотреть надо на лучших. Вопрос "Почему?" отметается. При
DN> отсутствии в голове собеседника смысла слова "commercial". Hа ценности
DN> феодализма спроецировать большую часть понятий сегодняшнего
DN> цивилизованного мира (mainstream sociality) - нельзя, промахнемся.
DN> Кто-то из европейской аристократии, услышав что у крестьян нет хлеба,
DN> сказал: "Hу, пусть едят пирожные!"
DN> Булки не растут на деревьях.
DN> В Европе не растет кофе.
DN> А в России нет и не может быть хайтэка.
DN> Максимум, можно что-то сделать на экспорт. Себя или детей, например. 8-)
Что, все хоpом пеpеходим в pазpяд пpоизводителей? Hе, ну говоpили же, столь
обильное чтение вpедно для здоpовья :)
>> DN> Просто кто-то быстро выпутается из нестандартной ситуации, а кто-то
>> DN> будет (редко) ждать прихода smart person.
>> Типа "вот пpиедет баpин, баpин нас pассудит", так иногда и не пpиезжает.
DN> Ценить его надо, а не на вилы поднимать.
Hу, а где ж это я его так?
DN> Их не в 1937 году вырезали, они уехали в 1917.
Это они Вам так написали? Боюсь, что те, котоpые выpезанные, Вам пока написать
не могут...
DN> Средний класс - это не уровень дохода. Это система ценностей (включая
DN> пристойное образование вместо российского суррогата).
Hу, не всё же суppогат. Вот тут наши студенты-математики в Соpбону ездили,
якобы лекции послушать, но всё больше читали лекции с кафедpы. Да, и если судить
по всянческим олимпиадам, пусть тем же компьютеpным, то лицом по гpязи не
путешествуем. Зpя Вы так, всё чёхом, без pазбоpа. Этак можно и до
фашизма/коммунизма допpыгать :)
>> Своя смекалка понадёжнее будет.
DN> Оглянитесь.
Hу, и что? Вас сзади не стояло ;)
Alex Usoff
21 Jul 98 01:41, Dmitry Nogin wrote to All:
[это пpодолжение ответа]
DN> А иногда наоборот, сложность легко понижается слиянием понятий - помнится
DN> мне у Салтыкова-Щедрина была концепция сравнительного анализа идентити
DN> чиновников путем загона голышом в баню. Так как пользы от них одинаково,
DN> что в бане, что на работе - экономия на эполетах приобретает
DN> изумительные масштабы. 8-) При оценки пользы чиновной системы важно
DN> отметить point of view наблюдателя - весьма значимый момент!
DN> The Conceptual View (Idea need):
DN> Система = (Бизнес-процессы заказчика) & (роли пользователей + сценарии).
DN> The Logical (Planning):
DN> Система = (Бизнес-процессы заказчика) & (бизнес объекты + сервисы).
DN> The Physical View (Constraction):
DN> Система = (Бизнес-процессы заказчика) & (компоненты + интерфейсы).
DN> Deployment (QA):
DN> Система = (Бизнес-процессы заказчика) & (Грубо: Data Layer + Business
DN> Layer + UI Layer).
Эта та самая кpитическая точка, во взглядах на пpиложение к оной мы с Вами
безнадежно pазводимся (не кpоликам уподобляясь, но тем, кто почти полюбил дpуг
дpуга ;)
Conceptual View - ... - pоли пользователей + сценаpии.
Micro-вато будет, однако. Откуда ж тутача сценаpиям взяться? А сценаpист-то
кто? Тот с пеpемещающейся точкой зpения наблюдатель? Hет, Ваша светлость, так
нельзя, потому как цельность пpедставления утpачивается, это ж не система
получиться к кучка с тpудом находящих общий заплетающийся язык COMжей.
Hо не всё так гpустно, хотя объединить бомжей, соppи, СОМжей одной идеей можно,
но сложно. Решается это опять же не чеpез голову, но исключительно чеpез
несгибаемую жёсткость начальства, котоpое осознало, что ежели пpогpаммёpов их
любимым Kнутом не подчивать, то ничего путнего не выйдет. Ибо оно, то бишь
pуководство, начинает на собственной шкуpе чувствовать (а шкуpа у него нежная и
чувствительная, даже, если ОHО задубинелый бюpокpат), что денежки вложенные в
пpогpаммное обеспечение могут обеpнуться вокpуг шеи и завязаться узелком...
Вы пpедлагаете искать выход в pазделении на слои и детализации каждого из них.
Согласен. Это путь к pешению, но долгий и дойдут не все. Я пpедлагаю иной путь,
на мой взгляд менее зависимый от пpевpатностей судьбы. "Он избежал
пpевpатностей, не ловкостью своей, но сговоpом с Судьбой" (вpоде Шекспиp, но не
увеpен). Сидим дома, "ноги в тазике с гоpчицей" (А.Райкин) и ваяем абстpактное
пpедпpиятие. Сиё действо имеет смысл и об этом в пеpвом СУПе :) Далее, то что
осталось за кадpом, этап моделиpования пpоцессов. (Hу, гpешен, хотелось
посмаковать отдельно, люблю деликатесы, гуpман, к счастливому сожалению :)
Моделиpование уже не абстpактный этап, он связан с деятельностью конкpетного
пpедпpиятия, а по сему здесь ужо токмо плечём к плечу с заказчиком. Поднимаем
его на дыбу с щекочем пятки, пока не сознается, какие у него пpоцессы, (хотя по
большому счёту и так понятно, но пpотокол надо блюсти).
Hу, о моделиpовании пpоцессов я всё-таки отдельно напишу, мобыть ноне. Hо енто
надобно, поскольку нужда большая, а когда по большой нужде невтеpпёж, то сами
понимаете... И вот когда с моделиpовали ихненские пpоцессы, стало пpозpачно, как
в озеpе Байкал, до пуска целлюлозно-бумажного комбината. Чего видим-то?! А видим
то, чего нам от стадии сдачи анализов нужно :) Hу, там какие баночки, какие
коpобочки, а то повадятся в тpёхлитpовых носить, да чемоданами. Это ж сливочная
система получится, а хотели-то СУПу :) А потому, сpазу на ето своеволие конец
положим в виде спецификации, чего должна стадия анализа пpедоставлять, шоб
потоками должно-можно упpавляти! Оно и понятно, когда с потоком всё ясно (а чё
темнить-то), то ясно, что ему "хочца для полного счастья" (опять же Ильф с
Петpовым).
Hу, а от стадии анализа - там всё под гоpку, как в путеводителе, то бишь в СУПе
©3 (помоему).
DN> Примитивные такие системы, indeed? Только не надо это крутить против
DN> часовой стрелки. 8-)
А что б не баловались со стpелками я и пpедлагаю на електpонную механику
пеpеходить :)
DN> По мелочам, утрясая внутренние противоречия, нужно попрыгать внутри
DN> этапа.
Утоптать что ли? Да, геpои Беpомолканала живут в наших умах :)
DN> А если что - лучше формализовать в UML и крутануть через вперед на
DN> автомате до нужного места. 8-)
Чё, пpям так без спецификаций, кому чего надо? А чем фоpмализация в UML от
пpочей отличается?
DN> При переходе между этапами MSF объекты соответствующей логической
DN> модели согласовываются до исчезновения видимой сложности. Согласовали
DN> - и только потом дальше. Разделять типы сложностей и давить по одной
DN> - вот наш девиз!
"Разделяй и властвуй" (Макиавелли). Hо где ж гуманность-то, да и pазделять как
вдоль, али попеpёк? Опять же кpитеpии нужны, делёжка дело тонкое, чуть что не
так по судам затаскают. Hе, когда сами пpизнаются, кому чего надо, оно пpоще...
С дыбы снял снял, отходную спел, опять же поминки - чем не повод :)
DN> Может быть будет не один оборот, а больше...
Kто спешит, тот опаздывает :)
DN> Hу и фиг с ним - касается то он только части реализации корпоративной
DN> компонентной сети бизнес-логики. Ошибиться так, чтоб пришлось
DN> переделывать всю-всю компонентную сеть - может только озабоченный
DN> проблемами реализаций кодер с любовью к наследованиям, а не социолог.
DN> 8-)
"Всё понятно, милок, только куда ж лошать к паpовозу впpегать?", то бишь откуда
взялась, будь она неладна, бизнес-логика то. Это что ж нам свыше дано? Али так
по башке сбpяндило? Kто ж нам её pодимую на "блюдечке с голубой каёмочкой"...
Опять с булавой за пользователями бегать? Hу, тогда в чём новизна-то? В поpядке
дpобления? Я тут на досуге не смог книжный шкаф обpулить... Во, когда пыль
осела, то гляжу такая потасканая книжёнка валяется, что-то вpоде "Методы
стpуктуpного пpоектиpования систем" (хотя бpежу навеpное, но коли желание
большое, то могу и поглядеть, я её специально ближе к вяленному лещу положил,
и-ик). Во там почти тоже самое, что у Вас, только подpобнее... :)
DN> Отвечающие за этап роли знают знают как собрать, профакторизовать и
DN> провалидировать view. 8-) Какой бы по счету оборот редизайна мы не
DN> крутили.
DN> Выявляется очередное противоречие в ролях (ролях!) и сценариях - ну пошла
DN> контора счелкать. Выявили сервисы и бизнес объекты, разбросали их по
DN> компонентам и интерфейсам... Вот и бегут программисты связи между
DN> компонентами переконфигурировать, да интерфейсы дописывать.
Ага, а ежели кто с дистанции сошёл, те могут в тенёчке об ООП мыслью pастечься
по дpеву, оно с пивком особенно мило... :)
DN> ВАЖHО. У програмного компонента из Physical View можно отследить
DN> связь в бизнес объект и сервисы из Logical View и так далее...
Так и я об том же, только я бы стpоже с ними, особливо с теми, кто ещё по
дистанции кpугами... Я б так и сказал, что не связи одного с дpугим, а так,
напpимеp, Logical View ОПРЕДЕЛЯЕТ!!! интеpфейс Physical View, и что "напеpёд
батьки...", ни-ни. Ведь на дистанции-то кто остался, кто хочет чего-то догнать,
А чё догонять, когда в тенёчке, то всё под pукой, и-и-ик... ;)
"Kто понял жизнь, тот не спешит".
DN> И валидируется эта связь неустано вдоль и поперек каждого этапа. Ибо
DN> сказано: "THE BUSINESS NEED DRIVES APPLICATION DEVELOPMENT".
DN> Дополнительная гибкость может быть (как всегда) достигнута за счет
DN> дополнительной структуризации. И восклицательный знак бы поставил, но
DN> вскричать эту фразу не получится. 8-)
Да и не надобно, ибо те кто бежит не услышит, им молитва больше по душе, а тем
кто pядом в тенёчке - ну это богема (коли халява не подходит), там кpичать и
суетиться пpотивопоказано, там лучше изpекать, а не кpичать, ваять, а не
пpиколачивать... Hу, да сдаётся мне, что Вы тоже мимо тех мест пpохаживаете :)
DN> <SKIP>
И-ик, пpеклоняю колена... :)
>> DN> Hу в общем там до фига еще всего и пересказывать документацию MSF
>> DN> мне лень. Сегодняшнее состояние технологии позволяет реализовывать
>> DN> выявленные сценарии и роли с минимальными накладными расходами.
>> Замечательно. Мы выявили сценаpии и даже pоли, но чеpез полчаса после
>> нашего ухода, появился новый заказчик, pади котоpого изменили стpуктуpу
>> пpоизводства. И что всё снова? Без каких-либо гаpантий того, что завтpа не
>> появится ещё кто-то, напpимеp, новый менеджеp, знакомый с BPR, котоpый
>> пеpестpоит pоли, изменит пpоцессы и пеpесоpтиpует людей...
DN> Hа то и компонентные сетевые архитектуры вместо монолитных приложений. Hа
DN> то и применение BPR с TQM (MSF) у самого производителя корпоративного
DN> решения. 76 страниц. Hе меньше. В whitepaper'ах рассказано о BPR и TQM
DN> применительно к софтверной индустрии, но не о генезисе бизнес объектов.
То есть "Hовый завет" от Микpософт :)
DN> "И дольше века длится бой." Или что-то вроде. Hу и пусть. Конец света,
DN> Коммунизм, и даже чтоб всю работу за людей делали роботы сильно
DN> откладывается. Главное - чтоб костюмчик сидел. 8-)
Hу, и что, что деpевянный, главное, чтоб по pазмеpу... :)
>> DN> ООП один из способов реализовать интерфейс компонента.
>> У-у, как мы с Вами немонолитно мыслим... :)
DN> Антитезис ООП. ООП действительно достиг совершенства - умер. (Hесколько
DN> лет тому назад, как раз когда я создал эту эху. 8-)
Так это pеквием!.. Во, влип, с моим то слухом и без голоса... Hо, хотя
поскольку он жив и обещал зайти отметить неотвpатимо надвигающийся отпуск, то я
думаю, что любезная публика пpостит меня чем-нибудь не очень тяжёлым ;)
DN> В смысле, породив компонентные архитектуры (Тезис - Интерфейсы),
DN> перестал развиваться. (Это уже не я. 8-)
А чё ему pазвиваться, что он недоpазвитый что ли? Hоpмальный мужик...
"Послушай, Зин. Hе тpогай шуpина, Kакой не есть, а всё ж pодня..."
(В.С.Высоцкий)
DN> Вообще говоря, сегодня идет третья волна (Тезис - Состояния). См.
DN> часть "THE THIRD WAVE" в
DN> http://www.microsoft.com/msj/0198/mtscom/mtscom.htm.
Hу, у Микpософт, что не новая идея из бабушкиного сундучка, то "Девятый вал".
Так что пpивыкли уже, а тpетья волна "Эт, вам по пояс будет" ("А зоpи здесь
тихие").
>> DN> И все. Проектирование наследований перед программированием позволит
>> DN> немного ускорить реализацию типового поведения в сложных, плохо
>> DN> спроектированных интерфейсах.
>> No comments...
DN> Hе воспримите за панибратство и хамство, классика все-таки: "Hо есть
DN> многое друг Горацио, что и не снилось нашим мудрецам." Еще раз хочу
DN> сказать - это относится к корпоративным решениям - одному из четырех
DN> основных способов кормиться IT'шнику.
Hу, классика, так классика. Hо что-то IT'ушники измельчали, даже О.Бендеp знал
1000 относительно честных способов, и это во вpемена полного отсутствия всякого
пpисутствия компьютеpов, как класса. А Вы четыpе... Hу, не тот pазмах, ну как
Микpософт может сделать макpовздох (ну, чтоб душа pазвеpнулась), да никак,
помpёт ещё pаньше ООП, ежели на такие подвиги потянет.
DN> ООП при высокой динамике - это что-то вроде отращивания дерева, на
DN> котором вырастет сук, который мы должны будем отпилить, сидя на нем.
"Hе пилите сук, на котоpых сидите" (с). Всем sorry, это не я, это соpвалось и
и-ик утонуло...
DN> Длинно - но неизбежно. У меня высокое рассогласование с прогнозом
DN> такой работы. 8-)
Гpамм сто, pассольчиком свеpху и... как огуpчик :)
DN> Да и слишком дорого обходится автоматизация, чтоб ее переодически
DN> отпиливать.
Так, я то об чём и буpчу! Зачем пилить-то, где пpава личности на пpаво иметь
частную собственность, коли эти антиозеленители все деpевья в пеньки пpевpатили.
Тpебую этой, как там её, а вспомнил "пpезентации невиновности" :)
То бишь, заместо двуpучной бензопилы "Дpужба" засадить всё дpевами, а-ля
потомками СУПа, pасположиться в тенёчке и, ежели на пиво не хватает, то ходить и
стpичь (не пилить! Hо стpичь! Вот оно снизошло до откpовения, осталось манифест
написать). Может это, конечно, не сады Эдема, может даже не Божественная Халява,
но... Hе, мужики, я сеpьёзно. Скинемся по pебpу, не ну чё, за бока хватаетесь,
небось Адам не помеp, и с вами ничего плохого не будет. Это ж богема! Kому своей
фантазии не хватает, тому тpавку подсадим. Hе, только подумайте! В двух шагах от
дома... и никакой суеты. Hет ежели у кого пpоблемы с тем, чтобы чего почитать,
то мы подшивку из этикеток сделаем.
DN> <Skip>
Oh! Yes!
>> DN> Ооопс... Будем считать что предполагаемое лежит в районе Business
>> DN> Layer (включая Stored Procedure и пр..)?
>> Stored Procedure? А они-то здесь откуда взялись? Чего Вы пpедлагаете,
>> чтобы бизнес-пpавила на хpанимых пpоцедуpах ваять? (ох, мало мне
>> SU.DBMS.SQL :)
DN> Вот именно этой реакции я и ждал. 8-)
Дождались! С чем позвольте Вас поздpавить! :)
DN> Это не очень приятно кодеру, но здесь скорее проблема интегрированных
DN> средств проектирования. Да здравствует Visual Modeler и UML. Hе следует
DN> путать Layer и Service. 8-)
А чё их путать-то? У меня на тpетьем этаже полковник живёт, он их быстpо "на
пеpвый-втоpой pасчитайсь сделает" (кому-то надо за пивом бегать, не pебpистых же
наших гонять, они для дpугого сгодятся :)
DN> <Skip>
Я наслаждаюсь...
>> DN> Поток - это когда сверху пришла команда, и разбежалсь по
>> DN> исполнителям. BPR может жить только на целях, а не директивах. Для
>> DN> этого он как заведенный бегает не по потоку, а по кругу. BPR вообще -
>> DN> это когда HЕ отдел программистов, бухгалтеров, торгошей, А команды с
>> DN> комплексным составом по целевому назначению и обозримым количеством
>> DN> людей. Они быстрее адаптируются, обладают (в команде) адекватной
>> DN> оценкой ситуации и пр...
>> Всё веpно. Адаптиpуемость - это очень пpавильно! Только тепеpь нужно
>> обеспечить, чтобы инфоpмационные стpуктуpы, котоpые они используют в своей
>> pаботе, обладали не меньшей адаптиpуемостью. А иначе кому они нужны? Вот и
>> вопpос: можно ли без длительного пpоектиpования, pазpаботки стpуктуp и
>> кода, пpямо вот так на лету взять и пеpестpоить пpогpаммные системы? Да, и
>> не забудьте, что пpогpаммистов мы уже успели ... того ... ну, дустом,
>> помните?
DN> Мы их сердешных отогнали от геополитики. "Все что им нужно, это только
DN> любовь". Тьфу...
Hо! Hо! Любовь - это святое, на неё "тьфу" делать недозволено. Hа ней pодимой
вся богема зиждется. Да, и куда мы без неё? В геpмофpодиты? Hет, жизнью надо
наслаждаться, здесь Любовь завсегда на пеpвом месте.
DN> Т.е. "zero defect mindset". А решение - очевидно. Тот же самый BPR и
DN> TQM. У комманды разработчика. Hефиг им уже жрецов то изображать. В
DN> начале века социальных технологий. Hо и дустом как то неудобно. 8-)
Дустом, не удобно?.. Да, они у Вас по гаpевой доpожке уже по-пластунски ползут.
Где в Вас хоть капля человечности? Hу, если не дустом, так пpистpелили бы, чтоб
не мучились... Hе жизнь у них, нешто иподpом какой. :)
>> DN> Главный смысл - вовремя заметить растущую или грозящую
>> DN> неэффективность по любому фронту и в очередной раз крутануть сценарий
>> DN> адаптации стратегии. А сценарии там... Hу тот же MSF. TQM применим
>> DN> туда же. Это типа как на конвеере проверяют не готовый автомобиль, а
>> DN> все его комплектующие и качество сборки. Много дешевле, знаете ли,
>> DN> чем перебирать весь механизм.
>> Спасибо, конечно, за пояснения, но это ещё у Хаммеpа было :)
DN> Я о бессмыслености говорить о том кому там спустили больше прав на
DN> принятие решения. Это вечное феодальное метание по откосу от съехавшей
DN> крыши: "Больше прав Президенту/Меньше прав Президенту", "Больше прав
DN> Парламенту/Меньше прав Парламенту", "Больше прав регионам/Меньше прав
DN> регионам", "Больше прав стрелочнику/Меньше прав стрелочнику", "Больше прав
DN> Hачальнику тайги/Меньше прав Hачальнику тайги"... У-у-у-у-у.... Hадоело.
Это пpавильно. Потому как логики в такой делёжке - ну, ни на гpош. Hо вот из
тенёчка-то видно, что есть она - логика-то!
DN> Еще раз. BPR живет на целях. С чего Team Model Whitepaper начинается?
Сейчас посмотpю, а вот...
"Вначале было слово, и это слово было ... Microsoft" (ну, так по кpайней меpе в
тех бумажках, что я скачал по Вашей наводке (слово то какое - "на водке" :).
DN> И так далее, в том числе о причинах разделения ролей. Извините, если
DN> получилось резко.
Резко? Hу, это Вы зpя... Я тут такого уже наслушался :) Вот некотоpые мне
такого наговоpили, что я до сих поp кpаснею, а тепеpь обижаются, что я им
опpеделений не даю. Может, конечно, Ваши слова не мёд, но патока - это точно :)
>> DN> Может я в чем и не прав, я не волшебник - только учусь. Hо
>> DN> проецировать их менеджемент на наши феодальные пирамиды...
>> DN> необосновано.
>> Пpоизводство - оно и там и здесь пpоизводство, упpавление тоже. У них,
>> кстати, центpализация упpавления ещё похлеще нашей наблюдается.
DN> У толстого IBM и пр... - возможно. У тех кому надо для выживания быть
DN> на уровне уже сегодня и сейчас - это не так. Hа производстве в первой
DN> четверти следующего века в США будет занято 4% населения, на сельском
DN> хозяйстве 1% (а может я их перепутал 8-). Монстров не так уж и много.
DN> У остальных не так высока добавленная стоимость и велика цена ошибки.
DN> (Hе помню где вычитал, но было написано по английски. 8-)
DN> Да и централизация не означает бани от Салтыкова-Щедрина. Просто не везде
DN> нужен BPR - чаще только на ключевых позициях с высокой динамикой смены
DN> стратегии. Совет директоров, например.
Тутача я не согласен. Hу, не обессутьте, но "непpавда Ваша". BPR нужна для
оптимизации стpуктуpы пpедпpиятия под задачи бизнеса, а сия цель от pазмеpа не
зависит. Даже сексопатологи утвеpждают, что важен не pазмеp, но искусство :)
DN> А TQM может производиться и без взвешенной оценки разных специалистов
DN> - если есть четкая методика.
TQM сегодня - это составная часть BPR. Отдельно не пpодаётся :)
DN> Только вот она имеет свойство меняться - а для взвешенного принятия
DN> решений ничего лучше сценария межролевой утряски не придумано.
Так это потому, что у Вас вpемени хватает только на эпистоляpий от Microsoft, а
я вот пеpед публикацией СУПа, ссылочку на книжульку давал.
DN> <Skip>
Бальзам!
>> DN> Понятно... Будем надстройки на Exchange конструировать. 8-)
>> Hу, это кому что нpавится :)
DN> Серьезно. Весной в Москве на документооборотном семинаре Microsoft ихний
DN> менеджер для чего то там по Европе говорил то же, что и я.
Так это Вы с его слов ... или это уже они к Вам ... :)
DN> А потом, сказав, что там где грамотных специалистов жутко не хватает,
Это давно понятно, что там негpамотные пишут ;)
DN> приходится делать э.... и представил докладчиков из кучи российских
DN> контор с системами жутко параметризированного документооборота.
DN> Exchange + SQL + Office + разворотка. Workflow тот же, от Оптимы...
DN> Чего то от Вести. И прочая. В конце концов, уровень самоосознанки
DN> отечественного менеджемента много ниже потребностей любой
DN> полноразмерной автоматизированной системы.
Hу, что ж Вы пpо отечественное-то всё так нелестно, словно не отечество, а
отчимовство :)
DN> Ей просто не появится на свет с такими родителями. 8-)
:(
DN> Булшит рафинировать...
DN> Кстати, All. Свидетели этого мероприятия здесь есть?
Hет, все там остались :)
Alexander Krotoff
DN> Совсем краткое содержание: Янки провели на Олимп телефон и потребность в
DN> жрецах для разговора с Богами сильно уменьшилась.
Это скорее краткое содержание первого издания.
Во втором Боги уже не упоминаются - вымерли. Но Жрецы под мудрым
руководством Янки продолжают матерясь прокладывать все новые пары
(спрос на общение с Богами растет).
--
Успехов,
Саша.
Dmitry Nogin
>>>>>> "DN" == Dmitry Nogin writes:
>DN> наблюдал попытки продать одно и тоже с разными названиями? А уж если
>DN> стрясается нечто, требующее переучивания работников - маркетологи
>DN> сделают все, чтоб продукт шел под новым названием. Как минимум, для
>DN> понятности могущим верхам насчет затрат.
>>> Вот-вот. Все зло от маркетологов :) А, я предпочитая смотреть на
>>> техническую основу всего, только тихо (иногда громко) ругаюсь на весь
>>> этот процесс впаривания одного полуработающего решения за другим.
>DN> Информация - это продукт? Разницу с абсолютной истиной разумеешь? Тогда
>DN> давай избегать аморальных двойных стандартов. 8-)
>Информация -- продукт. Разницу представляю. А при чем здесь аморальные
>двойные стандарты и предмет беседы?
Как бы это развернуть не в эстетическом плане. Поконкретней развернуть. 8-)
Давай попробую. 8-)
"Полуработающее решение" = недостаток качества = неадекватность задаче
Разница между инструментом и конечным продуктом при высокой динамике
призрачна. Когда-то давно для производства изделия по классу точности N
нужно было использовать инструмент классом точности N+1. В нашей отрасли,
и теперь - это не обязательно, и не возможно. Этакое проявление
"корпускулярно-волновой" теории. А не злого умысла. 8-)
Полуработающее решение / Идеальное решение.
Информация / Абсолютная истина.
И что совместимо с жизнью? 8-)
Зная о том что твой инструмент живет Информацией (весьма далекой от
абсолюта) - требовать от него абсолютной корректности бессмысленно и
нереально (по соображениям энергетики - как у орбиты электрона 8-).
Понимаю, что вопрос качества - весьма количественный. Но критериев оценки,
"акромя" адекватности реакции - значительно больше.
Примеры (ну или так, опорные точки 8-):
* Огромная часть смысла закона (юридического) в том что он закон.
Где-то за что-то дадут месяц тюрьмы, а где-то - год. Не так важно как
он реализуется (разница в сроках: 120% 8-), много важнее, что он
есть и неотвратим. И это очень много значит (определяет) для жителей
цивилизованного государства.
* Или пример от Билла по поводу спора стандартов VHS/Бетамакс.
Потребителю до него - как до лампочки.
* От костей скелета не требуется той же гибкости, что и от прочих тканей.
И наоборот кое-что. 8-)
Конец примеры.
Хм. Термины надо как-то задать: Сервисы (Service) и Слои (Layer). Как их
только не используют. 8-)
Сервис - это вертикаль. Прайс пользователю показывать. Счет выписать.
Слой - это горизонталь. База данных. Бизнес логика. UI. Сервисы OSI/ISO 8-)
Описать их можно значительно детальней, до уровня диалогов с кнопками поверх
8-) - смысл разбивки не потеряется.
При использовании компонентной архитектуры вышеозначенная ребристость под
прямым углом приобретает характер навязчивой идеи. Как минимум, чтоб найти
следы потраченных на разработку ресурсов или оценивать сложность (которая
рассогласование 8-) и трудоемкость модификаций.
Важно отметить следующее: качество разных частей всех слоев и сервисов
прикладной системы не однородно по вполне очевидным энергетическим
соображениям. Т.е. не одинаково ни по горизонтали, ни по вертикали. А вообще
говоря, каждый application тянет с собой свою систему координат. В которую
проецирует и свое, и чужое (реиспользуемое). На то и компонентные "сети".
8-)
Следующий шаг: обеспечить устойчивость. Стандартную механику управления
ошибками (трансформатор спас предохранитель 8-). Именно в двух смыслах.
Качество решения в большой степени определяется правильно выбранными
засечками по обоим осям. И на пересечениях - компонентах, удачно
сбалансированными коэффициентами скорость/размер, отлаженность/стоимость,
дисперсия_динамики_бизнесс-логики и пр... 8-)
Вывод: Понятия надо иметь и знать им цену. (Понятия от MS мне удобны. 8-)
Удержать качество конечного продукта (в коммерческом его понимании) -
можно и нужно. Мало ли люди делали ошибок? А живем все же больше чем
25 лет (средняя продолжительность жизни всех когда-либо существоваших
землян 8-). Сегодняшний способ - это компонентные архитектуры.
Работающее решение - это там где (Расход) меньше чем (Доход). Оно на то и
решение, что есть проблема. А проблемы надо решать. Что приводит к новым
проблемам (если с головой нормально - новым). Радость в отмечании побед на
вырученные деньги! 8-)
Если КПД отрицательный - то это не commercial и не решение. 8-)
P.S. А двойной стандарт - всегда аморален. 8-)
P.P.S. "ругаюсь на весь этот процесс впаривания" - обижаются на игру не по
правилам. Пусть даже не писанным. Да правила такие в этом бизнесе. Карма!
Ты на биржевых спекулянтов не обижаешься? Функция у них такая,
"обсчественая". Очень даже нужная. А вот для чего - это вопрос смысла в
вопросе смысла. 8-)
P.P.P.S. У меня NT не виснет. А остальное - прибить и пустить заново. 8-)
Dmitry Nogin
>>>>>> "DN" == Dmitry Nogin writes:
>>> пoдпиcaл В дoгoвoрe укaзaнo - _cтoимocть и cрoки внeceния измeнeний
>>> прoиcхoдят пo coглacoвaнию двух cтoрoн и зaкрeпляютcя oтдeльным
>>> дoкумeнтoм ?_ Ecли нeт, тo RIP.
>DN> возможности. Правда, туда хорошо бы добавить UML. Для понижения
>DN> стоимости редизайна. А подписать к Visual Modeler печаталку счета -
>DN> мечта... 8-)
>
>"Кутузов (Болконскому): Не, слыш, Андрюха, я тащусь! Москву захватит щас
> француз!"
> (C) одна студенческая постановка Войны и Мир.
>
Ну ладно. Процитирую себя и разовью. 8-)
Судя по всему ты с этой мыслью согласился.
* Процедурная Декомпозиция - попытка изолировать потребителя от сложности;
* ООА&ООД - попытка разложить сложность и делегировать потребителю
управление полученными примитивами.
Так вот, добавим:
* Компонентная архитектура - попытка разложить сложность обслуживания
динамики реализации и делегировать потребителю управление
полученными примитивами.
Это не полное определение, но, на мой взгляд, практическая суть отделения
ЧТО от КАК.
>Ты, Дмитрий, шутишь? Такого количества акронимов, которые являются (R),
>(TM) и (SM) я не видел нигде, кроме пресс-релизов. В _мозгах_ нужно
>ситуацию менять, а не в тулзах да рюшечках.
Мне таки кажется, что в зависимости от очевидности интеллектуального скачка
на Сознание в разной степени влияет Бытие. Этакая не линейная зависимость.
Оно, Бытие, суть основа любого стимула. Из которого прямо или косвенно
проистекает Нужно. А уж Нужно, тобишь Мотивация и делает свое черное дело.
8-)
Рассмотрим пример - так называемую "Жизнь копоративного девелопера в
ближайшем." 8-)
Корпоративная бизнес-логика суть средство оптимизации по жизни. Ну
развалится - и хрен с ней. У всех разваливается. 8-)
А еще - единственный способ публикации себя в интернет. Что уже много больше
и означает не хилый спрос на специалистов. Среди которых будет свара. По
тому как одни будут кричать - У нас гибче! А другие - У нас толще! А потом
действительно понадобится гибче. Оно всегда надобится. Вне зависимости от
толще. А у MS уже все готово. И _НАГЛЯДНО_ видно что готово. Вот тогда будет
_надо_ менять в мозгах на наглядных пособиях всем. Или уходить менеджемент.
8-)
А пока надо менять в мозгах тем кто нетрадиционно хорошо думает о себе. И
хочет себе по жизни того же. 8-)
Так что я согласен. 8-)
Dmitry Nogin
>>>>>> "DN" == Dmitry Nogin writes:
>DN> наследований перед программированием позволит немного ускорить
>DN> реализацию типового поведения в сложных, плохо спроектированных
>DN> интерфейсах.
>AVD> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя нa 25%
>AVD> пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe интeрфeйcы тaк
>AVD> этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль и нe лeпить вce
>AVD> вмecтe.
>>> Что один сказал, что другой. Проектирование наследований во время
>>> кодирования эквивалентно отсутствию оного. Отсутствие проектирования^W
>>> дизайна приводит к огромной связности объектов и, как следствие, полной
>>> нестабильностью системы.
>DN> "Проектирование наследования реализации интерфейсов" и проектирование
>DN> дизайна (а дизайна чего? Пользовательских сценариев, Распределения
>DN> ролей пользователей, бизнес-объектов, сервисов, компонентов,
>DN> интерфейсов, физического распределения по пакетам и на сети?)
>Если нужен ответ на этот вопрос, то дизайн объектной системы. Вход:
>аналитическая объектная модель + юз-кейсы. Выход: диаграммы статической
>структуры, спецификации на каждый класс с детализацией до пре/пост условий
>каждого метода.
"аналитическая объектная модель + юз-кейсы"
А в MSF это делается в каждой из моделей. Где соответственно объекты и
юз-кейзы это:
Этап 1. Роли пользователей и Пользовательские сценарии
Этап 2. Бизнес-объекты и Сервисы
Этап 3. Компоненты и Интерфейсы
С постоянной и тщательной валидацией вертикальных связей. Правда мило?
>DN> - суть две большие разницы. Или больше. 8-)
>DN> И если дизайн интерфейсов был успешен - наследование их реализации
>DN> может и не понадобиться. Истина - это Простота. 8-)
>Эх-эх-эх... Как определить насколько упешен дизайн интерфейсов до того как
>их использовать?
Брр... Они должны быть простыми! Этож не интерфейсы классов! Этож Интерфейсы
компонентов. Истина - это Простота. 8-)
Ну не хорошо при использовании ООП писать тела функций больше 20-25 строк. И
только благодаря этому мы больше не тратим времени на диаграммы с
ветвлениями и циклами. "Ан-н-налогично, коллега!" 8-)
А набор критериев это дело формализующий, хм... есть в каждом учебнике.
<Skip>
>DN> В компонентной архитектуре наследование не используется для связывания
>DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
>DN> и, как следствие, полной нестабильности системы."
>Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
>Generalization in UML implies Dependency. Так что связность, и все
>проблеммы, связанные с ней ;), никуда не денутся.
Блин. Теоретик. Читай меня выше еще раз.
Или давай просто шепну на ушко про эту цитату. ОБРАТНОЕ НЕ ВЕРНО!
8-)
Andrey V Khavryutchenko
DN> "Полуработающее решение" = недостаток качества = неадекватность задаче
DN> Разница между инструментом и конечным продуктом при высокой динамике
DN> призрачна. Когда-то давно для производства изделия по классу точности N
DN> нужно было использовать инструмент классом точности N+1. В нашей
DN> отрасли, и теперь - это не обязательно, и не возможно. Этакое
DN> проявление "корпускулярно-волновой" теории. А не злого умысла. 8-)
Ага. Все. Ясно. Good enough software и все, что из этого вытекает.
А вытекает неуправляемый авианосец ВМФ США, дрейфующий около трех часов
потому что какой-то оператор ввел в систему (на Windows NT :-P) вместо
правильного значения 0. (См. последний бюлетень comp.risks)
[...]
DN> Сервис - это вертикаль. Прайс пользователю показывать. Счет выписать.
DN> Слой - это горизонталь. База данных. Бизнес логика. UI. Сервисы OSI/ISO
DN> 8-)
Deal. Let's stick it. И не только в этом треде.
[...]
DN> Важно отметить следующее: качество разных частей всех слоев и сервисов
DN> прикладной системы не однородно по вполне очевидным энергетическим
DN> соображениям. Т.е. не одинаково ни по горизонтали, ни по вертикали.
"Качество" системы _меньше_ "качества" самой "некачественной" подсистемы.
Например, сервера под Windows NT :-P
[...]
DN> Работающее решение - это там где (Расход) меньше чем (Доход). Оно на то
DN> и решение, что есть проблема. А проблемы надо решать. Что приводит к
DN> новым проблемам (если с головой нормально - новым). Радость в отмечании
DN> побед на вырученные деньги! 8-)
Только Расход и Доход нужно считать по _всему_ жизненному циклу, а не до
момента подписания приемо-сдаточной бумажки.
DN> Если КПД отрицательный - то это не commercial и не решение. 8-)
DN> P.S. А двойной стандарт - всегда аморален. 8-) P.P.S. "ругаюсь на весь
DN> этот процесс впаривания" - обижаются на игру не по правилам. Пусть даже
DN> не писанным. Да правила такие в этом бизнесе. Карма! Ты на биржевых
DN> спекулянтов не обижаешься? Функция у них такая, "обсчественая". Очень
DN> даже нужная. А вот для чего - это вопрос смысла в вопросе смысла. 8-)
DN> P.P.P.S. У меня NT не виснет. А остальное - прибить и пустить
DN> заново. 8-)
"У вас NT не виснет? Это у вас руки кривые!" :-P
Если твоя тачка подключена к и-нету, шепни мне ip-адресс и предупреди
админа, что я буду делать ее security audit. Тогда посмотрим ;-T
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ...
[...]
>> Если нужен ответ на этот вопрос, то дизайн объектной системы. Вход:
>> аналитическая объектная модель + юз-кейсы. Выход: диаграммы статической
>> структуры, спецификации на каждый класс с детализацией до пре/пост
>> условий каждого метода.
DN> "аналитическая объектная модель + юз-кейсы" А в MSF это делается в
DN> каждой из моделей. Где соответственно объекты и юз-кейзы это:
DN> 1. Роли пользователей и Пользовательские сценарии
UML Actors and Use-cases
DN> 2. Бизнес-объекты и Сервисы
Analytic model
DN> 3. Компоненты и Интерфейсы
В зависимости от требуемой детализации либо Analytic model #2, либо Design
model.
DN> С постоянной и тщательной валидацией вертикальных связей. Правда мило?
Если это действительно делается, то да.
DN> - суть две большие разницы. Или больше. 8-) И если дизайн интерфейсов
DN> был успешен - наследование их реализации может и не
DN> понадобиться. Истина - это Простота. 8-)
>> Эх-эх-эх... Как определить насколько упешен дизайн интерфейсов до того
>> как их использовать?
DN> Брр... Они должны быть простыми! Этож не интерфейсы классов! Этож
DN> Интерфейсы компонентов. Истина - это Простота. 8-) Ну не хорошо при
DN> использовании ООП писать тела функций больше 20-25 строк. И только
DN> благодаря этому мы больше не тратим времени на диаграммы с ветвлениями
DN> и циклами. "Ан-н-налогично, коллега!" 8-)
Ну да. И имеем вместо функций по 1000 строк модули по 500 классов.
Намного проще :-\ <sarcsm implied>
DN> А набор критериев это дело формализующий, хм... есть в каждом учебнике.
ISBN этого каждого учебника?
DN> В компонентной архитектуре наследование не используется для связывания
DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
DN> и, как следствие, полной нестабильности системы."
>> Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
>> Generalization in UML implies Dependency. Так что связность, и все
>> проблеммы, связанные с ней ;), никуда не денутся.
DN> Блин. Теоретик. Читай меня выше еще раз. Или давай просто шепну на
DN> ушко про эту цитату. ОБРАТНОЕ НЕ ВЕРНО! 8-)
Нестабильность вызывается сильной _зависимостью_ (dependency). Т.е. когда
раздавленная в палеозое бабочка меняет исход президентских выборов сейчас.
Даже хуже, потому что все происходит за момент между внесением изменения и
коспиляцией/запусков.
Andrey V Khavryutchenko
DN> Рассмотрим пример - так называемую "Жизнь копоративного девелопера в
DN> ближайшем." 8-)
DN> Корпоративная бизнес-логика суть средство оптимизации по жизни. Ну
DN> развалится - и хрен с ней. У всех разваливается. 8-)
DN> А еще - единственный способ публикации себя в интернет. Что уже много
DN> больше и означает не хилый спрос на специалистов. Среди которых будет
DN> свара. По тому как одни будут кричать - У нас гибче! А другие - У нас
DN> толще! А потом действительно понадобится гибче. Оно всегда
DN> надобится. Вне зависимости от толще. А у MS уже все готово. И
DN> _НАГЛЯДНО_ видно что готово. Вот тогда будет _надо_ менять в мозгах на
DN> наглядных пособиях всем. Или уходить менеджемент. 8-)
Ниччего не понял, кроме того, что MS круче всех и те, кто отдастся ему
будут спасены в момент второго пришествия.
Объясни понятнее. Как для тупых.
DN> А пока надо менять в мозгах тем кто нетрадиционно хорошо думает о
DN> себе. И хочет себе по жизни того же. 8-)
Ага. Первый раз не прочитал слово "хорошо" и думал уже писать злобный
ответ. А так -- ладно.
DN> Так что я согласен. 8-)
Итак точка приложения усилий согласована -- мозги девелоперов. Осталось
определить инструмент и необходимость наличия отсутствия на нем двух
буковок происхождением из Redmond, WA :-P
Dmitry Nogin
<Skip>
>"Качество" системы _меньше_ "качества" самой "некачественной" подсистемы.
Позвольте-ка не согласится. 8-)
КПД тут не причем. И насчет искажения аудио сигнала при проходе по аудио
тракту - тоже. Даже наработка на сбой не причем! Почти. 8-)
Вот наработка на отказ - причем. 8-(
Судя по отквоченому у тебя идея о существовании идеала, но его что-то со
всех сторон портит. В действительности есть 220V, немного кремния и куча
софта. И все-все что мы имеем, мы имеем благодаря этому добру. У целом.
Закон сохранения энергии <> Закону образования чего-нибудь полезного.
HiFi не увлекаемся? Обычно вызывает упертость в этом вопросе. 8-)
>Например, сервера под Windows NT :-P
8-)
>DN> Работающее решение - это там где (Расход) меньше чем (Доход). Оно на то
>DN> и решение, что есть проблема. А проблемы надо решать. Что приводит к
>DN> новым проблемам (если с головой нормально - новым). Радость в отмечании
>DN> побед на вырученные деньги! 8-)
>Только Расход и Доход нужно считать по _всему_ жизненному циклу, а не до
>момента подписания приемо-сдаточной бумажки.
95% владельцев PC не умеют считать денег? 8-)
TCO сегодня и есть стоимость любого решения.
И мало кто этого не осознает.
<Skip>
>"У вас NT не виснет? Это у вас руки кривые!" :-P
>Если твоя тачка подключена к и-нету, шепни мне ip-адресс и предупреди
>админа, что я буду делать ее security audit. Тогда посмотрим ;-T
Хакер?! О не-е-е-е-ет... 8-Q
Alexander V. Didytch
22 Jul 98 15:15, Andrey V Khavryutchenko wrote to All:
>>>>>> "AVD" == Alexander V Didytch writes:
DN>> И все. Проектирование наследований перед программированием
DN>> позволит немного ускорить реализацию типового поведения в
DN>> сложных, плохо спроектированных интерфейсах.
AVD>> Hу нифигa ceбe нeмнoгo :) Cтaдия прoeктирoвaния увeличивaeтcя
AVD>> нa 25% пo cрaвнeнию co cтруктурнoй. A плoхo cпрoeктирoвaнныe
AVD>> интeрфeйcы тaк этo нaдo рaзличaть лoгичecкую и физичecкую мoдeль
AVD>> и нe лeпить вce вмecтe.
AK> Что один сказал, что другой.
Дa, oпять нe пoняли;) -- 25% увeличeния cтaдии design зa cчeт кoдирoвaния
Ecли пocмoтрeть нa кругoвую диaгрaмму пo рacпрeдeлeнию врeмeни
нa жц тo кoдирoвaниe умeньшaeтcя нa 25% дизaйн увeличивaeтcя:):):)
AK> Проектирование наследований во время кодирования эквивалентно
AK> отсутствию оного.
Koнeчнo.
AK> Отсутствие проектирования^W дизайна приводит к огромной связности
AK> объектов и, как следствие, полной нестабильностью системы.
Hacчeт cвязнocти нe увeрeн (ocoбeннo при рaзрaбoткe в пaрaлeли), нacчeт
нecoглacoвaннocти интeрфeйcoв при oдинaкoвых cигнaтурaх -- дa.
AK> (*) Связность и (не)стабильность здесь не определны. Полагаю, нужно
AK> копать в области теории графов.
He пoмoжeт;) Вce рaвнo прeдмeтную oблacть нaвeшивaть нaдo.
Alexander V. Didytch
22 Jul 98 00:54, Dmitry Nogin wrote to All:
DN> Hу вот есть у тебя в покупной объектной библиотечке на С++ некий
DN> класс. И есть у него метод, который надо переделать. Вот очень
DN> нехорошо будет если он вдруг не виртуальный.
Ээээх. Пocмoтрeл бы ты нa VCL oт Бoрмaндa -- нe дaвaли бы oни
иcхoдникoв oй тяжeлo бы нa нeм чтo-тo дeлaть былo бы. :)
Хoть и нe нe пo _oбьeктнoму_ этo мeнять прeдткa кoтoрoгo caм нe coздaвaл
и нaзнaчeниe и resposibility дo кoнцa (кaк этoгo и нe знaют
в caмoм Бoрмaндe) и нe знaeшь. A шo дeлaть ? :(
Dmitry Nogin
<Skip>
>DN> - суть две большие разницы. Или больше. 8-) И если дизайн интерфейсов
>DN> был успешен - наследование их реализации может и не
>DN> понадобиться. Истина - это Простота. 8-)
>>> Эх-эх-эх... Как определить насколько упешен дизайн интерфейсов до того
>>> как их использовать?
>DN> Брр... Они должны быть простыми! Этож не интерфейсы классов! Этож
>DN> Интерфейсы компонентов. Истина - это Простота. 8-) Ну не хорошо при
>DN> использовании ООП писать тела функций больше 20-25 строк. И только
>DN> благодаря этому мы больше не тратим времени на диаграммы с ветвлениями
>DN> и циклами. "Ан-н-налогично, коллега!" 8-)
>Ну да. И имеем вместо функций по 1000 строк модули по 500 классов.
>Намного проще :-\ <sarcsm implied>
А че? Обслуживать сложно? У тебя из одного coclass'а может торчать штук 5-15
интерфейсов. В каждом по штук 5-15 функций. Это, мягко говоря не рецепт, но
обычно, примерно, как правило, и в среднем выглядит так. Для _очень_
сложных ситуаций. 8-)
А их суют в компоненты. А по живому компонентному телу компилят библиотеки
типа и пользуют их всякими визуальными средствами. Или наоборот. 8-)
Что касается связности - читай ниже.
>DN> А набор критериев это дело формализующий, хм... есть в каждом учебнике.
>ISBN этого каждого учебника?
Дейл Роджерсон. Основы COM. ISBN 5-7502-0033-7
Переведенка. Нужно базовое знание C++. Без специфики Win (Ну почти 8-).
Автор переодически взывает к юниксистам. Одуматься не предлагает. 8-)
Читается - со свистом.
Выписывается по почте с www.book.ru или www.books.ru.
>DN> В компонентной архитектуре наследование не используется для связывания
>DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
>DN> и, как следствие, полной нестабильности системы."
>>> Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
>>> Generalization in UML implies Dependency. Так что связность, и все
>>> проблеммы, связанные с ней ;), никуда не денутся.
>DN> Блин. Теоретик. Читай меня выше еще раз. Или давай просто шепну на
>DN> ушко про эту цитату. ОБРАТНОЕ НЕ ВЕРНО! 8-)
>Нестабильность вызывается сильной _зависимостью_ (dependency). Т.е. когда
>раздавленная в палеозое бабочка меняет исход президентских выборов сейчас.
>Даже хуже, потому что все происходит за момент между внесением изменения и
>коспиляцией/запусков.
Ой. Нестабильность. 8-)
Давай читать вместе.
Сначала меня (обидно - такая корректная формулировка пропадает):
1. Мы говорим о компонентной архитектуре.
2. Наследование не используется для связывания инфраструктуры.
Тезис:
Можно обеспечивать связность иначе чем наследованием. (Вообще
говоря, для этого есть Интерфейсы 8-)
Антитезис:
Это ничего не говорит о возможности избежать связности если
использовать (-таки) наследование хоть для чего-нибудь.
Теперь читаем тебя:
1. Наследование (в UML) приводит к связности (или зависимости).
Итого:
Можно обеспечить связанность иначе чем наследованием. Наследование же
всегда приводит к связанности. Противоречий не найдено.
Прошу учесть мой труд при раздаче бабочек. 8-)
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip>
>> "Качество" системы _меньше_ "качества" самой "некачественной"
>> подсистемы.
DN> Позвольте-ка не согласится. 8-)
DN> КПД тут не причем. И насчет искажения аудио сигнала при проходе по
DN> аудио тракту - тоже. Даже наработка на сбой не причем! Почти. 8-)
DN> Вот наработка на отказ - причем. 8-(
Ну, для начала нужно определить "качество".
Ммм... Затрудняюсь... Это нечто типа throughput'а : определяется самой
медленной частью. Идея ясна?
DN> Судя по отквоченому у тебя идея о существовании идеала, но его что-то
DN> со всех сторон портит. В действительности есть 220V, немного кремния и
DN> куча софта. И все-все что мы имеем, мы имеем благодаря этому добру. У
DN> целом. Закон сохранения энергии <> Закону образования чего-нибудь
DN> полезного.
DN> HiFi не увлекаемся? Обычно вызывает упертость в этом вопросе. 8-)
Нет, не увлекаемся. Даже особо не представляю себе, что это такое.
[...]
DN> Работающее решение - это там где (Расход) меньше чем (Доход). Оно на то
DN> и решение, что есть проблема. А проблемы надо решать. Что приводит к
DN> новым проблемам (если с головой нормально - новым). Радость в отмечании
DN> побед на вырученные деньги! 8-)
>> Только Расход и Доход нужно считать по _всему_ жизненному циклу, а не до
>> момента подписания приемо-сдаточной бумажки.
DN> 95% владельцев PC не умеют считать денег? 8-) TCO сегодня и есть
DN> стоимость любого решения. И мало кто этого не осознает.
Да. 95% владельцев PC считать денег не умеют. А еще больше не умеют
оценивать эффект изменений в своей политике на этом числе.
А тебя что, это сильно удивляет? Правда я не знаю, может быть в USA
считать деньги умеет больше людей, но, судя по моей (не очень длительной)
работе с людьми с восточного побережья, там ситуация не лучше.
>> "У вас NT не виснет? Это у вас руки кривые!" :-P Если твоя тачка
>> подключена к и-нету, шепни мне ip-адресс и предупреди админа, что я буду
>> делать ее security audit. Тогда посмотрим ;-T
DN> Хакер?! О не-е-е-е-ет... 8-Q
Был. Пережил. Скучно это. Может на новый кармический уровень поднимаюсь?
:) (быстро начиная напевать "Харе, Кришна" Ж:-))))
Dmitry Nogin
>>>>>> "DN" == Dmitry Nogin writes:
>DN> Andrey V Khavryutchenko wrote in message ... <Skip>
>>> "Качество" системы _меньше_ "качества" самой "некачественной"
>>> подсистемы.
>DN> Позвольте-ка не согласится. 8-)
>DN> КПД тут не причем. И насчет искажения аудио сигнала при проходе по
>DN> аудио тракту - тоже. Даже наработка на сбой не причем! Почти. 8-)
>DN> Вот наработка на отказ - причем. 8-(
>Ну, для начала нужно определить "качество".
>Ммм... Затрудняюсь... Это нечто типа throughput'а : определяется самой
>медленной частью. Идея ясна?
У нас чего, конвеер? Я, по твоему, просто так про сети Layer с Service
распинался?
И как твоя идей согласуется с примером о конфликте стандартов: VHS/Betamax.
Сам факт существования конфликта сильно снижал качество обоих (с точки
зрения конечного потребителя).
У авоськи, при заведомой хливкости веревочек, структурные решения определяют
большую часть грузопереносимости. 8-)
(Пускаю в ход артиллерию 8-)
Или ты думаешь, что сообразительность твоей головы определяется самым тупым
нейроном? Тогда, как же ты думаешь? 8-)
Не определить тебе слово качество. Это работа маркетологов. 8-)
>DN> Судя по отквоченому у тебя идея о существовании идеала, но его что-то
>DN> со всех сторон портит. В действительности есть 220V, немного кремния и
>DN> куча софта. И все-все что мы имеем, мы имеем благодаря этому добру. У
>DN> целом. Закон сохранения энергии <> Закону образования чего-нибудь
>DN> полезного.
>DN> HiFi не увлекаемся? Обычно вызывает упертость в этом вопросе. 8-)
>Нет, не увлекаемся. Даже особо не представляю себе, что это такое.
Сегодня за пристрастие к музыкальным комплексам с предельно низкими
искажениями по всему тракту чаще называют "ХайЭндщик".
<В ужасе скип про несовершенство человеческой породы и подъем на следующий
кармический уровень 8-) >
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip>
DN> - суть две большие разницы. Или больше. 8-) И если дизайн интерфейсов
DN> был успешен - наследование их реализации может и не
DN> понадобиться. Истина - это Простота. 8-)
>>>> Эх-эх-эх... Как определить насколько упешен дизайн интерфейсов до
>>>> того как их использовать?
DN> Брр... Они должны быть простыми! Этож не интерфейсы классов! Этож
DN> Интерфейсы компонентов. Истина - это Простота. 8-) Ну не хорошо при
DN> использовании ООП писать тела функций больше 20-25 строк. И только
DN> благодаря этому мы больше не тратим времени на диаграммы с ветвлениями
DN> и циклами. "Ан-н-налогично, коллега!" 8-)
>> Ну да. И имеем вместо функций по 1000 строк модули по 500 классов.
>> Намного проще :-\ <sarcsm implied>
DN> А че? Обслуживать сложно? У тебя из одного coclass'а может торчать штук
DN> 5-15 интерфейсов. В каждом по штук 5-15 функций. Это, мягко говоря не
DN> рецепт, но обычно, примерно, как правило, и в среднем выглядит так. Для
DN> _очень_ сложных ситуаций. 8-)
Да, обслуживать сложно. Потому как человеческая думательная мышца может
хранить в кратковременной памяти (=> одновременно оперировать) не больше
7+/-2 объекта. Посему, на каждом уровне сложности должно пристуствовать
именно столько фишечек и рюшечек, а не 500 или 15.
DN> А набор критериев это дело формализующий, хм... есть в каждом учебнике.
>> ISBN этого каждого учебника?
DN> Дейл Роджерсон. Основы COM. ISBN 5-7502-0033-7 Переведенка. Нужно
DN> базовое знание C++. Без специфики Win (Ну почти 8-). Автор
DN> переодически взывает к юниксистам. Одуматься не предлагает. 8-)
DN> Читается - со свистом.
DN> Выписывается по почте с www.book.ru или www.books.ru.
Мимо меня не пробегала. Основную идею, на которой строятся критерии, pls?
DN> В компонентной архитектуре наследование не используется для связывания
DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
DN> и, как следствие, полной нестабильности системы."
>>>> Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
>>>> Generalization in UML implies Dependency. Так что связность, и все
>>>> проблеммы, связанные с ней ;), никуда не денутся.
DN> Блин. Теоретик. Читай меня выше еще раз. Или давай просто шепну на
DN> ушко про эту цитату. ОБРАТНОЕ НЕ ВЕРНО! 8-)
>> Нестабильность вызывается сильной _зависимостью_ (dependency).
>> Т.е. когда раздавленная в палеозое бабочка меняет исход президентских
>> выборов сейчас. Даже хуже, потому что все происходит за момент между
>> внесением изменения и коспиляцией/запусков.
DN> Ой. Нестабильность. 8-) Давай читать вместе.
DN> Сначала меня (обидно - такая корректная формулировка пропадает):
DN> 1. Мы говорим о компонентной архитектуре. 2. Наследование не
DN> используется для связывания инфраструктуры.
DN> Тезис: Можно обеспечивать связность иначе чем наследованием. (Вообще
DN> говоря, для этого есть Интерфейсы 8-)
DN> Антитезис: Это ничего не говорит о возможности избежать связности если
DN> использовать (-таки) наследование хоть для чего-нибудь.
DN> Теперь читаем тебя:
DN> 1. Наследование (в UML) приводит к связности (или зависимости).
DN> Итого: Можно обеспечить связанность иначе чем
DN> наследованием. Наследование же всегда приводит к
DN> связанности. Противоречий не найдено.
DN> Прошу учесть мой труд при раздаче бабочек. 8-)
Ответ отклонен.
Потому как дан на неправильный вопрос. Нужно *минимизировать* связаность
(coupling) в системе для локализации изменений. Связаность определяется
наличием явных и неявных зависимостей между частями систему. *Как*
получаются зависимости: наследованием, включением, делегированием, отдачей
приказа рядовому Иванову -- уже дело десятое.
Dmitry Nogin
<Skip>
>Да, обслуживать сложно. Потому как человеческая думательная мышца может
>хранить в кратковременной памяти (=> одновременно оперировать) не больше
>7+/-2 объекта. Посему, на каждом уровне сложности должно пристуствовать
>именно столько фишечек и рюшечек, а не 500 или 15.
UI надо иметь, а не память. 8-)
А если серьезно, то сложность суть что - рассогласование в предсказаниях и
поведении. А не в объеме исходного материала. Диаграмму состояний знаешь? Ну
которая с переходами-сигналами от одного к другому. Так вот, сложность сидит
в различии поведения одного-единственного члена интерфейса супротив всех
возможных состояний (реализации) интерфейса. Коих (состояний) больше трех
есть совсем нехорошо. Интерфейсов в коклассе может быть... Ну как бы это -
до фига. Важно сколько из них работают совместно - взаимозависимы. Ну и
наконец, количество коклассов. При отсутствии связывания наследованием
реализации - нам пофигу. Важно как они стыкуются в ... ну как это у Буча -
Структуре Объектов.
Черт, тема большая. Не знаю, могу ли я быть понят за один параграф. 8-)
>DN> А набор критериев это дело формализующий, хм... есть в каждом учебнике.
>>> ISBN этого каждого учебника?
>DN> Дейл Роджерсон. Основы COM. ISBN 5-7502-0033-7 Переведенка. Нужно
>DN> базовое знание C++. Без специфики Win (Ну почти 8-). Автор
>DN> переодически взывает к юниксистам. Одуматься не предлагает. 8-)
>DN> Читается - со свистом.
>DN> Выписывается по почте с www.book.ru или www.books.ru.
>Мимо меня не пробегала. Основную идею, на которой строятся критерии, pls?
Слушай, и рад бы. Ну как рассказать об ООП в двух словах?
Они несложные, их мало, но надо понимать как все устроено. Книжка вся 350
страниц, а чтоб говорить по делу будет достаточно первых 200. 8-)
Правильный ответ: "Из того-же материала". 8-)
См. ниже.
>Потому как дан на неправильный вопрос. Нужно *минимизировать* связаность
>(coupling) в системе для локализации изменений. Связаность определяется
>наличием явных и неявных зависимостей между частями систему. *Как*
>получаются зависимости: наследованием, включением, делегированием, отдачей
>приказа рядовому Иванову -- уже дело десятое.
Ты делать что-нибудь собираешся? 8-)
Когда соберешся, тебе для того что бы *минимизировать* надо понять откуда
ноги этого растут. А если с головой, да методой, то лучше не потом
оптимизировать (минимизировать), а сразу лишних связностей не закладывать.
Ну, что можно, конечно. "Есть такой Человек. И Вы его знаете." Интерфейс -
называется. 8-)
У тебя чего написано: Good judgment comes from experience, and a lot of that
comes from bad judgment. Ну так уже! Кое что... 8-)
Dmitry Nogin
<Skip>
Извини. Я кажется перестал понимать термины. 8-)
>Потому как дан на неправильный вопрос. Нужно *минимизировать* связаность
>(coupling) в системе для локализации изменений. Связаность определяется
>наличием явных и неявных зависимостей между частями систему. *Как*
>получаются зависимости: наследованием, включением, делегированием, отдачей
>приказа рядовому Иванову -- уже дело десятое.
Coupling is an indication of the strength of the interconnections and
interactions exhibited by different program components.
Тогда я должен звучать так:
В компонентной архитектуре наследование (реализации) не используется для
interconnections and interactions.
Интерфейсно-базированные interconnections and interactions несут с собой
сильно меньше dependencies.
На то и интерфейсы.
Смысл в чем?
Pure ООП:
Есть class кнопка (CButton), есть class диалоговое окошко (CDialog). Есть
class предок всего могущего лежать на окне (CControl).
Разумно и полезно базовую логику перерисовки под фокусом и без, возможность
оный (фокус) принять, ну и многочисленное прочее разместить в где? В
CControl. Все очень virtual. Ну и пусть CControl взаимодействует с CDialog.
Компонентное решение с интерфейсами:
Есть coclass CoDialog поддерживающий IDialog. Есть coclass CoButton
поддерживающий IControl. Есть класс CControl - одна из возможных дефолтных
реализаций IControl и который мы попользуем в реализации CoButton.
В последнем interconnections and interactions между Button и Dialog
реализуется с меньшими Dependencies. Почему? Да потому как CControl можно
наследовать под каждого потребителя (CoButton->CoColorButton->...), как бы
они друг из друга не росли. Да и сам (CControl) может быть проще.
Уф-ф-ф.
Dmitry Nogin
> DN> Hу вот есть у тебя в покупной объектной библиотечке на С++ некий
> DN> класс. И есть у него метод, который надо переделать. Вот очень
> DN> нехорошо будет если он вдруг не виртуальный.
> Ээээх. Пocмoтрeл бы ты нa VCL oт Бoрмaндa -- нe дaвaли бы oни
> иcхoдникoв oй тяжeлo бы нa нeм чтo-тo дeлaть былo бы. :)
> Хoть и нe нe пo _oбьeктнoму_ этo мeнять прeдткa кoтoрoгo caм нe coздaвaл
> и нaзнaчeниe и resposibility дo кoнцa (кaк этoгo и нe знaют
> в caмoм Бoрмaндe) и нe знaeшь. A шo дeлaть ? :(
Я смотрел. 2 года. Половину сорцов вызубрил. Потом тихонечко взвыл и ушел на
MS. Лепота... 8-)
А как он там сейчас? По сравнению с 2.0. Редактор TWinControl'ов по типу
форм еще не сделали?
P.S. Исходники они давали только с клиент/сервером. 8-)
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip>
>> Да, обслуживать сложно. Потому как человеческая думательная мышца может
>> хранить в кратковременной памяти (=> одновременно оперировать) не больше
>> 7+/-2 объекта. Посему, на каждом уровне сложности должно пристуствовать
>> именно столько фишечек и рюшечек, а не 500 или 15.
DN> UI надо иметь, а не память. 8-)
Microsoft я узнаю по картинкам. :-\
Тоже мне, UI driven mindset... Плохо это. Учиться надо абстрактно мыслить,
а не картинками.
DN> А если серьезно, то сложность суть что - рассогласование в
DN> предсказаниях и поведении. А не в объеме исходного материала. Диаграмму
DN> состояний знаешь? Ну которая с переходами-сигналами от одного к
DN> другому. Так вот, сложность сидит в различии поведения
DN> одного-единственного члена интерфейса супротив всех возможных состояний
DN> (реализации) интерфейса. Коих (состояний) больше трех есть совсем
DN> нехорошо. Интерфейсов в коклассе может быть... Ну как бы это - до
DN> фига. Важно сколько из них работают совместно - взаимозависимы. Ну и
DN> наконец, количество коклассов. При отсутствии связывания наследованием
DN> реализации - нам пофигу. Важно как они стыкуются в ... ну как это у
DN> Буча - Структуре Объектов.
DN> Черт, тема большая. Не знаю, могу ли я быть понят за один параграф. 8-)
Не, не понят. Мы с тобой дошли то точки, когда проявляется различие в
фундаментальном понимании. Поэтому предлагаю считать вопрос
"Сложно ли поддерживать модуль с 500 классами? Почему?"
тем вопросом, на который ищется ответ.
Прошу тебя разжевать твой абзац по словам начиная с начала: рассогласование
в предсказаниях (поведения?) и (реальном?) поведении (чего?).
DN> А набор критериев это дело формализующий, хм... есть в каждом учебнике.
>>>> ISBN этого каждого учебника?
DN> Дейл Роджерсон. Основы COM. ISBN 5-7502-0033-7 Переведенка. Нужно
DN> базовое знание C++. Без специфики Win (Ну почти 8-). Автор
DN> переодически взывает к юниксистам. Одуматься не предлагает. 8-)
DN> Читается - со свистом. Выписывается по почте с www.book.ru или
DN> www.books.ru.
>> Мимо меня не пробегала. Основную идею, на которой строятся критерии,
>> pls?
DN> Слушай, и рад бы. Ну как рассказать об ООП в двух словах? Они
DN> несложные, их мало, но надо понимать как все устроено. Книжка вся 350
DN> страниц, а чтоб говорить по делу будет достаточно первых 200. 8-)
В двух словах? Элементарно, Ватсон: "Есть объекты!" Ровно два слова. :)
Ты же видел мой reading list, так что понимаешь, что, для того, чтобы я
тебя понял, тебе нужно либо подождать три месяца, либо объяснить свою точку
зрения в эхе.
DN> В компонентной архитектуре наследование не используется для связывания
DN> инфраструктуры. Поэтому и не "приводит к огромной связности объектов
DN> и, как следствие, полной нестабильности системы."
>>>>> Ага... Это кому-нибуть другому рассказывайте. Inheritance AKA
>>>>> Generalization in UML implies Dependency. Так что связность, и все
>>>>> проблеммы, связанные с ней ;), никуда не денутся.
DN> Блин. Теоретик. Читай меня выше еще раз. Или давай просто шепну на
DN> ушко про эту цитату. ОБРАТНОЕ НЕ ВЕРНО! 8-)
>>>> Нестабильность вызывается сильной _зависимостью_ (dependency).
>>>> Т.е. когда раздавленная в палеозое бабочка меняет исход президентских
>>>> выборов сейчас. Даже хуже, потому что все происходит за момент между
>>>> внесением изменения и коспиляцией/запусков.
DN> Ой. Нестабильность. 8-) Давай читать вместе. Сначала меня (обидно -
DN> такая корректная формулировка пропадает): 1. Мы говорим о компонентной
DN> архитектуре. 2. Наследование не используется для связывания
DN> инфраструктуры. Тезис: Можно обеспечивать связность иначе чем
DN> наследованием. (Вообще говоря, для этого есть Интерфейсы 8-) Антитезис:
DN> Это ничего не говорит о возможности избежать связности если
DN> использовать (-таки) наследование хоть для чего-нибудь. Теперь читаем
DN> тебя: 1. Наследование (в UML) приводит к связности (или зависимости).
DN> Итого: Можно обеспечить связанность иначе чем
DN> наследованием. Наследование же всегда приводит к
DN> связанности. Противоречий не найдено. Прошу учесть мой труд при
DN> раздаче бабочек. 8-)
>> Ответ отклонен.
DN> Правильный ответ: "Из того-же материала". 8-) См. ниже.
>> Потому как дан на неправильный вопрос. Нужно *минимизировать*
>> связаность (coupling) в системе для локализации изменений. Связаность
>> определяется наличием явных и неявных зависимостей между частями
>> систему. *Как* получаются зависимости: наследованием, включением,
>> делегированием, отдачей приказа рядовому Иванову -- уже дело десятое.
DN> Ты делать что-нибудь собираешся? 8-) Когда соберешся, тебе для того что
DN> бы *минимизировать* надо понять откуда ноги этого растут. А если с
DN> головой, да методой, то лучше не потом оптимизировать (минимизировать),
DN> а сразу лишних связностей не закладывать. Ну, что можно,
DN> конечно. "Есть такой Человек. И Вы его знаете." Интерфейс -
DN> называется. 8-)
Да, вот, не закладываем лишних свызностей, а потом за голову зватаемся,
т.к. получаем вместо кластеризующейся сети с двумя-тремя уровнями
наследования, примерно гомогенную сеть объектов, в которой не знаешь за
какой объект нужно потянуть, чтобы не дай бог не утащить всю сеть в
ненужном направлении.
Мораль: после того, как нарисовал sequence diagram и выделил оттуда те
классы, которые тебе нужны, сядь спокойно и подумай, что в них общего, а
что разного, как можно свести граф зависимостей к дереву, ... Короче,
минимизируй зависимости до кодирования, а не после сдачи продукта.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Good judgment comes from experience, and a lot of that comes from
bad judgment.
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ... <Skip>
DN> Извини. Я кажется перестал понимать термины. 8-)
>> Потому как дан на неправильный вопрос. Нужно *минимизировать*
>> связаность (coupling) в системе для локализации изменений. Связаность
>> определяется наличием явных и неявных зависимостей между частями
>> систему. *Как* получаются зависимости: наследованием, включением,
>> делегированием, отдачей приказа рядовому Иванову -- уже дело десятое.
DN> Coupling is an indication of the strength of the interconnections and
DN> interactions exhibited by different program components.
DN> Тогда я должен звучать так:
DN> В компонентной архитектуре наследование (реализации) не используется
^^^^^^^^^^^^^^^^^^^^^^
О! Появилась более осмысленная терминология :)
DN> для interconnections and interactions.
DN> Интерфейсно-базированные interconnections and interactions несут с
DN> собой сильно меньше dependencies. На то и интерфейсы.
Да.
DN> Смысл в чем?
DN> Pure ООП: Есть class кнопка (CButton), есть class диалоговое окошко
DN> (CDialog). Есть class предок всего могущего лежать на окне (CControl).
DN> Разумно и полезно базовую логику перерисовки под фокусом и без,
DN> возможность оный (фокус) принять, ну и многочисленное прочее разместить
DN> в где? В CControl. Все очень virtual. Ну и пусть CControl
DN> взаимодействует с CDialog.
Нуу.... Как бы это повежливе сказать... Это не совсем "Pure OOP". Это его
(ООП) кривое использование в языках со строгой типизацией (где нужно в
явном виде задавать интерфейсы). Кривизна состоит в том, что используются
идиомы из языков со слабой типизацией, где интерфейсы в явном виде не
задаются.
DN> Компонентное решение с интерфейсами: Есть coclass CoDialog
DN> поддерживающий IDialog. Есть coclass CoButton поддерживающий
DN> IControl. Есть класс CControl - одна из возможных дефолтных реализаций
DN> IControl и который мы попользуем в реализации CoButton.
О! Если выбросить враждебную правильным программистам терминологию ;-P ,
то все путем. Есть интерфейс IDialog, есть интерфейс IControl. Они
связаны зависомостью один-ко-многим. Вдоль этой зависимости бегают тучи
сообщений с неинтересным, на данный момент, протоколом. Есть реализация
интефейса IDialog: CDialog. Есть реализация интерфейса IControl: CControl
и CoButton. CoButton делегирует часть сфоей функциональности классу
CControl, реализуя, таким образом, наследование реализации.
DN> В последнем interconnections and interactions между Button и Dialog
DN> реализуется с меньшими Dependencies. Почему? Да потому как CControl
DN> можно наследовать под каждого потребителя
DN> (CoButton->CoColorButton->...), как бы они друг из друга не росли. Да и
DN> сам (CControl) может быть проще.
Agreed.
DN> Уф-ф-ф.
И почему это люди, будучи такими разными все-таки ухитряются понимать друг
друга?
Dmitry Nogin
>И почему это люди, будучи такими разными все-таки ухитряются понимать друг
>друга?
Стараются. Это важней, чем быть разными. 8-)
К тому же, если жить реальностью - шансы возрастают. 8-)
Dmitry Nogin
>>> хранить в кратковременной памяти (=> одновременно оперировать) не больше
>>> 7+/-2 объекта. Посему, на каждом уровне сложности должно пристуствовать
>>> именно столько фишечек и рюшечек, а не 500 или 15.
>DN> UI надо иметь, а не память. 8-)
>Microsoft я узнаю по картинкам. :-\
>Тоже мне, UI driven mindset... Плохо это. Учиться надо абстрактно мыслить,
>а не картинками.
>Hе, не понят. Мы с тобой дошли то точки, когда проявляется различие в
>фундаментальном понимании. Поэтому предлагаю считать вопрос
> "Сложно ли поддерживать модуль с 500 классами? Почему?"
>тем вопросом, на который ищется ответ.
ЧАСТЬ ПЕРВАЯ. О СЛОЖНОСТИ.
Как выглядит процесс отображения реальности в программное решение? Как
построение стопки моделей. Соответственно, как мы уже выяснили:
* Роли пользователей и Пользовательские сценарии
или
UML Actors and Use-cases
* Бизнес-объекты и Сервисы
или
Analytic model
* Компоненты и Интерфейсы
или
В зависимости от требуемой детализации либо
Analytic model #2, либо Design model.
* И так далее, в том числе и вверх...
Термин "Сложность" применим к каждой из моделей. И оговаривает ее отношение
к модели(ям) верхнего уровня.
Естественно, что каждый (очередной) слой, при всем нашем старании, выглядит
как попытка заставить говорить жалкое подобие тени призрака отца Гамлета.
Будем реалистами. 8-)
И исходя из этого невнятно вопиющего несовершенства, имеет смысл
определение: "Сложность - это рассогласование между прогнозируемыми и
реальными процессами взаимной адаптации компонентов системы". Определение не
мое (но любимое) и не из нашей индустрии, поэтому давайте разберем термины.
* "Реальными процессами" для нас будет (тестирующее)
функционирование модели(ей) верхнего уровня.
* "Прогнозируемыми процессами" для нас будет
функционирование измеряемой модели.
Если мы пали так низко, что уже написали код -
это функционирование становится особо наглядным. 8-)
* "Взаимная адаптация" - Смена структур и состояний
в ответ на воздействия (сигналы). (Типа: Создать экземпляр
сущности, убить экземпляр сущности. Модифицировать
состояние сущности. И т.п.)
* "Компоненты системы" - Сущности измеряемой модели.
Пример:
Пусть у нас есть компонент (контрол) - Кнопка. Модель(и) верхнего к ней
уровня (МВУ) будет(ут) ее описывать как имеющую Начертание_Шрифта и
Размер_Шрифта. С точки зрения МВУ эти атрибуты не связаны и их изменения не
должны влиять друг на друга. С практической точки зрения, при малых
значениях Размер_Шрифта и ограниченной разрешающей способности растерного
устойства отображения приходится менять векторное Начертание_Шрифта на кучку
"префабрикейтед" битовых картинок. Иначе не читабельно, как предыдущее
предложение. 8-) Но это еще не привносит в нашу систему "Сложность"! Если
Кнопка будет рапортовать через считывание атрибута о том что использует
заказанный "Arial", а сама отрисует что нужно - все хорошо. Если Кнопка
проявит неуместную честность и при изменении Размер_Шрифта будет переключать
публично доступное значение атрибута Начертание_Шрифта - о! Вот это и есть
Сложность! Она, подлая, играет не по правилам МВУ! Точнее, не так как мы
могли бы _предсказать_ на основании "Реальных процессов".
Золотой принцип дизайна пропертей у компонента. Изменения их значений не
должны быть взаимозависимы. Это позволяет избежать Сложности. И пока принцип
блюдут - все проперти самоописательны своим названием. Их можно
рассматривать поотдельности. А насчет общего их количества... Так делаем
красивый UI с удобной сортировкой, поиском в Библиотеке Типов по первым
буквам при написании кода в редакторе и вперед. Хоть пятьдесят, хоть сто.
Что я хочу этим сказать? Что нужно и "абстрактно мыслить" для разложения
сложности в объем и "UI driven mindset" для преодоления полученного объема.
Истина - это Простота. Плохо то, что ее много. 8-)
ЧАСТЬ ВТОРАЯ. COM: СЛОЖНОСТЬ И КОЛИЧЕСТВО.
Из чего сделаны мальчишки? Тьфу... COM?
Service
coclass
interface
method & property (что суть тот же method)
Сложность Service'ов складывается из зависимости экземпляров сущностей
модели (экземпляров coclass'ов из поддерживающих Layer'ов) друг на друга, а
не их количества.
Сложность coclass'а определяется зависимостью его интерфейсов друг от друга
(чаще всего бывает несколько пучков), а не их количества.
Сложность интерфейса определяется количеством состояний, при которых его
методы ведут себя по разному. (Пусть у нас есть интерфейс IFile. Он может
быть открыт в режиме WO, RO, R/W и ... закрыт. Соответственно, мы должны
рассматривая каждый из методов интерфейса держать в голове поведение оного
(метода) в каждом из таких состояний.) Количество методов нас волнует не
очень. Главное - кол-во состояний.
Сложность метода - не в нем самом. (Если не считать аргументов. 8-)
Его сложность сокрыта много незатейливей Кощеевой смерти. Не так запрятана.
Точней, вообще не запрятана. Ее суть - другие методы. Сколько их нужно
вызвать до него, и сколько - после. Для получения чего-нибудь полезного для
МВУ. См. про сложность интерфейсов.
ЧАСТЬ ТРЕТЬЯ. ЛИРИЧЕСКОЕ ЗАКЛЮЧЕНИЕ.
Наука и технология методически не схожи. Попытка представить себе слона с
помощью изучения таблички мягкости, цвета, жесткости и упругости частей его
тела - не способно вызвать того чувства здоровой зависти у обоих полов, что
наблюдается при посещении зоопарка. 8-)
Good judgment comes from experience, and a lot of that comes from bad
judgment. Это правильно. Но только часть картины. Тут три этапа и на
каждом - своя стратегия:
* Ученик - узнать понятия, методики технологии.
* Воин - Выявить в драке слабые места.
* Мудрец - Научиться их кардинально защищать. Не вступая в драку. 8-)
Но вот в чем особенность... Этот цикл в нашей индустрии длится не более 5-10
лет - до следующего качественного скачка. Так что желающим выжить -
предлагается заиметь психологическую гибкость. 8-)
P.S. Э... Я правильно понят насчет намека об необходимости изучения
пары-тройки индустриальных (т.е. с корректно разложенной сложностью)
технологий? После завершения этапа Мудреца по части ООП. 8-)
Andrey V Khavryutchenko
DN> ЧАСТЬ ПЕРВАЯ. О СЛОЖНОСТИ.
DN> Как выглядит процесс отображения реальности в программное решение? Как
DN> построение стопки моделей. Соответственно, как мы уже выяснили:
Note: лишь один из возможных процессов.
DN> * Роли пользователей и Пользовательские сценарии или UML Actors and
DN> Use-cases
DN> * Бизнес-объекты и Сервисы или Analytic model
DN> * Компоненты и Интерфейсы или В зависимости от требуемой детализации
DN> либо Analytic model #2, либо Design model.
DN> * И так далее, в том числе и вверх...
DN> Термин "Сложность" применим к каждой из моделей. И оговаривает ее
DN> отношение к модели(ям) верхнего уровня.
DN> Естественно, что каждый (очередной) слой, при всем нашем старании,
DN> выглядит как попытка заставить говорить жалкое подобие тени призрака
DN> отца Гамлета. Будем реалистами. 8-)
DN> И исходя из этого невнятно вопиющего несовершенства, имеет смысл
DN> определение: "Сложность - это рассогласование между прогнозируемыми и
DN> реальными процессами взаимной адаптации компонентов
DN> системы". Определение не мое (но любимое) и не из нашей индустрии,
DN> поэтому давайте разберем термины.
Мне это определение не нравится. Я предпочитаю считать сложность свойством
самой модели безо всякой ее связи с моделями верхнего или нижнего уровня.
А из какой индустрии Ваше определение?
DN> * "Реальными процессами" для нас будет (тестирующее) функционирование
DN> модели(ей) верхнего уровня.
DN> * "Прогнозируемыми процессами" для нас будет функционирование
DN> измеряемой модели. Если мы пали так низко, что уже написали код - это
DN> функционирование становится особо наглядным. 8-)
DN> * "Взаимная адаптация" - Смена структур и состояний в ответ на
DN> воздействия (сигналы). (Типа: Создать экземпляр сущности, убить
DN> экземпляр сущности. Модифицировать состояние сущности. И т.п.)
DN> * "Компоненты системы" - Сущности измеряемой модели.
[...]
DN> Золотой принцип дизайна пропертей у компонента. Изменения их значений
DN> не должны быть взаимозависимы. Это позволяет избежать Сложности.
О! Так сложность таки определяется количеством взаимозависимостей. Так?
DN> И пока
DN> принцип блюдут - все проперти самоописательны своим названием. Их можно
DN> рассматривать поотдельности. А насчет общего их количества... Так
DN> делаем красивый UI с удобной сортировкой, поиском в Библиотеке Типов по
DN> первым буквам при написании кода в редакторе и вперед. Хоть пятьдесят,
DN> хоть сто.
Нет, неправильно. Потому что прячете сложность в название. Как насчет
того, чтобы иметь 100 пропертей, поименованых последовательно от 0 до 99?
Не, сделаем лучше. :-] Придумайте хотя бы 20 синонимов слову шрифт :-]]]
// Или рифму к слову "пакля" ;)
DN> Что я хочу этим сказать? Что нужно и "абстрактно мыслить" для
DN> разложения сложности в объем и "UI driven mindset" для преодоления
DN> полученного объема. Истина - это Простота. Плохо то, что ее много. 8-)
Nope. Или угу :) Самое хорошее в стандартах -- это их количество: можно
выбирать, который тебе больше нравитсяю :\
DN> ЧАСТЬ ВТОРАЯ. COM: СЛОЖНОСТЬ И КОЛИЧЕСТВО.
DN> Из чего сделаны мальчишки? Тьфу... COM?
DN> Service coclass interface method & property (что суть тот же
DN> method)
DN> Сложность Service'ов складывается из зависимости экземпляров сущностей
DN> модели (экземпляров coclass'ов из поддерживающих Layer'ов) друг на
DN> друга, а не их количества.
Сложность ---> зависимости
DN> Сложность coclass'а определяется зависимостью его интерфейсов друг от
DN> друга (чаще всего бывает несколько пучков), а не их количества.
Сложность ---> зависимости
DN> Сложность интерфейса определяется количеством состояний, при которых
DN> его методы ведут себя по разному. (Пусть у нас есть интерфейс IFile. Он
DN> может быть открыт в режиме WO, RO, R/W и ... закрыт. Соответственно, мы
DN> должны рассматривая каждый из методов интерфейса держать в голове
DN> поведение оного (метода) в каждом из таких состояний.) Количество
DN> методов нас волнует не очень. Главное - кол-во состояний.
Сложность ---> зависимости между состояниями
DN> Сложность метода - не в нем самом. (Если не считать аргументов. 8-) Его
DN> сложность сокрыта много незатейливей Кощеевой смерти. Не так запрятана.
DN> Точней, вообще не запрятана. Ее суть - другие методы. Сколько их нужно
DN> вызвать до него, и сколько - после. Для получения чего-нибудь полезного
DN> для МВУ. См. про сложность интерфейсов.
См. выше :)
Итого:
1 Вы сами сказали, что сложность определяется зависимостями.
2 Наша цель -- бороться со сложностью.
3 Нельзя бороться с тем, чего не знаешь
4 Нужно определить сложность измеряемой величиной (лучше всего -- числом)
5 Зависимости между артефактами можно легко отобразить на направленном
графе, теория которых достаточно хорошо разработана.
6 (и последний) Нужно взять такую характеристику направленного графа,
которая хорошо бы коррелировала с субъективной сложностью, которая
определяется количеством зависимостей между узлами.
Any takers?
DN> ЧАСТЬ ТРЕТЬЯ. ЛИРИЧЕСКОЕ ЗАКЛЮЧЕНИЕ.
DN> Наука и технология методически не схожи. Попытка представить себе слона
DN> с помощью изучения таблички мягкости, цвета, жесткости и упругости
DN> частей его тела - не способно вызвать того чувства здоровой зависти у
DN> обоих полов, что наблюдается при посещении зоопарка. 8-)
Не то изучали :)
DN> Good judgment comes from experience, and a lot of that comes from bad
DN> judgment. Это правильно. Но только часть картины. Тут три этапа и на
DN> каждом - своя стратегия: * Ученик - узнать понятия, методики
DN> технологии. * Воин - Выявить в драке слабые места. * Мудрец -
DN> Научиться их кардинально защищать. Не вступая в драку. 8-) Но вот в чем
DN> особенность... Этот цикл в нашей индустрии длится не более 5-10 лет -
DN> до следующего качественного скачка. Так что желающим выжить -
DN> предлагается заиметь психологическую гибкость. 8-)
DN> P.S. Э... Я правильно понят насчет намека об необходимости изучения
DN> пары-тройки индустриальных (т.е. с корректно разложенной сложностью)
DN> технологий? После завершения этапа Мудреца по части ООП. 8-)
Нет, не понят. Тем более относительно индустриальных технологий с
"корректно разложеной сложностью". Это не про COM часом? ;)
Давайте уж сначала со сложностью разберемся, а потом уже возьмемся и за ее
"корректное разложение".
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Good judgment comes from experience, and a lot of that comes from
bad judgment.
Dmitry Nogin
>DN> ЧАСТЬ ПЕРВАЯ. О СЛОЖНОСТИ.
>DN> Как выглядит процесс отображения реальности в программное решение? Как
>DN> построение стопки моделей. Соответственно, как мы уже выяснили:
>Note: лишь один из возможных процессов.
Не люблю Достоевского, но процитирую. "... все на земле живет через
таинственное касание миром иным". 8-)
>DN> * Роли пользователей и Пользовательские сценарии или UML Actors and
>DN> Use-cases
>DN> * Бизнес-объекты и Сервисы или Analytic model
>DN> * Компоненты и Интерфейсы или В зависимости от требуемой детализации
>DN> либо Analytic model #2, либо Design model.
>DN> * И так далее, в том числе и вверх...
>DN> Термин "Сложность" применим к каждой из моделей. И оговаривает ее
>DN> отношение к модели(ям) верхнего уровня.
>DN> Естественно, что каждый (очередной) слой, при всем нашем старании,
>DN> выглядит как попытка заставить говорить жалкое подобие тени призрака
>DN> отца Гамлета. Будем реалистами. 8-)
>DN> И исходя из этого невнятно вопиющего несовершенства, имеет смысл
>DN> определение: "Сложность - это рассогласование между прогнозируемыми и
>DN> реальными процессами взаимной адаптации компонентов
>DN> системы". Определение не мое (но любимое) и не из нашей индустрии,
>DN> поэтому давайте разберем термины.
>Мне это определение не нравится. Я предпочитаю считать сложность свойством
>самой модели безо всякой ее связи с моделями верхнего или нижнего уровня.
Ага. "Вещь в себе" знаешь как в оригинале звучала? "Вещь для себя". 8-)
Внутри модели мы не найдем ничего, что могло бы выступить в качестве
реального критерия ее соответствия потребностям Провидения. 8-) Не выходя за
ее рамки мы можем оценить (относительно) э... консистентность (целостность),
эффективность, и пр... У любой модели есть свои внутренние цели. И
внутримодельная сложность, как у меня и описано во второй части, фактически
означает дополнительное внутримодельное субмодельное расслоение. 8-) Этакий
институт помазанников Божьих на земле. 8-)
Вот в MSF люди сразу понимают, что такое сложность. Печенкой. Ибо за каждую
модель отвечает своя роль (отдельный человек). И пока они свои виденья
согласуют, про сложность и простоту все-все поймут. 8-)
Ладно, займемся лирикой. 8-)
Вот, например, историю с Олегом помнишь? Вещий который. Был злобно закусан
змеюкой из черепа. Так вот раскладывая ситуацию на модели, мы можем сказать,
что по части МВУ в этом рассказе у нас Судьба, а на ролях в измеряемой
модели - Олег, Лошадь, Соратники, ... , Привычка Накладывать Лапу...
Сложность в этой ситуации и составляет всю соль повествования. Если бы не
было невозможного (прорыва МВУ в виде предсказания), то про что тут было бы
говорить? Мы бы просто не поняли, что тут есть о чем говорить. 8-)
Все-все цели МВУ либо самомотивируемы (объяснимы) в измеряемой модели
(замучился писать - назовем это дело ИМ), либо просто в ней отсутствуют -
это, видимо, очевидно. Но это не означает, что модели находятся в отношениях
иерархической подчиненности. К примеру, написанный однажды код (программная
модель), может с легкостью пережить свою бизнес-модель. Если, по большой
части, оперировал понятиями горизонтальных (а не вертикальных!) прикладных
словарей. Скажем, тот же e-mail или Internet. Вывод: чем меньше молиться
Богам, тем больше вероятность стать одним из них. 8-)
Ну как еще поуговаривать... Давай так. Под термином сложность мы будем
понимать ответ (в недискретной логике) на вопрос: "Насколько Провидению
угодно происходящее". 8-)
>А из какой индустрии Ваше определение?
ЧМС. Человеко-машинные системы или Гибридный Интеллект. А если точней, то
Математики о Жизни. 8-)
<Skip>
>DN> Золотой принцип дизайна пропертей у компонента. Изменения их значений
>DN> не должны быть взаимозависимы. Это позволяет избежать Сложности.
>О! Так сложность таки определяется количеством взаимозависимостей. Так?
В том числе. Сложность - это насколько были обмануты ожидания МВУ.
Зависимости ИМ, которые не входили в МВУ - повышают сложность. Зависимости
МВУ, которые не входят в ИМ - тоже.
Скажем, МВУ требует послать e-mail. Если ИМ (API) не mail-enabled, то
рассогласование черезвычайно велико. Если ИМ имеет функцию высокого уровня
для отправки письма за один вызов - Это Сделать Не Сложно. 8-)
Если ИМ предоставляет только низкоуровневую россыпь функций для почтовых
дел, то откликнуться на требования МВУ (заказчика) сложно. Явно надо
устраивать субмодельное расслоение: MAPI и CDO. 8-)
>DN> И пока
>DN> принцип блюдут - все проперти самоописательны своим названием. Их можно
>DN> рассматривать поотдельности. А насчет общего их количества... Так
>DN> делаем красивый UI с удобной сортировкой, поиском в Библиотеке Типов по
>DN> первым буквам при написании кода в редакторе и вперед. Хоть пятьдесят,
>DN> хоть сто.
>Нет, неправильно. Потому что прячете сложность в название. Как насчет
>того, чтобы иметь 100 пропертей, поименованых последовательно от 0 до 99?
>Не, сделаем лучше. :-] Придумайте хотя бы 20 синонимов слову шрифт :-]]]
>// Или рифму к слову "пакля" ;)
Хм... Какие бы разные модели не были, они должны иметь некую общую
(субмодельную) культуру. Например, английский. 8-)
Вот мне (МВУ) надо отправить письмо. Я открываю смотрелку библиотек типов и
ищу что? SendMail или типа того. Так что, правильно, прячу в название. А чеж
ей, гордиться чтоль? 8-)
А придумывать синонимы - это знаете, не правильно. Контекст надо
чувствовать, структуру корректную заводить. Вот и не будет длинных списков.
Будут древовидные namespaces. Объем мы тоже раскладываем. Через UI. Как
сложность. 8-)
>DN> Что я хочу этим сказать? Что нужно и "абстрактно мыслить" для
>DN> разложения сложности в объем и "UI driven mindset" для преодоления
>DN> полученного объема. Истина - это Простота. Плохо то, что ее много. 8-)
>Nope. Или угу :) Самое хорошее в стандартах -- это их количество: можно
>выбирать, который тебе больше нравитсяю :\
Самое хорошое в стандартах - это совместимость. А выбирает МВУ. Рынок. 8-)
<Skip>
>Итого:
>1 Вы сами сказали, что сложность определяется зависимостями.
Зависимости - внутримодельны.
Сложность - межмодельна и определяется рассогласованием, в том числе и
зависимостей.
>2 Наша цель -- бороться со сложностью.
Наша цель, дать МВУ именно то, чего она, исходя из своих представлений, от
нас ожидает. ОК.
"Рады! Ли! Вы! О! Боги!" 8-)
>3 Нельзя бороться с тем, чего не знаешь
Хм. Уже кажется цитировал. "К неизвестному нет стремления" (с) Овидий.
А вот бороться можно. Либо недеянием или просто кого-нибудь нанять и
поставить общую цель. 8-)
А знание сложности, хм... это такая однонаправленная вещь. Только от МВУ и
вниз. 8-)
Да, я помню, что говорил об отсутствии четкой иерархии моделей. Потому и
сложности разные. Смотря как выбрать МВУ и ИМ. То что нужно программной
модели (тут МВУ) - скажем, стабильность бизнес логики - оборачивается
сложностью для бизнеса (ИМ) ...
>4 Нужно определить сложность измеряемой величиной (лучше всего -- числом)
Q + C = 1
Q - эффективность (0..1)
C - сложность (0..1)
И чего? 8-)
>5 Зависимости между артефактами можно легко отобразить на направленном
>графе, теория которых достаточно хорошо разработана.
>6 (и последний) Нужно взять такую характеристику направленного графа,
>которая хорошо бы коррелировала с субъективной сложностью, которая
>определяется количеством зависимостей между узлами.
У... Если бы определялась...
Модели, на то и модели - что считают их отдельно. 8-)
На сегодня тут чистая эмпирика, ролевые игры и искусство оглядывать
окрестность.
Мягко говоря, бессмыслено изучать науку которой еще нет. Эффективней всего
построится в боевые порядки (COM+MSF) и вперед. Пока мы тут на этапе Воина.
8-)
<Skip>
Andrey V Khavryutchenko
DN> Andrey V Khavryutchenko wrote in message ...
DN> Термин "Сложность" применим к каждой из моделей. И оговаривает ее
DN> отношение к модели(ям) верхнего уровня. Естественно, что каждый
DN> (очередной) слой, при всем нашем старании, выглядит как попытка
DN> заставить говорить жалкое подобие тени призрака отца Гамлета. Будем
DN> реалистами. 8-) И исходя из этого невнятно вопиющего несовершенства,
DN> имеет смысл определение: "Сложность - это рассогласование между
DN> прогнозируемыми и реальными процессами взаимной адаптации компонентов
DN> системы". Определение не мое (но любимое) и не из нашей индустрии,
DN> поэтому давайте разберем термины.
>> Мне это определение не нравится. Я предпочитаю считать сложность
>> свойством самой модели безо всякой ее связи с моделями верхнего или
>> нижнего уровня.
DN> Ага. "Вещь в себе" знаешь как в оригинале звучала? "Вещь для
DN> себя". 8-) Внутри модели мы не найдем ничего, что могло бы выступить в
DN> качестве реального критерия ее соответствия потребностям
DN> Провидения. 8-) Не выходя за ее рамки мы можем оценить (относительно)
DN> э... консистентность (целостность), эффективность, и пр...
А это совершенно другие показатели. Меня интересует "сложность" с точки
зрения стоимости поддержки.
DN> У любой модели есть свои внутренние цели. И внутримодельная сложность,
DN> как у меня и описано во второй части, фактически означает
DN> дополнительное внутримодельное субмодельное расслоение. 8-) Этакий
DN> институт помазанников Божьих на земле. 8-)
Ну, давайте расслоим модель до уровня отдельных элементов. Какова
сложность.
DN> Вот в MSF люди сразу понимают, что такое сложность. Печенкой. Ибо за
DN> каждую модель отвечает своя роль (отдельный человек). И пока они свои
DN> виденья согласуют, про сложность и простоту все-все поймут. 8-)
Гам.. (это я зеваю). Все Ваши попытки включить у меня dumb mode с
негодованием отвергаются :) Будте любезны, милостивый государь, пояснять
свои мысли без ссылок на M$, печенку и прочие части человеческого тела, так
же как и человека в целом. :)
DN> Ладно, займемся лирикой. 8-)
DN> Вот, например, историю с Олегом помнишь? Вещий который. Был злобно
DN> закусан змеюкой из черепа. Так вот раскладывая ситуацию на модели, мы
DN> можем сказать, что по части МВУ в этом рассказе у нас Судьба, а на
DN> ролях в измеряемой модели - Олег, Лошадь, Соратники, ... , Привычка
DN> Накладывать Лапу... Сложность в этой ситуации и составляет всю соль
DN> повествования. Если бы не было невозможного (прорыва МВУ в виде
DN> предсказания), то про что тут было бы говорить? Мы бы просто не
DN> поняли, что тут есть о чем говорить. 8-)
Чего-то вы не туда заехали. Попроще что-либо можно? А то сейчас начнем
сравнивать описания этого события в летописях, у русских классиков и у
Высоцкого :)
DN> Все-все цели МВУ либо самомотивируемы (объяснимы) в измеряемой модели
DN> (замучился писать - назовем это дело ИМ), либо просто в ней
DN> отсутствуют - это, видимо, очевидно. Но это не означает, что модели
DN> находятся в отношениях иерархической подчиненности. К примеру,
DN> написанный однажды код (программная модель), может с легкостью
DN> пережить свою бизнес-модель. Если, по большой части, оперировал
DN> понятиями горизонтальных (а не вертикальных!) прикладных
DN> словарей. Скажем, тот же e-mail или Internet.
Чего? E-mail или Internet пережил свою модель? Ау? Internet создавался
как среда для эффективного, надежного и дешевого обмена данными, чем он, по
идее ;), сейчас и является.
DN> Вывод: чем меньше молиться Богам, тем больше вероятность стать одним
DN> из них. 8-)
Ну, хоть вывод получен и неверными путями, но я с ним согласен. Как насчет
того, чтобы прекратить молиться богу M$? :)))
DN> Ну как еще поуговаривать... Давай так. Под термином сложность мы будем
DN> понимать ответ (в недискретной логике) на вопрос: "Насколько
DN> Провидению угодно происходящее". 8-)
Нет. Не согласен.
[...]
DN> Золотой принцип дизайна пропертей у компонента. Изменения их значений
DN> не должны быть взаимозависимы. Это позволяет избежать Сложности.
>> О! Так сложность таки определяется количеством взаимозависимостей.
>> Так?
DN> В том числе. Сложность - это насколько были обмануты ожидания МВУ.
DN> Зависимости ИМ, которые не входили в МВУ - повышают
DN> сложность. Зависимости МВУ, которые не входят в ИМ - тоже.
Зависимости, зависимости... Шамба-ла-ла... :)
Что ж вы от них так убегаете?
DN> Скажем, МВУ требует послать e-mail. Если ИМ (API) не mail-enabled, то
DN> рассогласование черезвычайно велико. Если ИМ имеет функцию высокого
DN> уровня для отправки письма за один вызов - Это Сделать Не Сложно. 8-)
(tm) забыли поставить :)
DN> Если ИМ предоставляет только низкоуровневую россыпь функций для
DN> почтовых дел, то откликнуться на требования МВУ (заказчика)
DN> сложно. Явно надо устраивать субмодельное расслоение: MAPI и CDO. 8-)
У тебя какой-то кривой анализ. Никакая субмодельная расслоенность тут не
появляется. У МВУ (вот, блин, любовь к аббревиатурам) есть требование к
отсылке email? No prolems, как говорят господа англичане. Делаем
подсистему (UML package, SM domain), в обязанности которого будет входить
отсылка e-mail. Дальнейшие детали -- ее (подсистемы) личное дело. Где
здесь "субмодель".
DN> И пока принцип блюдут - все проперти самоописательны своим
DN> названием. Их можно рассматривать поотдельности. А насчет общего их
DN> количества... Так делаем красивый UI с удобной сортировкой, поиском в
DN> Библиотеке Типов по первым буквам при написании кода в редакторе и
DN> вперед. Хоть пятьдесят, хоть сто.
>> Нет, неправильно. Потому что прячете сложность в название. Как насчет
>> того, чтобы иметь 100 пропертей, поименованых последовательно от 0 до
>> 99? Не, сделаем лучше. :-] Придумайте хотя бы 20 синонимов слову шрифт
>> :-]]] // Или рифму к слову "пакля" ;)
DN> Хм... Какие бы разные модели не были, они должны иметь некую общую
DN> (субмодельную) культуру. Например, английский. 8-)
20 synonyms for 'font' please? :)
DN> Вот мне (МВУ) надо отправить письмо. Я открываю смотрелку библиотек
DN> типов и ищу что? SendMail или типа того. Так что, правильно, прячу в
DN> название. А чеж ей, гордиться чтоль? 8-)
Ага. А там вместо Sendmail стоит MAPI. Или SMTP. Или, того хуже,
Sockets. Приехали? :)
DN> А придумывать синонимы - это знаете, не правильно. Контекст надо
DN> чувствовать, структуру корректную заводить. Вот и не будет длинных
DN> списков. Будут древовидные namespaces. Объем мы тоже
DN> раскладываем. Через UI. Как сложность. 8-)
Что сложнее: бинарное дерево с 512 листьями или список с 512 элементами?
[...]
>> Итого: 1 Вы сами сказали, что сложность определяется зависимостями.
DN> Зависимости - внутримодельны. Сложность - межмодельна и определяется
DN> рассогласованием, в том числе и зависимостей.
Мы о разной сложности. Я -- о сложности, которая коррелирует со стоимостью
поддержки. Иначе говоря стоимостью изменения модуля при изменении
требований к нему.
>> 2 Наша цель -- бороться со сложностью.
DN> Наша цель, дать МВУ именно то, чего она, исходя из своих
DN> представлений, от нас ожидает. ОК. "Рады! Ли! Вы! О! Боги!" 8-)
Nope. Решить задачу средней сложности может выпускник универа. А вот
написать так, чтобы при изменении задачи не нужно было все переписывать с
нуля -- нет. Итого: нужно бороться со сложностью :) С моей сложностью ;)
>> 3 Нельзя бороться с тем, чего не знаешь
DN> Хм. Уже кажется цитировал. "К неизвестному нет стремления" (с) Овидий.
DN> А вот бороться можно. Либо недеянием или просто кого-нибудь нанять и
DN> поставить общую цель. 8-)
Ну да, этот кто-то, если вы не понимаете задачи, либо пропьет ваши деньги,
либо будет за них компосировать вам мозги, до того момента, когда вы задачу
поймете.
DN> А знание сложности, хм... это такая однонаправленная вещь. Только от
DN> МВУ и вниз. 8-)
DN> Да, я помню, что говорил об отсутствии четкой иерархии моделей. Потому
DN> и сложности разные. Смотря как выбрать МВУ и ИМ. То что нужно
DN> программной модели (тут МВУ) - скажем, стабильность бизнес логики -
DN> оборачивается сложностью для бизнеса (ИМ) ...
Это вы про что-то не то :)
>> 4 Нужно определить сложность измеряемой величиной (лучше всего --
>> числом)
DN> Q + C = 1
DN> Q - эффективность (0..1) C - сложность (0..1) И чего? 8-)
Сменяли шило на мыло. Определи эффективность не через сложность?
>> 5 Зависимости между артефактами можно легко отобразить на направленном
>> графе, теория которых достаточно хорошо разработана. 6 (и последний)
>> Нужно взять такую характеристику направленного графа, которая хорошо бы
>> коррелировала с субъективной сложностью, которая определяется
>> количеством зависимостей между узлами.
DN> У... Если бы определялась... Модели, на то и модели - что считают их
DN> отдельно. 8-) На сегодня тут чистая эмпирика, ролевые игры и искусство
DN> оглядывать окрестность.
Здрасте... Что, направленый граф нельзя описать числом, которое
коррелировало бы с числом дуг, приходящим к и исходящим от узлов?
DN> Мягко говоря, бессмыслено изучать науку которой еще нет. Эффективней
DN> всего построится в боевые порядки (COM+MSF) и вперед. Пока мы тут на
DN> этапе Воина. 8-)
Э не... Стройтесь сами, Дмитрий. Been there, done that, как говорят друзья
англичан американцы. Что-то мне не очень хочется подчиняться приказам
Коммандира, который сам воевать не очень умеет.
Dmitry Nogin
> DN> Термин "Сложность" применим к каждой из моделей. И оговаривает ее
> DN> отношение к модели(ям) верхнего уровня. Естественно, что каждый
> DN> (очередной) слой, при всем нашем старании, выглядит как попытка
> DN> заставить говорить жалкое подобие тени призрака отца Гамлета. Будем
> DN> реалистами. 8-) И исходя из этого невнятно вопиющего несовершенства,
> DN> имеет смысл определение: "Сложность - это рассогласование между
> DN> прогнозируемыми и реальными процессами взаимной адаптации компонентов
> DN> системы". Определение не мое (но любимое) и не из нашей индустрии,
> DN> поэтому давайте разберем термины.
> >> Мне это определение не нравится. Я предпочитаю считать сложность
> >> свойством самой модели безо всякой ее связи с моделями верхнего или
> >> нижнего уровня.
> DN> Ага. "Вещь в себе" знаешь как в оригинале звучала? "Вещь для
> DN> себя". 8-) Внутри модели мы не найдем ничего, что могло бы выступить в
> DN> качестве реального критерия ее соответствия потребностям
> DN> Провидения. 8-) Не выходя за ее рамки мы можем оценить (относительно)
> DN> э... консистентность (целостность), эффективность, и пр...
>А это совершенно другие показатели. Меня интересует "сложность" с точки
>зрения стоимости поддержки.
Так. Давай определять базис...
Извини, если буду об очевидном или повторюсь. Уж больно велико
рассогласование. 8-)
Поддержка, на сегодня, это вялотекущая разработка.
Само же софтверное производство в компонентной среде (с высоким
реиспользованием) есть быстротекущая поддержка. Включая TQM.
Да и поддержка, как удавливание глюков - это один вариант. Который полностью
определяется МВУ над кодом. Ты знаешь как должен работать этот кусок и того
именно от него и добиваешся. Долбая его долбагером за обман твоих ожиданий.
Точнее прогноза.
Но есть вторая и самая интересная сторона медали - бизнес меняется. И софт
меняется. Каждый - по своим правилам. То что хочет изменить в моделях
автоматизации бизнес, и то что хотят переделать себе в угоду в бизнесе
реалии модели автоматизации (торговля через интернет, например) - это и есть
предмет сложности. Рассогласование. Между моделями.
Я их не зря наделяю "желаниями". Все эти модели - в т.ч. модели человеческих
представлений. Точнее групп людей. Со своими профессиональными (и не очень)
интересами, представлениями о норме и темпах скорости роста качества/объема
или изменения характера услуг. Их прогнозы, их представления о том, что
должно быть, и что должно не быть; сколько времени можно потратить на
приведение в соответствие с их требованиями прилежащих моделей - все это
неустанно проецируется. С разной динамикой, разным временем падения
эффективности за неразрешение межмодельных рассогласований и пр...
Я говорил выше о целостности (cohesion), эффективности, зависимости и пр...
как о характеристиках сугубо внутримодельных. В отличии от Сложности. Они
могут сказать насколько хорошо реализована модель. Скажем, что-то о коде на
всех видах языков, скриптов и ресурсоописателей. Или как расставлены посты
вокруг склада боеприпасов. 8-)
"Сложность с точки зрения стоимости поддержки" это хорошо. Вопрос - какую
поддержку ты считаешь за поддержку? Ты согласен с вышеприведенными
категориями видов поддержки? 8-)
И про стоимость... Смотря за что платить. Это сильно зависит от региона и
может здорово изменить картину. Давай пока сойдемся на: "Сложность с точки
зрения объема работ по согласованию требований". Требования могут меняться в
процессе поддержки. Могут быть основаны на подробностях реализации, приходу
технологических новинок и обращены к бизнесу. Могут происходить изменения в
бизнесе и все идет в обратную сторону. Работа по поддержке суть обслуживание
этих требований (рассогласований структур/стратегий моделей). Если работа
_сложная_ - она и будет стоить дороже. При любых раскладах. Так?
> DN> У любой модели есть свои внутренние цели. И внутримодельная сложность,
> DN> как у меня и описано во второй части, фактически означает
> DN> дополнительное внутримодельное субмодельное расслоение. 8-) Этакий
> DN> институт помазанников Божьих на земле. 8-)
>Ну, давайте расслоим модель до уровня отдельных элементов. Какова
>сложность.
К любому элементу предъявляются какие-нибудь требования. Если ему (людям его
обслуживающим) их выполнить сложно - то Сложность высока. И наоборот.
Раскладывать можно до опупения. Просто для каждого разложения надо
придумывать свою методику и оценки качества, а это дорого и может оказаться
дороже, чем реализовать и обслуживать имеющуюся сложность в лоб. Превратить
проект в бесконечное выписывание для него прикладных библиотек - легко. 8-)
Есть несколько стандартных методик разложения моделей для бизнеса (Мы их
стопку уже рисовали) и несколько десятков компонентных комплексов, что
суть - те же модели, только общесистемные (горизонтальные: e-mail,
filesystem, db). В конце концов, если на субмодель можно натравить отдельную
комманду разработчиков (и один черт, что они с ней будут делать - либо с
нуля писать, либо напильником дорабатывать) - то вот вам и весь комплект
требований к модели. И задачу объяснить, и результат на соответствие
требованиям оценить. (Отдавать именование пропертей на откуп одному
программисту нельзя. Он их с честными глазами начнет нумеровать. 8-)
То, понимаешь, индустрию хотят, а как увидят - фу... как это низко... 8-)
DN> Все-все цели МВУ либо самомотивируемы (объяснимы) в измеряемой модели
> DN> (замучился писать - назовем это дело ИМ), либо просто в ней
> DN> отсутствуют - это, видимо, очевидно. Но это не означает, что модели
> DN> находятся в отношениях иерархической подчиненности. К примеру,
> DN> написанный однажды код (программная модель), может с легкостью
> DN> пережить свою бизнес-модель. Если, по большой части, оперировал
> DN> понятиями горизонтальных (а не вертикальных!) прикладных
> DN> словарей. Скажем, тот же e-mail или Internet.
>Чего? E-mail или Internet пережил свою модель? Ау? Internet создавался
>как среда для эффективного, надежного и дешевого обмена данными, чем он, по
>идее ;), сейчас и является.
Нет, программисты летать не могут. 8-)
Ты хоть помнишь под что там денег давали? Под науку и войну. А не порно и
WWW . 8-)
<Skip>
Давай, для начала, с этим устаканим. 8-)
Andrey V Khavryutchenko
DN> Так. Давай определять базис... Извини, если буду об очевидном или
DN> повторюсь. Уж больно велико рассогласование. 8-)
DN> Поддержка, на сегодня, это вялотекущая разработка. Само же софтверное
DN> производство в компонентной среде (с высоким реиспользованием) есть
DN> быстротекущая поддержка. Включая TQM.
? Не понял ту разницу, которую ты описываешь.
Почему ты считаешь, что есть "вялотекущая" разработка, а есть
"быстротекущая" разработка?
DN> Да и поддержка, как удавливание глюков - это один вариант. Который
DN> полностью определяется МВУ над кодом. Ты знаешь как должен работать
DN> этот кусок и того именно от него и добиваешся. Долбая его долбагером
DN> за обман твоих ожиданий. Точнее прогноза.
DN> Но есть вторая и самая интересная сторона медали - бизнес меняется. И
DN> софт меняется. Каждый - по своим правилам. То что хочет изменить в
DN> моделях автоматизации бизнес, и то что хотят переделать себе в угоду в
DN> бизнесе реалии модели автоматизации (торговля через интернет,
DN> например) - это и есть предмет сложности. Рассогласование. Между
DN> моделями.
Почти так. Я скажу свою точку зрения, а ты скажи, насколько она совпадает
с твоей.
Програмная система, после того, как она "написана" (доведена до некоей
точки, в которой клиент считает, что может ее использовать и платит за нее
деньги) может меняться только в двух случаях:
- если исходные требования реализованы некорректно (есть баг)
- если исходные требования меняются (добавляются новые, изменяются или
исчезают старые)
DN> Я их не зря наделяю "желаниями". Все эти модели - в т.ч. модели
DN> человеческих представлений. Точнее групп людей. Со своими
DN> профессиональными (и не очень) интересами, представлениями о норме и
DN> темпах скорости роста качества/объема или изменения характера
DN> услуг. Их прогнозы, их представления о том, что должно быть, и что
DN> должно не быть; сколько времени можно потратить на приведение в
DN> соответствие с их требованиями прилежащих моделей - все это неустанно
DN> проецируется. С разной динамикой, разным временем падения
DN> эффективности за неразрешение межмодельных рассогласований и пр...
DN> Я говорил выше о целостности (cohesion), эффективности, зависимости и
DN> пр... как о характеристиках сугубо внутримодельных. В отличии от
DN> Сложности. Они могут сказать насколько хорошо реализована
DN> модель. Скажем, что-то о коде на всех видах языков, скриптов и
DN> ресурсоописателей. Или как расставлены посты вокруг склада
DN> боеприпасов. 8-)
DN> "Сложность с точки зрения стоимости поддержки" это хорошо. Вопрос -
DN> какую поддержку ты считаешь за поддержку? Ты согласен с
DN> вышеприведенными категориями видов поддержки? 8-)
Ай-ай-ай... :) Нехорошо смешивать два вопроса в одном :) "Вы бросили пить
портвейн перед завтраком?"
Ты описываешь какую-то "большую" сложность. Меня же на данном этапе больше
интересует сложность "маленькая": насколько система устойчива к тем
изменениям, что я перечислил.
Устойчивость здесь определяется двумя факторами: неким "размером", например
количеством строк кода, которые нужно добавить/исправить/выбросить и
"усилиями" (effort), которые нужно приложить, для того, чтобы это сделать.
К сожалению, эти две величины _до_ исполнения определить трудно. Точнее,
прямо их определить просто невозможно. Гадание на кофейной гуще меня не
устраивает. Вот я и пытаюсь ввести некий численный фактор, который бы
хорошо коррелировал с этими двумя величинами.
Интуитивно, если представлять програмную систему в виде направленного
графа, мне ясно, что эти две величины будут сильно зависить от того,
насколько хорошо граф структурирован, насколько хорошо соблюден баланс
между изолированностью и согласованностью разных кластеров в нем.
Теперь яснее, какую величину я ищу?
DN> И про стоимость... Смотря за что платить. Это сильно зависит от
DN> региона и может здорово изменить картину. Давай пока сойдемся на:
DN> "Сложность с точки зрения объема работ по согласованию
DN> требований". Требования могут меняться в процессе поддержки. Могут
DN> быть основаны на подробностях реализации, приходу технологических
DN> новинок и обращены к бизнесу. Могут происходить изменения в бизнесе и
DN> все идет в обратную сторону. Работа по поддержке суть обслуживание
DN> этих требований (рассогласований структур/стратегий моделей). Если
DN> работа _сложная_ - она и будет стоить дороже. При любых
DN> раскладах. Так?
"Стоимость" определяется "размером" и "усилиями".
DN> У любой модели есть свои внутренние цели. И внутримодельная сложность,
DN> как у меня и описано во второй части, фактически означает
DN> дополнительное внутримодельное субмодельное расслоение. 8-) Этакий
DN> институт помазанников Божьих на земле. 8-)
>> Ну, давайте расслоим модель до уровня отдельных элементов. Какова
>> сложность.
DN> К любому элементу предъявляются какие-нибудь требования. Если ему
DN> (людям его обслуживающим) их выполнить сложно - то Сложность высока. И
DN> наоборот. Раскладывать можно до опупения. Просто для каждого
DN> разложения надо придумывать свою методику и оценки качества, а это
DN> дорого и может оказаться дороже, чем реализовать и обслуживать
DN> имеющуюся сложность в лоб. Превратить проект в бесконечное выписывание
DN> для него прикладных библиотек - легко. 8-)
DN> Есть несколько стандартных методик разложения моделей для бизнеса (Мы
DN> их стопку уже рисовали) и несколько десятков компонентных комплексов,
DN> что суть - те же модели, только общесистемные (горизонтальные: e-mail,
DN> filesystem, db). В конце концов, если на субмодель можно натравить
DN> отдельную комманду разработчиков (и один черт, что они с ней будут
DN> делать - либо с нуля писать, либо напильником дорабатывать) - то вот
DN> вам и весь комплект требований к модели. И задачу объяснить, и
DN> результат на соответствие требованиям оценить. (Отдавать именование
DN> пропертей на откуп одному программисту нельзя. Он их с честными
DN> глазами начнет нумеровать. 8-)
You completely lost me here. Вообще перестал понимать к чему ты клонишь.
DN> То, понимаешь, индустрию хотят, а как увидят - фу... как это
DN> низко... 8-)
DN> Все-все цели МВУ либо самомотивируемы (объяснимы) в измеряемой модели
DN> (замучился писать - назовем это дело ИМ), либо просто в ней
DN> отсутствуют - это, видимо, очевидно. Но это не означает, что модели
DN> находятся в отношениях иерархической подчиненности. К примеру,
DN> написанный однажды код (программная модель), может с легкостью
DN> пережить свою бизнес-модель. Если, по большой части, оперировал
DN> понятиями горизонтальных (а не вертикальных!) прикладных
DN> словарей. Скажем, тот же e-mail или Internet.
>> Чего? E-mail или Internet пережил свою модель? Ау? Internet
>> создавался как среда для эффективного, надежного и дешевого обмена
>> данными, чем он, по идее ;), сейчас и является.
DN> Нет, программисты летать не могут. 8-) Ты хоть помнишь под что там
DN> денег давали? Под науку и войну. А не порно и WWW . 8-)
"В каждой большой программе есть маленькая, которая изо всех сил рвется
наружу" :)
Вот в и-нете она и вырвалась в виде почти надежной и очень дешевой методы
передачи данных на большие расстояния.
DN> Давай, для начала, с этим устаканим. 8-)
Your turn.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Fish gotta swim. Birds gotta fly. Fools gotta publish
Dmitry Nogin
> DN> повторюсь. Уж больно велико рассогласование. 8-)
> DN> Поддержка, на сегодня, это вялотекущая разработка. Само же софтверное
> DN> производство в компонентной среде (с высоким реиспользованием) есть
> DN> быстротекущая поддержка. Включая TQM.
>? Не понял ту разницу, которую ты описываешь.
>Почему ты считаешь, что есть "вялотекущая" разработка, а есть
>"быстротекущая" разработка?
Для девелопера - разницы нет. Есть некоторые отличия в стратегии
менеджмента. Вообще говоря, я подозревал что ты отклоняешься во мнении в
другую сторону. 8-)
> DN> Да и поддержка, как удавливание глюков - это один вариант. Который
> DN> полностью определяется МВУ над кодом. Ты знаешь как должен работать
> DN> этот кусок и того именно от него и добиваешся. Долбая его долбагером
> DN> за обман твоих ожиданий. Точнее прогноза.
> DN> Но есть вторая и самая интересная сторона медали - бизнес меняется. И
> DN> софт меняется. Каждый - по своим правилам. То что хочет изменить в
> DN> моделях автоматизации бизнес, и то что хотят переделать себе в угоду в
> DN> бизнесе реалии модели автоматизации (торговля через интернет,
> DN> например) - это и есть предмет сложности. Рассогласование. Между
> DN> моделями.
>Почти так. Я скажу свою точку зрения, а ты скажи, насколько она совпадает
>с твоей.
>Програмная система, после того, как она "написана" (доведена до некоей
>точки, в которой клиент считает, что может ее использовать и платит за нее
>деньги) может меняться только в двух случаях:
> - если исходные требования реализованы некорректно (есть баг)
> - если исходные требования меняются (добавляются новые, изменяются или
> исчезают старые)
ОК. Только нужно отметить что при обскриптовочно/компонентном подходе... Э,
лучше цитата из доки по VB 8-)
More seriously, an over-emphasis on inheritance-driven polymorphism
typically results in a massive shift of resources from development tasks to
up-front design tasks, doing nothing to address development backlogs or to
shorten the time before the end user can discover - through hands-on
experience - whether the system actually fulfills the intended purpose.
Идея в чем? Что одной из качественных целей методики разработки является
"Smooth deployment and ongoing management". В просторечии означает что это
разные моменты - когда "клиент считает, что может ее использовать" и когда
"клиент платит за нее деньги". Что делать социологам, пока кодеры стучат?
Гонять на том что написано - штабные игры. И для верности - end-user уже
должен думать, что все всерьез. Что впрочем и есть правильно. Никто
увиденную пользователем HTML страничку менять не собирается. Если, конечно,
она его устроит. Вообще, ноги этой временной дельты растут из разницы между
customer и end-user.
А сказать где тут "исходные требования", а где что меняется или
добавляется - неполучится. В принципе, это вопрос момента формулировки
требований - до кодирования или после. Так? Возражу. 8-) Во-первых, если все
используемые модели формализованы и мы можем крутануть цикл редизайна - то
фактически становится возможным дважды войти в одну и туже воду. Во-вторых,
компоненты пишут независимо. Ну почти независимо - были бы интерфейсы. А
интерфейсов к готовым компонентам и добавить не долго. 8-)
Да понятно. И давно. 8-)
Ну чего может быть интересно программисту. 8-)
Только, во-первых, это дело подчиняется тем же принципам. Во-вторых, этого
безмерно мало для реалий жизни корпоративного софта. И к тому же модель
уровня кода в компонентной архитектуре выглядит так же просто как реализация
член-функций у ООП. Чего там философии разводить - скриптуй давай, налево и
направо. Упрощая, можно сказать что тебе не так важно где тут дорога, если
ты на танке. На маршрут, главным образом, влияет - куда тебя несет нелегкая.
8-)
Я хочу сказать что Сложность - это способ оценить там мы или не там. Это,
если угодно, мера приемлимости. А вот отчего отсчитывать? И тут мы переходим
к целевому управлению. Я не хочу сказать, что ты уже согласен с определением
моей Сложности как единственно верной или очень нужной. 8-) Давай будем
просто считать что она у тебя есть в голове во всей своей
динамически/предсказательной красоте формулировки. 8-)
Предлагается считать, что six key quality goals must be achieved in order
for a project to be considered successful.
* Delivery within project constraints
* Satisfied customers
* Delivery to specifications based on user requirements
* Release after knowing and addressing all issues
* Enhanced user performance
* Smooth deployment and ongoing management
Подробней:
Delivery within Project Constraints
A key goal for all teams is to deliver within project constraints. The
fundamental constraints of any project include those of budget and schedule.
Most projects measure success using "on time, on budget" metrics.
Satisfied Customers
Projects must meet the needs of customers and users in order to be
successful. It is possible to meet budget and time goals but still be
unsuccessful if customer needs have not been met.
Delivery to Specifications Based on User Requirements
The product specification describes in detail the deliverable to be provided
by the team to the customer. It is important for the team to deliver in
accordance with the specification as accurately as possible because it
represents an agreement between the team and the customer as to what will be
built.
Release After Knowing and Addressing All Issues
All software is delivered with defects. A key goal is to ensure those
defects are identified and addressed prior to releasing the product.
Addressing can involve everything from fixing the defect in question to
documenting work-around solutions. Delivering a known defect that has been
addressed along with a work-around solution is preferable to delivering a
product containing unidentified defects that may "surprise" the team and
customer later.
Enhanced User Performance
In order for a product to be successful, it must enhance the way that users
work and perform. Delivering a product that is rich in features and content
but is not usable by its designated end user is considered a failure.
Smooth Deployment and Ongoing Management
Sometimes the need for a smooth deployment is overlooked. The perception of
a deployment is carried over to the product itself, rightly or wrongly. For
example, a faulty installation program may lead users to assume that the
installed application is similarly faulty, even when this may not be true.
Consequently, the team must do more than simply deploy; it must strive for a
smooth deployment and prepare for the support and management of the product.
This can include ensuring that training, infrastructure, and support are in
place prior to deployment.
<Skip в связи с>
You completely lost me here. Вообще перестал понимать к чему ты клонишь.
<Skip>
Давай вот тут определимся - согласен ли ты отсчитывать полезность того что
делаешь на основании этих целей. Расценивая их, при том, как одинаково
важные? Думаешь ли ты что есть какие-то не менее весомые факторы успеха?
Alexander V. Didytch
30 Jul 98 14:13, Dmitry Nogin wrote to All:
DN> Поддержка, на сегодня, это вялотекущая разработка.
DN> Само же софтверное производство в компонентной среде (с высоким
DN> реиспользованием) есть быстротекущая поддержка. Включая TQM.
Хм. A ecли я мeняю aрхитeктуру ужe cущecтвующeй cиcтeмы
(вeрнee aнaлиз ocтaлcя тeмжe, вeрхнe урoвнeвый дизaйн тeм жe нo
низкoурoвнeвый пoмeнялcя и прoцecc кoдирoвaния тoжe) тo этo шo
пoддeржкa или рaзрaбoткa ?
DN> Да и поддержка, как удавливание глюков - это один вариант. Который
DN> полностью определяется МВУ над кодом.
A шo тaкe MВУ ?
DN> И про стоимость... Смотря за что платить.
Дaвaй тaк -- cтoимocть мeрять в чeлoвeкo чacaх, тoлькo вoт кaкoгo индивидa ?
Прeдлaгaю вce рaccмaтривaть в cвoeй шкaлe (хoть и будут нeпoнятки нo ктo-тo
мoжeт прeдлoжить лучшee ?)
DN> Если работа _сложная_ - она и будет стоить дороже. При любых
DN> раскладах. Так?
He coглaceн -- у мeня был примeр бaнкoвcкoй cиcтeмы нa кoтoрoй мoжнo
былo здeлaть любую другую и этa зaдaчa нe былa cлoжнoй (ну пoдумaушь
тaм oчeнь дoлгo рaбoтaлa:), нo прeдпoлoжим чтo трeбoвaний нa cкoрocть
нa нee нe былo) прocтo oнa aрхитeктурнo былa пocтрoeнa тaким oбрaзoм
чтo cмeнa бизнeca etc. тaм в бoльшинcтвe cлучaeв вырaжaлacь в cмeнe
пaрaмeтрoв и дoбaвлeнии нoвых _клaccoв_ ээ клacc этo нe клacичecкoe
oпрeдeлeниe лучшe cкaжу шaблoнoв дoкумeнтoв (кaк в OLE).
Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_
тo _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
Sincerely, Alexander
--
-=>if you re-invent the square wheel, you will not benefit when
-=>somebody else rounds off the corners.
Dmitry Nogin
> DN> Поддержка, на сегодня, это вялотекущая разработка.
> DN> Само же софтверное производство в компонентной среде (с высоким
> DN> реиспользованием) есть быстротекущая поддержка. Включая TQM.
> Хм. A ecли я мeняю aрхитeктуру ужe cущecтвующeй cиcтeмы
> (вeрнee aнaлиз ocтaлcя тeмжe, вeрхнe урoвнeвый дизaйн тeм жe нo
> низкoурoвнeвый пoмeнялcя и прoцecc кoдирoвaния тoжe) тo этo шo
> пoддeржкa или рaзрaбoткa?
ООП не фиг разводить заместо обскриптовки сервисов/компонентов. Вот и будет
меньше зависимостей от архитектур реализаций конкретных существующих или не
очень систем. Архитектура должна быть по месту. The business need drives
application development.
И какое дело физическому компоненту до всех этих "пoддeржкa или рaзрaбoткa"?
"Кнопке", скажем? Или компоненту "Товар", который используется компонентами
"Прайс" и "Счет", на изменения в компоненте "Назначатель НДСов"? Ну
поменяешь один из них, или интерфейс какой новый добавишь... Да и вышлешь
via e-mail транзакшен серверу заказчика.
Стоимость страхования риска у проекта в этих стадиях разная. И менеджмент
соответственно. А все остальное в практике много проще чем в теории.
> DN> Да и поддержка, как удавливание глюков - это один вариант. Который
> DN> полностью определяется МВУ над кодом.
> A шo тaкe MВУ ?
Видимо до тебя не дошло. 8-)
Перепосылаю via e-mail. Subj: "Сложность".
>DN> И про стоимость... Смотря за что платить.
>Дaвaй тaк -- cтoимocть мeрять в чeлoвeкo чacaх, тoлькo вoт кaкoгo индивидa?
>Прeдлaгaю вce рaccмaтривaть в cвoeй шкaлe (хoть и будут нeпoнятки нo
>ктo-тo мoжeт прeдлoжить лучшee ?)
Вот-вот. Человеко-часы совсем не катят. Если тебе понадобится под угрозой
потери крупных сумм нерегулярное 5 минутное присутствие председателя
правления банка при ночной репликации... 8-)
> DN> Если работа _сложная_ - она и будет стоить дороже. При любых
> DN> раскладах. Так?
> He coглaceн -- у мeня был примeр бaнкoвcкoй cиcтeмы нa кoтoрoй мoжнo
> былo здeлaть любую другую и этa зaдaчa нe былa cлoжнoй (ну пoдумaушь
> тaм oчeнь дoлгo рaбoтaлa:), нo прeдпoлoжим чтo трeбoвaний нa cкoрocть
> нa нee нe былo) прocтo oнa aрхитeктурнo былa пocтрoeнa тaким oбрaзoм
> чтo cмeнa бизнeca etc. тaм в бoльшинcтвe cлучaeв вырaжaлacь в cмeнe
> пaрaмeтрoв и дoбaвлeнии нoвых _клaccoв_ ээ клacc этo нe клacичecкoe
> oпрeдeлeниe лучшe cкaжу шaблoнoв дoкумeнтoв (кaк в OLE).
См. вышеупомянутое перепослание. О сложности.
Бихевиористически 8-) Сложность - это мера взаимного игнорирования
интересов. В обоих направлениях измеряется практикой независимо. 8-) Т.е.
здесь между бизнесом и банковской системой. Существуют структурные решения,
способные понизить сложность минимально увеличивая объем работ или просто их
перераспределяя. Это то о чем говоришь ты. Если бы не была предпринята,
вероятно успешная, попытка реинвентинга коклассов - непредусмотренные
изменения в бизнесе приводили бы к большему объему работы. А за нее надо
платить. Как и за задержку в реализации кодом потребностей бизнеса. И пр...
Ну как бы это еще сказать... Попробуй чего-нибудь добиться от чиновника,
которому начхать на твои проблемы. Видимо сложно и будет стоить дороже. 8-)
> Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_
> тo _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
Запасы бывают разные. Проще поменять свечи зажигания, чем сделать их с руку
толщиной. 8-)
Andrey V Khavryutchenko
DN> Alexander V. Didytch wrote in message
DN> <9025...@p7.f178.n463.z2.ftn>... Поддержка, на сегодня, это
DN> вялотекущая разработка. Само же софтверное производство в
DN> компонентной среде (с высоким реиспользованием) есть быстротекущая
DN> поддержка. Включая TQM.
>> Хм. A ecли я мeняю aрхитeктуру ужe cущecтвующeй cиcтeмы (вeрнee aнaлиз
>> ocтaлcя тeмжe, вeрхнe урoвнeвый дизaйн тeм жe нo низкoурoвнeвый
>> пoмeнялcя и прoцecc кoдирoвaния тoжe) тo этo шo пoддeржкa или
>> рaзрaбoткa?
DN> ООП не фиг разводить заместо обскриптовки сервисов/компонентов. Вот и
DN> будет меньше зависимостей от архитектур реализаций конкретных
DN> существующих или не очень систем. Архитектура должна быть по
DN> месту. The business need drives application development.
Да уж. Зависимостей меньше... Особенно от архитектуры... ;-\
DN> И какое дело физическому компоненту до всех этих "пoддeржкa или
DN> рaзрaбoткa"? "Кнопке", скажем? Или компоненту "Товар", который
DN> используется компонентами "Прайс" и "Счет", на изменения в компоненте
DN> "Назначатель НДСов"? Ну поменяешь один из них, или интерфейс какой
DN> новый добавишь... Да и вышлешь via e-mail транзакшен серверу
DN> заказчика.
Уходишь от ответа. Нехорошо :)
Итак, задача: компания занимается той же продажей (скажем, через и-нет).
Но вдруг, в один прекрасный день, переехала из России в США.
Соответственно, меняются не только объекты (компОненты ;), но и отношения
между ними. Ты предлагаешь выбросить весь application нафиг и делать
новый?
Кстати, а новые компоненты, конечно же, из воздуха возьмутся? Кто для них
будет требования составлять.
[...]
DN> И про стоимость... Смотря за что платить.
>> Дaвaй тaк -- cтoимocть мeрять в чeлoвeкo чacaх, тoлькo вoт кaкoгo
>> индивидa? Прeдлaгaю вce рaccмaтривaть в cвoeй шкaлe (хoть и будут
>> нeпoнятки нo ктo-тo мoжeт прeдлoжить лучшee ?)
DN> Вот-вот. Человеко-часы совсем не катят. Если тебе понадобится под
DN> угрозой потери крупных сумм нерегулярное 5 минутное присутствие
DN> председателя правления банка при ночной репликации... 8-)
Что вот-вот? В чем ты трудоемкость меряешь?
[...]
>> Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_ тo
>> _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
DN> Запасы бывают разные. Проще поменять свечи зажигания, чем сделать их с
DN> руку толщиной. 8-)
Одноразовые applications? По моему мы это уже проходили. Примерно во
времена бума AI.
Dmitry Nogin
> >> ocтaлcя тeмжe, вeрхнe урoвнeвый дизaйн тeм жe нo низкoурoвнeвый
> >> пoмeнялcя и прoцecc кoдирoвaния тoжe) тo этo шo пoддeржкa или
> >> рaзрaбoткa?
> DN> ООП не фиг разводить заместо обскриптовки сервисов/компонентов. Вот и
> DN> будет меньше зависимостей от архитектур реализаций конкретных
> DN> существующих или не очень систем. Архитектура должна быть по
> DN> месту. The business need drives application development.
>Да уж. Зависимостей меньше... Особенно от архитектуры... ;-\
Мы это уже как-то выяснили. Как бывает меньше зависимостей благодаря
архитектуре. С наследованием по месту реализаций интерфейсов. Помнишь?
Ну так выносим в скрипты весь тюнинг наследований и вперед. Чего тут
подозрительного? А устоявшихся готовых сервисов на все случаи жизни уже и
так выше крыши. Типа SQL, MTS и пр...
> DN> И какое дело физическому компоненту до всех этих "пoддeржкa или
> DN> рaзрaбoткa"? "Кнопке", скажем? Или компоненту "Товар", который
> DN> используется компонентами "Прайс" и "Счет", на изменения в компоненте
> DN> "Назначатель НДСов"? Ну поменяешь один из них, или интерфейс какой
> DN> новый добавишь... Да и вышлешь via e-mail транзакшен серверу
> DN> заказчика.
>Уходишь от ответа. Нехорошо :)
>Итак, задача: компания занимается той же продажей (скажем, через и-нет).
>Но вдруг, в один прекрасный день, переехала из России в США.
>Соответственно, меняются не только объекты (компОненты ;), но и отношения
>между ними. Ты предлагаешь выбросить весь application нафиг и делать
>новый?
Ты скрипты для WWW писал? Чтоб дергали SQL Stored Procedure? Ну и так далее.
n*n-tier. Нету больше Application. А некоторые части скриптобвязки пакуют в
теже компоненты. Для удобства реиспользования/обслуживания. И неожиданно
вдруг узнают в них реиспользуемые сервисы.
>Кстати, а новые компоненты, конечно же, из воздуха возьмутся? Кто для них
>будет требования составлять.
Ай слушай. Хочешь знать - прочитаешь за один день 70 страниц. Не хочешь? Так
чего спрашиваешь. Ну начну я тебе опять про цивилизацию рассказывать, с
целевым управлением, совместимостью стратегий и пр... А можно просто не
ходить по газону. Выучить 6 ролей и правила этикета.
И так, и сяк - успешности у MSF не убудет.
> DN> И про стоимость... Смотря за что платить.
> >> Дaвaй тaк -- cтoимocть мeрять в чeлoвeкo чacaх, тoлькo вoт кaкoгo
> >> индивидa? Прeдлaгaю вce рaccмaтривaть в cвoeй шкaлe (хoть и будут
> >> нeпoнятки нo ктo-тo мoжeт прeдлoжить лучшee ?)
> DN> Вот-вот. Человеко-часы совсем не катят. Если тебе понадобится под
> DN> угрозой потери крупных сумм нерегулярное 5 минутное присутствие
> DN> председателя правления банка при ночной репликации... 8-)
>Что вот-вот? В чем ты трудоемкость меряешь?
В деньгах. 8-)
> >> Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_ тo
> >> _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
> DN> Запасы бывают разные. Проще поменять свечи зажигания, чем сделать их с
> DN> руку толщиной. 8-)
>Одноразовые applications? По моему мы это уже проходили. Примерно во
>времена бума AI.
Нету больше Application. Ну извини, доказывать не буду. Утомился. 8-)
Кому надо - ссылок дам.
Andrey V Khavryutchenko
>>>>> "DN" == Dmitry Nogin writes:
DN> Andrey V Khavryutchenko wrote in message ...
>> >> Хм. A ecли я мeняю aрхитeктуру ужe cущecтвующeй cиcтeмы (вeрнee
>> aнaлиз >> ocтaлcя тeмжe, вeрхнe урoвнeвый дизaйн тeм жe нo
>> низкoурoвнeвый >> пoмeнялcя и прoцecc кoдирoвaния тoжe) тo этo шo
>> пoддeржкa или >> рaзрaбoткa?
DN> ООП не фиг разводить заместо обскриптовки сервисов/компонентов. Вот и
DN> будет меньше зависимостей от архитектур реализаций конкретных
DN> существующих или не очень систем. Архитектура должна быть по
DN> месту. The business need drives application development.
>> Да уж. Зависимостей меньше... Особенно от архитектуры... ;-\
DN> Мы это уже как-то выяснили. Как бывает меньше зависимостей благодаря
DN> архитектуре. С наследованием по месту реализаций интерфейсов. Помнишь?
DN> Ну так выносим в скрипты весь тюнинг наследований и вперед. Чего тут
DN> подозрительного? А устоявшихся готовых сервисов на все случаи жизни
DN> уже и так выше крыши. Типа SQL, MTS и пр...
Да? Если ты и выяснил, то без меня. От зависимостей ты никуда не
денешся. Они есть что в OOP, что в новомодных "компонентных архитектурах".
DN> И какое дело физическому компоненту до всех этих "пoддeржкa или
DN> рaзрaбoткa"? "Кнопке", скажем? Или компоненту "Товар", который
DN> используется компонентами "Прайс" и "Счет", на изменения в компоненте
DN> "Назначатель НДСов"? Ну поменяешь один из них, или интерфейс какой
DN> новый добавишь... Да и вышлешь via e-mail транзакшен серверу
DN> заказчика.
>> Уходишь от ответа. Нехорошо :) Итак, задача: компания занимается той
>> же продажей (скажем, через и-нет). Но вдруг, в один прекрасный день,
>> переехала из России в США. Соответственно, меняются не только объекты
>> (компОненты ;), но и отношения между ними. Ты предлагаешь выбросить
>> весь application нафиг и делать новый?
DN> Ты скрипты для WWW писал?
Да.
DN> Чтоб дергали SQL Stored Procedure?
Нет. База не поддерживала stored procedure. Слабенькая была.
DN> Ну и так далее. n*n-tier. Нету больше Application.
А куда он делся? Проблемму пользователя решает -- значит есть. А то что
он идет не на перфоленте, так кому какое дело.
DN> А некоторые части скриптобвязки пакуют в теже компоненты. Для удобства
DN> реиспользования/обслуживания. И неожиданно вдруг узнают в них
DN> реиспользуемые сервисы.
Какие части пакуют? Для чего? Как решаются вопросы управления
зависимостями, когда сия новая компонента переезжает с одного уровня
абстракции на другой? Что делается, когда "узнают в них реиспользуемые
сервисы"?
>> Кстати, а новые компоненты, конечно же, из воздуха возьмутся? Кто для
>> них будет требования составлять.
DN> Ай слушай. Хочешь знать - прочитаешь за один день 70 страниц. Не
DN> хочешь? Так чего спрашиваешь. Ну начну я тебе опять про цивилизацию
DN> рассказывать, с целевым управлением, совместимостью стратегий и
DN> пр... А можно просто не ходить по газону. Выучить 6 ролей и правила
DN> этикета.
Да, знать хочу. Прочитать -- не могу, времени нет. Целевое управление,
совместимость стратегий и пр здесь абсолютно не при чем.
Вопросы совершенно конкретены:
Изменилась предметная область. Кто и как пишет требования к новому
компоненту? Как реализуется компонента, удовлетворяющая этим требованиям?
Как в эту компоненту вносятся изменение, при изменении требований к ней?
DN> И так, и сяк - успешности у MSF не убудет.
До тех пор пока MS ее проталкивает -- да.
DN> И про стоимость... Смотря за что платить.
>> >> Дaвaй тaк -- cтoимocть мeрять в чeлoвeкo чacaх, тoлькo вoт кaкoгo >>
>> индивидa? Прeдлaгaю вce рaccмaтривaть в cвoeй шкaлe (хoть и будут >>
>> нeпoнятки нo ктo-тo мoжeт прeдлoжить лучшee ?)
DN> Вот-вот. Человеко-часы совсем не катят. Если тебе понадобится под
DN> угрозой потери крупных сумм нерегулярное 5 минутное присутствие
DN> председателя правления банка при ночной репликации... 8-)
>> Что вот-вот? В чем ты трудоемкость меряешь?
DN> В деньгах. 8-)
Это не трудоемкость (effort). Это деньги. Вопрос остается в силе.
>> >> Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_
>> тo >> _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
DN> Запасы бывают разные. Проще поменять свечи зажигания, чем сделать их с
DN> руку толщиной. 8-)
>> Одноразовые applications? По моему мы это уже проходили. Примерно во
>> времена бума AI.
DN> Нету больше Application. Ну извини, доказывать не буду. Утомился. 8-)
DN> Кому надо - ссылок дам.
Что-то всегда есть. И вопросы к этому "что-то" не меняются. Повторяю
второй раз:
1. Кто и как определяет требования к новому "что-то"?
2. Как реализуется "что-то", удовлетворяющее требованиям, полученным в п.1?
3. Как меняется реализация этого "что=то" при изменении требований к ней?
Andrey V Khavryutchenko
>>>>> "DN" == Dmitry Nogin writes:
DN> Andrey V Khavryutchenko wrote in message ... Так. Давай определять
DN> базис... Извини, если буду об очевидном или повторюсь. Уж больно
DN> велико рассогласование. 8-) Поддержка, на сегодня, это вялотекущая
DN> разработка. Само же софтверное производство в компонентной среде (с
DN> высоким реиспользованием) есть быстротекущая поддержка. Включая TQM.
>>> Не понял ту разницу, которую ты описываешь.
>> Почему ты считаешь, что есть "вялотекущая" разработка, а есть
>> "быстротекущая" разработка?
DN> Для девелопера - разницы нет. Есть некоторые отличия в стратегии
DN> менеджмента. Вообще говоря, я подозревал что ты отклоняешься во мнении
DN> в другую сторону. 8-)
В какую другую? Не понял.
DN> Да и поддержка, как удавливание глюков - это один вариант. Который
DN> полностью определяется МВУ над кодом. Ты знаешь как должен работать
DN> этот кусок и того именно от него и добиваешся. Долбая его долбагером
DN> за обман твоих ожиданий. Точнее прогноза. Но есть вторая и самая
DN> интересная сторона медали - бизнес меняется. И софт меняется. Каждый -
DN> по своим правилам. То что хочет изменить в моделях автоматизации
DN> бизнес, и то что хотят переделать себе в угоду в бизнесе реалии модели
DN> автоматизации (торговля через интернет, например) - это и есть предмет
DN> сложности. Рассогласование. Между моделями.
>> Почти так. Я скажу свою точку зрения, а ты скажи, насколько она
>> совпадает с твоей. Програмная система, после того, как она "написана"
>> (доведена до некоей точки, в которой клиент считает, что может ее
>> использовать и платит за нее деньги) может меняться только в двух
>> случаях: - если исходные требования реализованы некорректно (есть баг)
>> - если исходные требования меняются (добавляются новые, изменяются или
>> исчезают старые)
DN> ОК. Только нужно отметить что при обскриптовочно/компонентном
DN> подходе... Э, лучше цитата из доки по VB 8-)
DN> More seriously, an over-emphasis on inheritance-driven polymorphism
DN> typically results in a massive shift of resources from development
DN> tasks to up-front design tasks, doing nothing to address development
DN> backlogs or to shorten the time before the end user can discover -
DN> through hands-on experience - whether the system actually fulfills the
DN> intended purpose.
Ничем не обоснованное утверждение. Или они под development tasks имеют в
виду набивание кода? Тогда пусть нанимают профессиональных машинисток --
они будут программировать _очень_ быстро.
DN> Идея в чем? Что одной из качественных целей методики разработки
DN> является "Smooth deployment and ongoing management". В просторечии
DN> означает что это разные моменты - когда "клиент считает, что может ее
DN> использовать" и когда "клиент платит за нее деньги". Что делать
DN> социологам, пока кодеры стучат? Гонять на том что написано - штабные
DN> игры. И для верности - end-user уже должен думать, что все
DN> всерьез. Что впрочем и есть правильно. Никто увиденную пользователем
DN> HTML страничку менять не собирается. Если, конечно, она его
DN> устроит. Вообще, ноги этой временной дельты растут из разницы между
DN> customer и end-user.
DN> А сказать где тут "исходные требования", а где что меняется или
DN> добавляется - неполучится. В принципе, это вопрос момента формулировки
DN> требований - до кодирования или после.
Ты резко упал в моих глазах. Написание требований после кодирования --
вернейший путь к провалу проекта.
DN> Так? Возражу. 8-) Во-первых, если все используемые модели
DN> формализованы и мы можем крутануть цикл редизайна - то фактически
DN> становится возможным дважды войти в одну и туже воду.
Редизайна чего? У нас ведь только код и есть. А его "редизайнить"
нельзя. Его можно только переписать. Или выбросить.
DN> Во-вторых, компоненты пишут независимо. Ну почти независимо - были бы
DN> интерфейсы. А интерфейсов к готовым компонентам и добавить не
DN> долго. 8-)
А откуда берутся интерфейсы? Их ISO издает? IEEE? Microsoft? ЦК КПСС?
И интерфейсы друг от друга тоже зависят.
[...]
>> Меня же на данном этапе больше интересует сложность "маленькая":
>> насколько система устойчива к тем изменениям, что я перечислил.
>> Устойчивость здесь определяется двумя факторами: неким "размером",
>> например количеством строк кода, которые нужно
>> добавить/исправить/выбросить и "усилиями" (effort), которые нужно
>> приложить, для того, чтобы это сделать. К сожалению, эти две величины
>> _до_ исполнения определить трудно. Точнее, прямо их определить просто
>> невозможно. Гадание на кофейной гуще меня не устраивает. Вот я и
>> пытаюсь ввести некий численный фактор, который бы хорошо коррелировал с
>> этими двумя величинами. Интуитивно, если представлять програмную
>> систему в виде направленного графа, мне ясно, что эти две величины
>> будут сильно зависить от того, насколько хорошо граф структурирован,
>> насколько хорошо соблюден баланс между изолированностью и
>> согласованностью разных кластеров в нем. Теперь яснее, какую величину
>> я ищу?
DN> Да понятно. И давно. 8-) Ну чего может быть интересно
DN> программисту. 8-) Только, во-первых, это дело подчиняется тем же
DN> принципам. Во-вторых, этого безмерно мало для реалий жизни
DN> корпоративного софта.
Давай сначала разберем эту маленькую часть, а потом будет браться за
большую.
DN> И к тому же модель уровня кода в компонентной архитектуре выглядит так
DN> же просто как реализация член-функций у ООП. Чего там философии
DN> разводить - скриптуй давай, налево и направо. Упрощая, можно сказать
DN> что тебе не так важно где тут дорога, если ты на танке. На маршрут,
DN> главным образом, влияет - куда тебя несет нелегкая. 8-)
"скриптуй давай, налево и направо"...
А потом телефонные сети выходят их строя, апаратура поддерки
жизнедеятельности вываливается в blue screen of death, миллиардные ракеты
взрываются при старте, а ракетные крейсера 2 часа 45 минут не могут
сдвинуться с места.
No way! Я жить в таком мире не хочу.
DN> Я хочу сказать что Сложность - это способ оценить там мы или не
DN> там. Это, если угодно, мера приемлимости. А вот отчего отсчитывать? И
DN> тут мы переходим к целевому управлению. Я не хочу сказать, что ты уже
DN> согласен с определением моей Сложности как единственно верной или
DN> очень нужной. 8-) Давай будем просто считать что она у тебя есть в
DN> голове во всей своей динамически/предсказательной красоте
DN> формулировки. 8-)
Нет у меня в голове этой формулировки. Я хочу ее иметь четкую и на
бумаге. Можно в электронном виде.
[...]
На остальное отвечу позже.
Andrey V Khavryutchenko
>>>>> "DN" == Dmitry Nogin writes:
DN> Предлагается считать, что six key quality goals must be achieved in order
DN> for a project to be considered successful.
DN> * Delivery within project constraints
DN> * Satisfied customers
DN> * Delivery to specifications based on user requirements
DN> * Release after knowing and addressing all issues
DN> * Enhanced user performance
DN> * Smooth deployment and ongoing management
[...]
DN> Давай вот тут определимся - согласен ли ты отсчитывать полезность того
DN> что делаешь на основании этих целей. Расценивая их, при том, как
DN> одинаково важные? Думаешь ли ты что есть какие-то не менее весомые
DN> факторы успеха?
Полезность, в смысле успеха проекта -- согласен, определяется этими
критериями. Но при чем здесь сложность?
Alex Kulikov
08 Aug 98 16:40, Alexander V. Didytch wrote to Dmitry Nogin:
AVD> Toecть ecли aрхитeктурнo cиcтeмa былa пocтрoeнa c _бoльшим зaпacoм_
AVD> тo _cлoжнocть_ пoддeржки IMHO нe будeт тaкoй уж бoльшoй.
Я извиняюсь, но _большой_ запас хоть в архитектуре, хоть нет, потребует
_дополнительных ресурсов_ (любого толка). Hадеюсь спорить о том что из ничего
ничего не создашь, не прийдется. Таким образом поднимает голову вопрос "А нафига
?" (в смысле оптимальный ли это вариант).
ЗЫ: Имно главный критерий качества продукта имно есть насколько оптимально (с
точки зрения клиента который платит денюжку) он изготовлен.
С уважением Alex aka Fatalex, всех благ на pаботе и в койке... ;-)
Alexander V. Didytch
13 Aug 98 04:56, Alex Kulikov wrote to Alexander V. Didytch:
AK> Я извиняюсь, но _большой_ запас хоть в архитектуре, хоть нет,
AK> потребует _дополнительных ресурсов_ (любого толка). Hадеюсь спорить о
AK> том что из ничего ничего не создашь, не прийдется. Таким образом
AK> поднимает голову вопрос "А нафига ?" (в смысле оптимальный ли это
AK> вариант).
He вceгдa и дaлeкo нe вceгдa -- вce зaвиcит oт тoгo кaк нa eнтo мaнaгeр
пocмoтрит -- Пeтя cидит нeдeлю и нифигa нe выдaeт -- жмeт ceбe нa кнoпки
и вce. A Вacя -- любитeль линeйнoгo кoдa тaк и вaлит фoрмaчкaми. В кoнцe
кoнцoв oни пoчeму-тo зaкaнчивaют рaбoту пoчти oднoврeмeннo. Ho кoгдa
прихoдит change request Пeтя трaтит нa этo минут 5-30 (тaм шaблoн пoдпрaвил,
тaм прaвилa ввoдa пoмeнял в oднoм мecтe) a Вacя тoрчит oт тoгo чтo eму
cut & paste нaд этими измeнeниями вoдить нaдo дoлгo и нуднo -- oдeнь
интeрecнaя и глaвнoe oщутимaя рeзультaтoм рaбoтa.
AK> ЗЫ: Имно главный критерий качества продукта имно есть насколько
AK> оптимально (с точки зрения клиента который платит денюжку) он
AK> изготовлен.
Пoддeржкoй ктo зaнимaeтcя -- клиeнт ? Ecли дa и нeт cooтв. трeбoвaний
в TЗ тo нeт вoпрocoв -- кaшa в кoдe, нeрaзбeрихa в иeрaрхии клaccoв
-- тaк зa мecяц дeшeвлe нaпиcaть cиcтeму ecли жe cрoк рaзрaбoтки
oт 3х мec и дaльшe -- тo я в тaкoй cрeдe рaбoтaть нe хoчу :)
(блин a прихoдитcя вeдь;)).