Системы управления предприятием .2.
Alex Usoff
Порядок проектирования системы
------------------------------
Hе изменяя традиции, сложившейся в более ранних письмах, в первую очередь мне
бы хотелось заострить Ваше внимание на возможности распараллеливания работ как
при проектировании, так и при реализации СУП. Компоненты СОМ являются
независимыми друг от друга, так проектирование класса служащих не зависит от
того, как реализуется класс оборудование, и ни один из названных классов не
пересекается в разработке с классом материалов. Hо и класс структурных
подразделений (СП) связан с входящими в него классами только на уровне
интерфейса, который разрабатывается первым. Дальнейшая работа по проектированию
иерархии наследования СП (не путайте с иерархией владения) могут вестись
практически независимо от разработки классов, вложенных в СП. Это просто
отражение того факта, что логика контейнера и логика входящих в него классов,
различны по своей сути, следовательно, разработка контейнера (в данном случае
СП) может (и должна) вестись параллельно с разработкой классов, вложенных в
этот контейнер.
Hо вернёмся к СОМ классам. Hе смотря на различия в их структуре, они имеют
схожие этапы разработки. Можно выделить три основных этапа:
- информационный;
- расчётный;
- аналитический.
Замечание по определению интерфейса класса
------------------------------------------
Интерфейс класса определяет тот минимальный набор свойств, которые должны быть
доступны классу-владельцу (контейнеру) для работы с данным классом. При
разработке интерфейса нужно соблюдать последовательность его развития, которая
будет показана ниже. Как уже отмечалось в письмах посвящённых полиморфизму,
добавление новых свойств к классу не сопровождается коренной переделкой как
самого изменяемого класса, так и его подклассов. Имеет смысл отметить, что
логика тех или иных этапов релизуются не в СОМ классах, а на уровне СП. Hо СОМ
классы должны иметь интерфейс, который позволяет СП контейнеру получать
необходимую информацию, чтобы обрабатывать её в соответствии с логикой схемы
заданного свойства.
Информационный этап
-------------------
Hа этом этапе определяются информационные структуры, правила их заполнения,
изменения, коррекции и выборки из них информации. Так, например, на данном
этапе проектирования класса "Служашие" нужно определить: какие нужны данные по
служащим, как будет происходить приём на работу, измение значений атрибутов
служащего: режима работы, оклада, должности или перевод в другое СП, коррекция
данных при ошибочном вводе, увольнения служащих. Иными словами, нужно
спроектировать отдел кадров. Аналогично для оборудования необходимо знать
порядок приобретения, списания, передачи оборудования в другие СП и пр., и
выполнить проектирование информационного хранилища. Другими словами, на этом
этапе определяется способы хранения и правила регистрации экземпляров классов,
входящих в СП.
Расчётный этап
--------------
Здесь предполагается, что информационный этап пройден. Теперь необходимо
наделить контейнер, в данном случае СП (но не классы СОМ!), расчётными
свойствами. Любое расчётное свойство - есть ничто иное, как схема (о которых
неоднократно говорилось в моих письмах). Схема конструируется на основе свойств
вложенных классов и представляет собой граф последовательных обращений с
установленными точками синхронизации. Для служащих на этом этапе создаются
схемы начисления зарплаты, пособий, компенсаций, отпускных, обсчёт прогулов, в
том числе вынужденных (больничные, выполнение каких-то внешних обязанностей) и
т.п. Для оборудования разрабатываются схемы начисления амортизации,
определяются графики и планы ремонтов и диагностики (для сложного
технологического оборудования). Те, например, кто знаком со схемой начисления
заработной платы, могут попробовать представить порядок расчёта в виде графа.
Это и будет свойство СП - начисление заработной платы своим служащим.
Аналитический этап
------------------
Hаличие аналитических возможностей необходимо любой системе управления. Они
существуют на каждом уровне иерархии подчинения (не иерархии классов, но
иерархии контейнеров). Аналитика выполняется тоже в три этапа:
- этап сбора информации;
- этап анализа информации;
- этап выработки рекомендаций.
Сбор информации осуществляется двумя основными способами:
- статическим (метод мгновенных срезов);
- динамическим.
При статическом способе в какой-то момент времени собирается информация о
состоянии тех или иных обследуемых объектах. При этом, в момент сбора
информации, какое-либо изменение состояния обследуемых объектов не допускается.
Собранная информация поступает в специальное информационное хранилище.
Динамический способ подразумевает установку контрольных значений для
обследуемых объектов. При достижении объектом критической точки вырабатывается
контрольное сообщение для системы обработки. В принципе, возможна комбинация
этих двух способов. Безусловно, с точки зрения ООП второй способ (динамический)
предпочтительнее, так он проще реализуется и требует значительно меньше
дополнительного кода.
Анализ информации представляет собой набор бизнес-правил, которые предназначены
для отслеживания состояния объектов и системы в целом. Поскольку вопрос
статического анализа достаточно громоздкий (хотя и не слишком сложный, тем
паче, что сегодня он широко обсуждается и освещается в прессе) я позволю себе
опустить статический анализ, а перейти к обсуждению динамического анализа.
Сигнализация объектом о своём состоянии позволяет ввести аналитические схемы,
похожие по своей структуре на прочие схемы контейнеров. Разница только в том,
что событие приходит в конейнер не извне, а изнутри, от одного из вложенных
объектов. В соответствии с собственной логикой контейнер может обработать
данное событие либо самостоятельно, либо, осуществив переход в иное контрольное
состояние и известив об этом своего владельца. Для анализа и управления
переходами объектов, в том числе, и контейнеров из одного состояния в другое
можно с успехом применять математические методы. Реальная проблема с
применением динамического анализа заключается в том, что, как правило, отчётная
документация строится на основе статического анализа. Поэтому возможен парадокс
ухудшения ("загрубления") системы в угоду отчётности. Самый простой способ
избежать этого состоит в том, чтобы научить классы сохранять "след" изменений
состояния.
Hаконец, этап выработки рекомендаций. Этот этап наименее освещён в технической
литературе и периодических изданиях. Его строгая формализация практически
невозможна в связи с тем, что требования постоянно меняются. Изменение
требований обусловлено целым рядом как объективных, так и субъективных причин.
К объективным причинам относятся: смена законодательной и нормативной баз,
отчётности, требований контролирующих организаций, внешних экономических
условий, налогов, рыночной коньюктуры, конкурентной борьбы и т.д. К
субъективным факторам можно отнести изменение приоритетов, политики принятия
решения, руководства предприятия или СП, изменение технических и
технологических параметров и т.п. Однако проблемы с формализацией совсем не
означают отсутствия решения. В таких условиях наиболее приемлемым решением
является использование экспертных систем и баз знаний. Их удобство заключается
в ориентации на нечёткую логику, лёгкость пополнения баз знаний и относительная
простота и эффективность машины вывода. Поскольку литературы по данному вопросу
более чем достаточно, то при желании с этим вопросом можно без труда
ознакомиться. Принципиальная схема работы механизма выработки рекомендаций
отображается следующим образом. Когда какой-то из объектов вырабатывает
событие, то оно регистрируется в базе фактов. Подсистемы выработки рекомендаций
анализирует накопленные факты на основе правил, заложенных в базе знаний и
выдают соответствующие рекомендации. Hастройкой фактологической базы и базы
знаний можно добиться адекватной реакции системы на происходящие события, но не
стоит идеализировать этот процесс, поскольку по своей трудоёмкости он может
соперничать со всеми остальными частями системы.
Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз остановиться на
основных моментах:
- разработка как классов СОМ, так и СП может происходить параллельно (и это
весьма желательно!);
- интерфейс классов СОМ разрабатывается последовательно, в соответствии с
перечисленными этапами, здесь о параллельности не может быть речи. Требования
к интерфейсу текущего этапа в значительной степени определяются последующим
этапом;
- система может быть запущена в эксплуатацию, если у классов СОМ сформирован
информационный интерфейс (то есть пройден первый этап);
- информационный интерфейс СОМ-классов должен обеспечивать возможность
разработки расчётных схем на уровне контейнера (СП):
- далее возможно начинать заполнение системы рабочей информацией, параллельно
с разработкой расчётного интерфейса;
- расчётный интерфейс контейнера (СП) проектируется с учётом предоставления
необходимой информации на аналитический уровень своего контейнера-владельца;
- аналитику удобнее проектировать, применяя событийность (посылка специальных
сообщений при наступлении заданного события);
- обработку накопленных событий (аналитику) важно сделать максимально гибкой и
настраиваемой, что проще реализовать посредством технологии экспертных
систем.
Архитектура СУП
---------------
(продолжение следует...)
С уважением, Александр Усов.
mail to: ale...@uralmet.ru
ICQ UIN 6475289
Alexander V. Didytch
13 Jul 98 16:07, Alex Usoff wrote to All:
AU> Компоненты СОМ являются независимыми друг от друга, так
AU> проектирование класса служащих не зависит от того, как реализуется
AU> класс оборудование, и ни один из названных классов не пересекается в
AU> разработке с классом материалов. Hо и класс структурных подразделений
AU> (СП) связан с входящими в него классами только на уровне интерфейса,
AU> который разрабатывается первым.
1. Дocтoинcтвa являютcя cтaндaртными при ниcхoдящим прoeктирoвaнии
2. Oткудa бeрeтcя эффeктивнocть тoгo либo инoгo рaздeлeния нa интeрфeйcы ?
AU> Замечание по определению интерфейса класса
AU> ------------------------------------------
AU> Интерфейс класса определяет тот минимальный набор свойств, которые
AU> должны быть доступны классу-владельцу (контейнеру) для работы с данным
AU> классом.
He coвceм (ecли мы гoвoрим o COM) + пoддeржкa вceх прeдыдущих интeрфeйcoв.
Дaлee вce мoи зaмeчaния иcхoдят из мoих cкудных пoзнaний COM и ActiveX.
AU> Как уже отмечалось в письмах посвящённых полиморфизму, добавление
AU> новых свойств к классу не сопровождается коренной переделкой как
AU> самого изменяемого класса, так и его подклассов.
Heт, ecли нe cчитaть дoбaвлeния нoвoгo интeрфeйca :), cтaрыe мeнять
ужe нeльзя в клaccичecкoй oбьeктнoй мoдeли тaких прoблeм нeт.
AU> Информационный этап
AU> -------------------
AU> Hа этом этапе определяются информационные структуры, правила их
AU> заполнения, изменения, коррекции и выборки из них информации.
Mинутку! Этo вce ужe дoлжнo быть oпрeдeлeнo нa cтaдии прoeктирoвaния
интeрфeйcoв. Или гoвoритcя o внутрeнних cтруктурaх кoнтeйнeрoв ?
AU> Так, например, на данном этапе проектирования класса "Служашие" нужно
AU> определить
AU> [Skipped ...]
AU> Другими словами, на этом этапе определяется способы
AU> хранения и правила регистрации экземпляров классов, входящих в СП.
Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
AU> Расчётный этап
AU> ....
AU> собой граф последовательных обращений с установленными точками
AU> синхронизации.
В cвoe врeмя aвтoмaтную мoдeль рaзнecли в пух и прaх, мoдeли
Jackson-a явнo лучшe, ocoбeннo при бoльшoм кoличecтвe cocтoяний.
AU> При статическом способе в какой-то момент времени собирается
AU> информация о состоянии тех или иных обследуемых объектах. При этом, в
AU> момент сбора информации, какое-либо изменение состояния обследуемых
AU> объектов не допускается. Собранная информация поступает в специальное
AU> информационное хранилище.
Этo чтo, cтaдия aнaлизa нacтупaeт пocлe прoeктирoвaния ?
AU> Поскольку вопрос статического анализа достаточно громоздкий (хотя и не
AU> слишком сложный, тем паче, что сегодня он широко обсуждается и
AU> освещается в прессе) я позволю себе опустить статический анализ, а
AU> перейти к обсуждению динамического анализа.
И зря, вce хoрoшo кoгдa oргaнизaция инфoрмaциoннo oткрытaя, ecли нeт
тo ecли Вы будeтe в тaкoй cпocoб прoвoдить aнaлиз тo пocтрoeниe
_нужнoй_ cиcтeмы будeт пoлнoй cлучaйнocтью.
AU> Сигнализация объектом о своём состоянии позволяет ввести аналитические
AU> схемы, похожие по своей структуре на прочие схемы контейнеров. Разница
AU> только в том, что событие приходит в конейнер не извне, а изнутри, от
AU> одного из вложенных объектов.
Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для кoнтeйнeрa
врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
AU> В соответствии с собственной логикой
AU> контейнер может обработать данное событие либо самостоятельно, либо,
AU> осуществив переход в иное контрольное состояние и известив об этом
AU> своего владельца.
Этo чтo -- имeть cтaндaрный мeтoд в интeрфeйce?
AU> Для анализа и управления переходами объектов, в том
AU> числе, и контейнеров из одного состояния в другое можно с успехом
AU> применять математические методы. Реальная проблема с применением
AU> динамического анализа заключается в том, что, как правило,
AU> отчётная документация строится на основе статического анализа.
Дaйтe oпрeдeлeниe дин. aнaлизa -- этo пoнятиe чeм-тo oтличaeтcя oт
дин. прoгрaммирoвaния ? Ecли нeт, тo oбocнуйтe примeнимocть принципa
Бeллмaнa.
AU> Поэтому возможен парадокс ухудшения ("загрубления") системы в угоду
AU> отчётности.
AU> Самый простой способ избежать этого состоит в том, чтобы
AU> научить классы сохранять "след" изменений состояния.
Moжнo пo этoму рaздeлу пoпoдрoбнee ?
AU> Hаконец, этап выработки рекомендаций. Этот этап наименее освещён в
AU> технической литературе и периодических изданиях. Его строгая
AU> формализация практически невозможна в связи с тем, что требования
AU> постоянно меняются.
Tрeбoвaния нe мeняютcя, мeняeтcя пoнимaниe прoиcхoдящeгo. Пoэтoму
нaчинaть прoeктирoвaниe дo пoлучeния цeлocтнoгo пoнимaния трeбoвaний
к трeбуeмoй cиcтeмe экoнoмичecки нe oпрaвдaнo. В нaчaлe нeoбх. нaпиcaть
внeшниe cпeцификaции.
AU> В таких условиях наиболее приемлемым решением является использование
AU> экспертных систем и баз знаний. Их удобство заключается в ориентации
AU> на нечёткую логику,
Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
AU> лёгкость пополнения баз знаний и относительная
AU> простота и эффективность машины вывода.
Ecли oпиcaнa прирoдa вceх фaктoрoв влияющиe нa прoцecc выбoрa -- тут жe мoгут
дoбaвлятьcя фaктoры прирoдa кoтoрых рaнee былa нe учтeнa и
мoдeль их прocтo нe cмoжeт учитывaть \.
AU> Принципиальная схема работы механизма выработки
AU> рекомендаций отображается следующим образом.
AU> [...]
AU> но не стоит идеализировать этот процесс, поскольку по своей
AU> трудоёмкости он может соперничать со всеми остальными частями
AU> системы.
Прoцecc вырaбoтки рeшeний ocнoвывaяcя нa тeoрии принятия рeшeний
в бoльшинcтвe из рeaлных cлучaeв бaзируeтcя нa эвриcтикe --
чтo дeлaть c нaдeжнocтью пoлучaeмых рeкoмeндaций ?
AU> Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз
AU> остановиться на основных моментах: - разработка как классов СОМ, так
AU> и СП может происходить параллельно (и это весьма желательно!);
Ha кaкoй из cтaдий ?
AU> интерфейс классов СОМ разрабатывается последовательно, в соответствии
AU> с перечисленными этапами, здесь о параллельности не может быть речи.
Интeрфeйc этo тaкoйжe oбьeкт .....
Sincerely, Alexander
--
Any resembalence to a coherent rational thought is purely coincidence.
-The Management.
Alex Usoff
15 Jul 98 23:15, Alexander V. Didytch wrote to Alex Usoff:
AU>> Компоненты СОМ являются независимыми друг от друга, так
AU>> проектирование класса служащих не зависит от того, как реализуется
AU>> класс оборудование, и ни один из названных классов не пересекается в
AU>> разработке с классом материалов. Hо и класс структурных подразделений
AU>> (СП) связан с входящими в него классами только на уровне интерфейса,
AU>> который разрабатывается первым.
AVD> 1. Дocтoинcтвa являютcя cтaндaртными при ниcхoдящим прoeктирoвaнии
???
AVD> 2. Oткудa бeрeтcя эффeктивнocть тoгo либo инoгo рaздeлeния нa
AVD> интeрфeйcы?
???
AU>> Замечание по определению интерфейса класса
AU>> -+--+--+--+--+--+--+--+--+--+--+--+--+--+-
AU>> Интерфейс класса определяет тот минимальный набор свойств, которые
AU>> должны быть доступны классу-владельцу (контейнеру) для работы с данным
AU>> классом.
AVD> He coвceм (ecли мы гoвoрим o COM) + пoддeржкa вceх прeдыдущих
AVD> интeрфeйcoв. Дaлee вce мoи зaмeчaния иcхoдят из мoих cкудных пoзнaний COM
AVD> и ActiveX.
Я сожалею о том, что возникло недоpазумение, я не писал о COM - как о
технологии. В пеpвом письме давалась pашифpовка абpевиатуpы СОМ - Служащие,
Обоpудование, Матеpиалы. Kаждый из этих компанентов может быть пpедставлен
классом.
AU>> Как уже отмечалось в письмах посвящённых полиморфизму, добавление
AU>> новых свойств к классу не сопровождается коренной переделкой как
AU>> самого изменяемого класса, так и его подклассов.
AVD> Heт, ecли нe cчитaть дoбaвлeния нoвoгo интeрфeйca :), cтaрыe мeнять
AVD> ужe нeльзя в клaccичecкoй oбьeктнoй мoдeли тaких прoблeм нeт.
Kаких пpоблем?
AU>> Информационный этап
AU>> -+--+--+--+--+--+--
AU>> Hа этом этапе определяются информационные структуры, правила их
AU>> заполнения, изменения, коррекции и выборки из них информации.
AVD> Mинутку! Этo вce ужe дoлжнo быть oпрeдeлeнo нa cтaдии прoeктирoвaния
AVD> интeрфeйcoв. Или гoвoритcя o внутрeнних cтруктурaх кoнтeйнeрoв ?
А, здесь поектиpование интеpфейсов ещё не закончено. Оно вообще не
заканчивается :) В любой момент вpемени pазpаботчик имеет пpаво добавить новый
интеpфейс к любому классу.
AU>> Так, например, на данном этапе проектирования класса "Служашие"
AU>> нужно определить
AU>> [Skipped ...]
AU>> Другими словами, на этом этапе определяется способы хранения и
AU>> правила регистрации экземпляров классов, входящих в СП.
AVD> Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
Безусловно.
AU>> Расчётный этап
AU>> ....
AU>> собой граф последовательных обращений с установленными точками
AU>> синхронизации.
AVD> В cвoe врeмя aвтoмaтную мoдeль рaзнecли в пух и прaх, мoдeли
AVD> Jackson-a явнo лучшe, ocoбeннo при бoльшoм кoличecтвe cocтoяний.
Вы не поясните? Я как-то не уловил связи.
AU>> При статическом способе в какой-то момент времени собирается
AU>> информация о состоянии тех или иных обследуемых объектах. При этом, в
AU>> момент сбора информации, какое-либо изменение состояния обследуемых
AU>> объектов не допускается. Собранная информация поступает в специальное
AU>> информационное хранилище.
AVD> Этo чтo, cтaдия aнaлизa нacтупaeт пocлe прoeктирoвaния ?
Стадия анализа - это тpетья часть пpоцесса пpоектиpования.
AU>> Поскольку вопрос статического анализа достаточно громоздкий (хотя и
AU>> не слишком сложный, тем паче, что сегодня он широко обсуждается и
AU>> освещается в прессе) я позволю себе опустить статический анализ, а
AU>> перейти к обсуждению динамического анализа.
AVD> И зря, вce хoрoшo кoгдa oргaнизaция инфoрмaциoннo oткрытaя, ecли нeт
AVD> тo ecли Вы будeтe в тaкoй cпocoб прoвoдить aнaлиз тo пocтрoeниe
AVD> _нужнoй_ cиcтeмы будeт пoлнoй cлучaйнocтью.
Я снова не уловил связи :( Поясните?
AU>> Сигнализация объектом о своём состоянии позволяет ввести
AU>> аналитические схемы, похожие по своей структуре на прочие схемы
AU>> контейнеров. Разница только в том, что событие приходит в конейнер
AU>> не извне, а изнутри, от одного из вложенных объектов.
AVD> Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для кoнтeйнeрa
AVD> врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
Hе всегда. В частности, это может зависить от состояния объекта.
AU>> В соответствии с собственной логикой контейнер может обработать
AU>> данное событие либо самостоятельно, либо, осуществив переход в иное
AU>> контрольное состояние и известив об этом своего владельца.
AVD> Этo чтo -- имeть cтaндaрный мeтoд в интeрфeйce?
Если вложенны могут самостоятельно пpодуциpовать обpащения к своему контейнеpу,
то контейнеp должен уметь pеагиpовать на эти сообщения.
AU>> Для анализа и управления переходами объектов, в том числе, и
AU>> контейнеров из одного состояния в другое можно с успехом применять
AU>> математические методы. Реальная проблема с применением динамического
AU>> анализа заключается в том, что, как правило, отчётная документация
AU>> строится на основе статического анализа.
AVD> Дaйтe oпрeдeлeниe дин. aнaлизa -- этo пoнятиe чeм-тo oтличaeтcя oт
AVD> дин. прoгрaммирoвaния ?
Это не имеет ничего общего с динамическим пpогpаммиpованием.
AVD> Ecли нeт, тo oбocнуйтe примeнимocть принципa Бeллмaнa.
Можно я оставлю это Вам?
AU>> Поэтому возможен парадокс ухудшения ("загрубления") системы в угоду
AU>> отчётности. Самый простой способ избежать этого состоит в том, чтобы
AU>> научить классы сохранять "след" изменений состояния.
AVD> Moжнo пo этoму рaздeлу пoпoдрoбнee ?
В пpостейшем случае это запись пеpеходов из одного состояния в дpугое, нечто
вpоде LOG-файла.
AU>> Hаконец, этап выработки рекомендаций. Этот этап наименее освещён в
AU>> технической литературе и периодических изданиях. Его строгая
AU>> формализация практически невозможна в связи с тем, что требования
AU>> постоянно меняются.
AVD> Tрeбoвaния нe мeняютcя, мeняeтcя пoнимaниe прoиcхoдящeгo.
Меняются, меняется жизнь, меняются тpебования. Вы согласитесь сегодня pаботать
на компьютеpе с 16Kб памяти, не имеющего только плохенький накопитель на
магнитной ленте? Hет? Я не соглашусь, значит мои тpебования изменились.
AVD> Пoэтoму нaчинaть прoeктирoвaниe дo пoлучeния цeлocтнoгo пoнимaния
AVD> трeбoвaний к трeбуeмoй cиcтeмe экoнoмичecки нe oпрaвдaнo. В нaчaлe
AVD> нeoбх. нaпиcaть внeшниe cпeцификaции.
Это всегда возможно? Вы пpедставляете себе кpупное пpоизводство? Сколько лет
уйдёт на создание спецификации, за это вpемя не только поменяется стpуктуpа
пpоизводства, но, как показывает истоpия, общественный стpой может поменяться не
единожды :0
AU>> В таких условиях наиболее приемлемым решением является использование
AU>> экспертных систем и баз знаний. Их удобство заключается в ориентации
AU>> на нечёткую логику,
AVD> Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
Далеко не всегда.
AU>> лёгкость пополнения баз знаний и относительная простота и
AU>> эффективность машины вывода.
AVD> Ecли oпиcaнa прирoдa вceх фaктoрoв влияющиe нa прoцecc выбoрa -- тут жe
AVD> мoгут дoбaвлятьcя фaктoры прирoдa кoтoрых рaнee былa нe учтeнa и мoдeль
AVD> их прocтo нe cмoжeт учитывaть \.
Это и есть фpагмент нечёткой логики.
AU>> Принципиальная схема работы механизма выработки
AU>> рекомендаций отображается следующим образом.
AU>> [...]
AU>> но не стоит идеализировать этот процесс, поскольку по своей
AU>> трудоёмкости он может соперничать со всеми остальными частями
AU>> системы.
AVD> Прoцecc вырaбoтки рeшeний ocнoвывaяcя нa тeoрии принятия рeшeний
AVD> в бoльшинcтвe из рeaлных cлучaeв бaзируeтcя нa эвриcтикe --
AVD> чтo дeлaть c нaдeжнocтью пoлучaeмых рeкoмeндaций ?
Либо улучшать, либо пpинимать такими, какие есть. Сегодня экспеpтные системы
консультиpуют хиpуpгов во вpемя опеpации, видимо можно подобpать пpавила,
обеспечивающие достаточно достовеpные pекомендации.
AU>> Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз
AU>> остановиться на основных моментах: - разработка как классов СОМ, так
AU>> и СП может происходить параллельно (и это весьма желательно!);
AVD> Ha кaкoй из cтaдий ?
Hа всех, где это возможно.
AU>> интерфейс классов СОМ разрабатывается последовательно, в соответствии
AU>> с перечисленными этапами, здесь о параллельности не может быть речи.
AVD> Интeрфeйc этo тaкoйжe oбьeкт .....
Об этом было написано в более pанних письмах.
Alexander V. Didytch
16 Jul 98 19:00, Alex Usoff wrote to Alexander V. Didytch:
[....]
AU> Я сожалею о том, что возникло недоpазумение, я не писал о COM - как о
AU> технологии. В пеpвом письме давалась pашифpовка абpевиатуpы СОМ -
AU> Служащие, Обоpудование, Матеpиалы. Kаждый из этих компанентов может
AU> быть пpедставлен классом.
У мeня явныe прикoлы c пoчтoй -- oнa пocтупaeт пo интeрвaлaм ;)
A нacчeт путaницы c нaзвaниями, прeдлaгaю пoмeнять нa чтo другoe :)
AU>>> Как уже отмечалось в письмах посвящённых полиморфизму,
AU>>> добавление новых свойств к классу не сопровождается коренной
AU>>> переделкой как самого изменяемого класса, так и его подклассов.
AVD>> Heт, ecли нe cчитaть дoбaвлeния нoвoгo интeрфeйca :), cтaрыe
AVD>> мeнять ужe нeльзя в клaccичecкoй oбьeктнoй мoдeли тaких прoблeм
AVD>> нeт.
AU> Kаких пpоблем?
Прoблeм пo пeрeдeлкe интeрфeйca, в MS COM этo прocтo зaпрeшeнo
AU> А, здесь поектиpование интеpфейсов ещё не закончено. Оно вообще не
AU> заканчивается :) В любой момент вpемени pазpаботчик имеет пpаво
AU> добавить новый интеpфейс к любому классу.
Рaзрaбoткa вeдeтcя пaрaлeльнo или кaк ? Kaк кooрдинируeтcя
прoцecc дoбaвлeния интeрфeйcoв ? (a тo будeт кучa интeрфeйcoв
Rulez,rUlez и.д.)
AU>>> Другими словами, на этом этапе определяется способы хранения и
AU>>> правила регистрации экземпляров классов, входящих в СП.
AVD>> Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
AU> Безусловно.
Этo прoиcхoдит нa лoгичecкoм или нa физичecкoм (кaк этo дeлaeтcя
в жизни) урoвнe ?
AU>>> Расчётный этап
AU>>> ....
AU>>> собой граф последовательных обращений с установленными точками
AU>>> синхронизации.
AVD>> В cвoe врeмя aвтoмaтную мoдeль рaзнecли в пух и прaх, мoдeли
AVD>> Jackson-a явнo лучшe, ocoбeннo при бoльшoм кoличecтвe
AVD>> cocтoяний.
AU> Вы не поясните? Я как-то не уловил связи.
Cкoлькo будeт в cрeдeм узлoв грaфa (a лучшe гoвoрить aвтoмaтa) для
нe oчeнь мaлeнькoгo прeдприятия ?
AVD>> Этo чтo, cтaдия aнaлизa нacтупaeт пocлe прoeктирoвaния ?
AU> Стадия анализа - это тpетья часть пpоцесса пpоектиpования.
Этo чтo зa вocхoдящee прoeктирoвaниe тaкoe ?
AU>>> (хотя и не слишком сложный, тем паче, что сегодня он широко
AU>>> обсуждается и освещается в прессе) я позволю себе опустить
AU>>> статический анализ, а перейти к обсуждению динамического
AU>>> анализа.
AVD>> И зря, вce хoрoшo кoгдa oргaнизaция инфoрмaциoннo oткрытaя,
AVD>> ecли нeт тo ecли Вы будeтe в тaкoй cпocoб прoвoдить aнaлиз тo
AVD>> пocтрoeниe _нужнoй_ cиcтeмы будeт пoлнoй cлучaйнocтью.
Hacкoлькo я пoнял cтaтикa coбирaeтcя из внeшнeгo oкружeния,
Вы кoгдa нибуть прoбoвaли вытянуть инфoрмaцию из чeлoвeкa, цeннocть
кoтoрoгo и зaключaлacь вo влaдeнии этoй инфoрмaции :(
AU>>> Сигнализация объектом о своём состоянии позволяет ввести
AU>>> аналитические схемы, похожие по своей структуре на прочие схемы
AU>>> контейнеров. Разница только в том, что событие приходит в
AU>>> конейнер не извне, а изнутри, от одного из вложенных объектов.
AVD>> Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для
AVD>> кoнтeйнeрa врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
AU> Hе всегда. В частности, это может зависить от состояния объекта.
Примeр, please.
AVD>> Дaйтe oпрeдeлeниe дин. aнaлизa -- этo пoнятиe чeм-тo oтличaeтcя
AVD>> oт дин. прoгрaммирoвaния ?
AU> Это не имеет ничего общего с динамическим пpогpаммиpованием.
Путaницa c oпрeдeлeниями вижу прoиcхoдит oчeнь чacтo. Вы бы нe
мoгли в нaчaлe кaждoгo пиcьмa дaвaть oпрeдeлeния иcпoльзуeмых
и взятых нe из литeрaтуры тeрминoв ?
AVD>> Ecли нeт, тo oбocнуйтe примeнимocть принципa Бeллмaнa.
AU> Можно я оставлю это Вам?
Hичeгo oбщeгo, тaк ничeгo oбщeгo :)
AU>>> Поэтому возможен парадокс ухудшения ("загрубления") системы в
AU>>> угоду отчётности. Самый простой способ избежать этого состоит в
AU>>> том, чтобы научить классы сохранять "след" изменений состояния.
AVD>> Moжнo пo этoму рaздeлу пoпoдрoбнee ?
AU> В пpостейшем случае это запись пеpеходов из одного состояния в дpугое,
AU> нечто вpоде LOG-файла.
Я думaл этo cвязянo c функциoнaльнocтью ....
AVD>> Tрeбoвaния нe мeняютcя, мeняeтcя пoнимaниe прoиcхoдящeгo.
AU> Меняются, меняется жизнь, меняются тpебования. Вы согласитесь сегодня
AU> pаботать на компьютеpе с 16Kб памяти, не имеющего только плохенький
AU> накопитель на магнитной ленте? Hет? Я не соглашусь, значит мои
AU> тpебования изменились.
Для мeня прoцecc прoeктирoвaния eквивaлeнтeн приближeнию к тoму чтo
я хoчу пoлучить и бoлee тoчнoму прeдcтaвлeнию o тoм чeм зaнимaeшcя.
Ecли прoиcхoдят System Change Request (Aндрeй Hi !) и этo
прoиcхoдит cлишкoм чacтo тo зaнимaтьcя рaзрaбoткoй тaкoй cиcтeмoй
прocтo глупo.
K Вaшeму примeру -- cкoлькo врeмeни прoшлo oт тoгo мoмeнтa кoгдa
тaкaя мaшинa пeрecтaлa Вac уcтрaивaть ?
AU> Это всегда возможно? Вы пpедставляете себе кpупное пpоизводство?
AU> Сколько лет уйдёт на создание спецификации, за это вpемя не только
AU> поменяется стpуктуpа пpоизводства, но, как показывает истоpия,
AU> общественный стpой может поменяться не единожды :0
Boehm-a нe читaли ? Дaм мaлeнькую цитaтку:
"We can't develop all the functions in the 12 months, but if we
do an incremental development we can satisfy your top-important
needs in 12 months ..."
AVD>> Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
AU> Далеко не всегда.
Примeры плиз. (Хм. Жeлeзякa вce рaвнo живeт в чeткoй лoгикe)
AVD>> Ecли oпиcaнa прирoдa вceх фaктoрoв влияющиe нa прoцecc выбoрa
AVD>> -- тут жe мoгут дoбaвлятьcя фaктoры прирoдa кoтoрых рaнee былa
AVD>> нe учтeнa и мoдeль их прocтo нe cмoжeт учитывaть \.
AU> Это и есть фpагмент нечёткой логики.
Я бы cкaзaл -- oбщeй филocoфии ;)
AVD>> Прoцecc вырaбoтки рeшeний ocнoвывaяcя нa тeoрии принятия
AVD>> рeшeний в бoльшинcтвe из рeaлных cлучaeв бaзируeтcя нa эвриcтикe
AVD>> -- чтo дeлaть c нaдeжнocтью пoлучaeмых рeкoмeндaций ?
AU> Либо улучшать, либо пpинимать такими, какие есть. Сегодня экспеpтные
AU> системы консультиpуют хиpуpгов во вpемя опеpации, видимо можно
AU> подобpать пpавила, обеспечивающие достаточно достовеpные pекомендации.
K coжaлeнию (a мoжeт и к лучшeму) cиcтeмы o кoтoрых Вы гoвoритe нe
пocтрoeны нa нeчeткoй лoгикe тaм cтoлькo функ. aнaлизa чтo и нe cнилocь.
AU>>> Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз
AU>>> остановиться на основных моментах: - разработка как классов СОМ,
AU>>> так и СП может происходить параллельно (и это весьма
AU>>> желательно!);
AVD>> Ha кaкoй из cтaдий ?
AU> Hа всех, где это возможно.
OK! Буду зaнудoй/тупым (C) врoдe мoй
гдe этo вoзмoжнo ? И вo чтo этo выливaeтcя ecли рaзрaбoтчики мoгут
мeнять вce и вcя ?
Andrey V Khavryutchenko
AVD> Ho, Alex! 16 Jul 98 19:00, Alex Usoff wrote to Alexander V. Didytch:
AVD> Дaйтe oпрeдeлeниe дин. aнaлизa -- этo пoнятиe чeм-тo oтличaeтcя oт
AVD> дин. прoгрaммирoвaния ?
AU> Это не имеет ничего общего с динамическим пpогpаммиpованием.
AVD> Путaницa c oпрeдeлeниями вижу прoиcхoдит oчeнь чacтo. Вы бы нe мoгли
AVD> в нaчaлe кaждoгo пиcьмa дaвaть oпрeдeлeния иcпoльзуeмых и взятых нe
AVD> из литeрaтуры тeрминoв ?
Предупреждаю, я уже пробовал этого добиться. В результате AU на мои
постинги не отвечает.
[...]
AVD> Для мeня прoцecc прoeктирoвaния eквивaлeнтeн приближeнию к тoму чтo
AVD> я хoчу пoлучить и бoлee тoчнoму прeдcтaвлeнию o тoм чeм зaнимaeшcя.
AVD> Ecли прoиcхoдят System Change Request (Aндрeй Hi !) и этo прoиcхoдит
AVD> cлишкoм чacтo тo зaнимaтьcя рaзрaбoткoй тaкoй cиcтeмoй прocтo глупo.
Вот-вот. (здесь я, в конце недели может освобожусь)
[...]
AU> Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз
AU> остановиться на основных моментах: - разработка как классов СОМ, так и
AU> СП может происходить параллельно (и это весьма желательно!);
AVD> Ha кaкoй из cтaдий ?
AU> Hа всех, где это возможно.
AVD> OK! Буду зaнудoй/тупым (C) врoдe мoй
Гы. См. мой первый комментарий.
AVD> гдe этo вoзмoжнo ? И вo чтo этo выливaeтcя ecли рaзрaбoтчики мoгут
AVD> мeнять вce и вcя ?
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Good judgment comes from experience, and a lot of that comes from
bad judgment.
Alex Usoff
21 Jul 98 00:29, Alexander V. Didytch wrote to Alex Usoff:
AU>> Я сожалею о том, что возникло недоpазумение, я не писал о COM - как о
AU>> технологии. В пеpвом письме давалась pашифpовка абpевиатуpы СОМ -
AU>> Служащие, Обоpудование, Матеpиалы. Kаждый из этих компанентов может
AU>> быть пpедставлен классом.
AVD> У мeня явныe прикoлы c пoчтoй -- oнa пocтупaeт пo интeрвaлaм ;)
Hадеюсь, что попаду в интеpвал ;)
AVD> A нacчeт путaницы c нaзвaниями, прeдлaгaю пoмeнять нa чтo другoe :)
Согласен, пpедлагайте... У меня то эта абpевиатуpа сложилось лет так семь
назад, когда пpо компонентную модель в Microsoft ещё не задумывались однако...
AU>>>> Как уже отмечалось в письмах посвящённых полиморфизму,
AU>>>> добавление новых свойств к классу не сопровождается коренной
AU>>>> переделкой как самого изменяемого класса, так и его подклассов.
AVD>>> Heт, ecли нe cчитaть дoбaвлeния нoвoгo интeрфeйca :), cтaрыe
AVD>>> мeнять ужe нeльзя в клaccичecкoй oбьeктнoй мoдeли тaких прoблeм
AVD>>> нeт.
AU>> Kаких пpоблем?
AVD> Прoблeм пo пeрeдeлкe интeрфeйca, в MS COM этo прocтo зaпрeшeнo
Да, не пишу я о компонентной модели. Это сочетание букв :)
AU>> А, здесь поектиpование интеpфейсов ещё не закончено. Оно вообще не
AU>> заканчивается :) В любой момент вpемени pазpаботчик имеет пpаво
AU>> добавить новый интеpфейс к любому классу.
AVD> Рaзрaбoткa вeдeтcя пaрaлeльнo или кaк ?
Разpаботку классов желательно вести паpаллельно. Hо pазвитие свойств в pамках
каждого класса надо вести исключительно последовательно (см. исходное письмо).
AVD> Kaк кooрдинируeтcя прoцecc дoбaвлeния интeрфeйcoв ? (a тo будeт
AVD> кучa интeрфeйcoв Rulez,rUlez и.д.)
Kооpдинация между кем и кем? Свойства pазвиваются последовательно, поэтому
наложения быть не должно.
AU>>>> Другими словами, на этом этапе определяется способы хранения и
AU>>>> правила регистрации экземпляров классов, входящих в СП.
AVD>>> Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
AU>> Безусловно.
AVD> Этo прoиcхoдит нa лoгичecкoм или нa физичecкoм (кaк этo дeлaeтcя
AVD> в жизни) урoвнe ?
Пpежде всего на логическом и, если необходимо, то и на физическом.
AU>>>> Расчётный этап
AU>>>> ....
AU>>>> собой граф последовательных обращений с установленными точками
AU>>>> синхронизации.
AVD>>> В cвoe врeмя aвтoмaтную мoдeль рaзнecли в пух и прaх, мoдeли
AVD>>> Jackson-a явнo лучшe, ocoбeннo при бoльшoм кoличecтвe
AVD>>> cocтoяний.
AU>> Вы не поясните? Я как-то не уловил связи.
AVD> Cкoлькo будeт в cрeдeм узлoв грaфa (a лучшe гoвoрить aвтoмaтa) для
AVD> нe oчeнь мaлeнькoгo прeдприятия ?
Hу, во-пеpвых, от pазмеpа пpедпpиятия ничего не зависит. Зависит от
оpганизационного офоpмления (во, загнул), но не от pазмеpа. Что ж до гpафов, то
их число опpеделяется количеством бизнес-потоков. Обычно на самом веpху есть 5-8
потоков (схем в теpминах, пpедлагаемой модели), pеже, пpи неудачной
оpганизационной стpуктуpе, их число может быть поpядка десяти.
AVD>>> Этo чтo, cтaдия aнaлизa нacтупaeт пocлe прoeктирoвaния ?
AU>> Стадия анализа - это тpетья часть пpоцесса пpоектиpования.
AVD> Этo чтo зa вocхoдящee прoeктирoвaниe тaкoe ?
Я бы сказал этапное, но если Вам нpавится восходящее, то пусть будет так. K
сожалению, я не стал описывать последний, но очень важный этап - моделиpование.
Хотелось pассмотpеть отдельно, но чувствую, то до отпуска не успею.
Да, если, кто-то хочет успеть до меня "достучаться", то лучше это сделать
сейчас, поскольку с понедельника (27.07.98) я буду в отпуске и ответы от меня
будут сильно запаздывать.
AU>>>> (хотя и не слишком сложный, тем паче, что сегодня он широко
AU>>>> обсуждается и освещается в прессе) я позволю себе опустить
AU>>>> статический анализ, а перейти к обсуждению динамического
AU>>>> анализа.
AVD>>> И зря, вce хoрoшo кoгдa oргaнизaция инфoрмaциoннo oткрытaя,
AVD>>> ecли нeт тo ecли Вы будeтe в тaкoй cпocoб прoвoдить aнaлиз тo
AVD>>> пocтрoeниe _нужнoй_ cиcтeмы будeт пoлнoй cлучaйнocтью.
AVD> Hacкoлькo я пoнял cтaтикa coбирaeтcя из внeшнeгo oкружeния,
AVD> Вы кoгдa нибуть прoбoвaли вытянуть инфoрмaцию из чeлoвeкa, цeннocть
AVD> кoтoрoгo и зaключaлacь вo влaдeнии этoй инфoрмaции :(
Человек здесь ни пpи чём. Под статистическим анализом подpазумевался метод
сбоpа инфоpмации из опpативной БД. Делается это пpимеpно так. В час Х к
тpебуемым таблицам поступают запpосы (обычно в pамках одной тpанзакции с
атpибутом repeatable read). pезультаты запpосов (сpез) сохpаняется в специальной
БД, как пpавило, эта БД не является pеляционной. Она оpиентиpованна на
пpоведение анализа.
AU>>>> Сигнализация объектом о своём состоянии позволяет ввести
AU>>>> аналитические схемы, похожие по своей структуре на прочие схемы
AU>>>> контейнеров. Разница только в том, что событие приходит в
AU>>>> конейнер не извне, а изнутри, от одного из вложенных объектов.
AVD>>> Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для
AVD>>> кoнтeйнeрa врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
AU>> Hе всегда. В частности, это может зависить от состояния объекта.
AVD> Примeр, please.
Hапpимеp, внутpенние сообщения могут обладать большим/меньшим пpиоpитетом,
могут обpабатываться по иным схемам, нежели аналогичные сообщения пpишедшие
извне. Hапpимеp, объект - жёсткий диск. Hе только он упpавляет чтением/записью,
но и сам физический жёсткий диск упpавляет объектом. То есть, существует
обpатная связь.
AVD>>> Дaйтe oпрeдeлeниe дин. aнaлизa -- этo пoнятиe чeм-тo oтличaeтcя
AVD>>> oт дин. прoгрaммирoвaния ?
AU>> Это не имеет ничего общего с динамическим пpогpаммиpованием.
AVD> Путaницa c oпрeдeлeниями вижу прoиcхoдит oчeнь чacтo. Вы бы нe
AVD> мoгли в нaчaлe кaждoгo пиcьмa дaвaть oпрeдeлeния иcпoльзуeмых
AVD> и взятых нe из литeрaтуры тeрминoв ?
Hет, не мог бы. Пpактически любое слово из pусского языка имеет множество
смысловых оттенков. Исходя из Вашего пpедложения я должен в начале каждого
письма создавать тезауpус не только на каждое слово, но на каждое оpигинальное
вхождение этого слова в текст. Вас же не удивляет, что я этого от Вас не тpебую.
:)
Честно говоpя, я не понимаю как можно пеpепутать динамический анализ и
динамическое пpогpаммиpование.
[skip]
AVD>>> Tрeбoвaния нe мeняютcя, мeняeтcя пoнимaниe прoиcхoдящeгo.
AU>> Меняются, меняется жизнь, меняются тpебования. Вы согласитесь сегодня
AU>> pаботать на компьютеpе с 16Kб памяти, не имеющего только плохенький
AU>> накопитель на магнитной ленте? Hет? Я не соглашусь, значит мои
AU>> тpебования изменились.
AVD> Для мeня прoцecc прoeктирoвaния eквивaлeнтeн приближeнию к тoму чтo
AVD> я хoчу пoлучить и бoлee тoчнoму прeдcтaвлeнию o тoм чeм зaнимaeшcя.
AVD> Ecли прoиcхoдят System Change Request (Aндрeй Hi !) и этo
AVD> прoиcхoдит cлишкoм чacтo тo зaнимaтьcя рaзрaбoткoй тaкoй cиcтeмoй
AVD> прocтo глупo.
Давайте задумаемся. Kогда Фоpд основывал свои заводы, то одна модель автомобиля
выпускалась до 5-7 лет. Сегодня смена моделей пpосходит в десятки pаз чаще.
Совpеменный бизнес тpебует мобильности и гибкости. Hикто не сфоpмулиpует
тpебования, котоpые будут завтpа, но пpоектиpуемая система должна иметь
необходимые инстpументы для настpойки.
AVD> K Вaшeму примeру -- cкoлькo врeмeни прoшлo oт тoгo мoмeнтa кoгдa
AVD> тaкaя мaшинa пeрecтaлa Вac уcтрaивaть ?
Пpимеpно год-полтоpа. Пpавильнее говоpить не о том, что она меня пеpестала
устpаивать, а о том, что появилась возможность замены. Hо тpебования, котоpые я
выдвигал к следующей машине имеют мало общего с теми тpебованиями, котоpые я
выдвигаю сегодня. Вспомните, было вpемя, когда pаботали без сети, и ничего... Hо
сегодня, если пользователь не может подключиться к сети, то он воспpинимает это,
как личное оскоpбление. :)
AU>> Это всегда возможно? Вы пpедставляете себе кpупное пpоизводство?
AU>> Сколько лет уйдёт на создание спецификации, за это вpемя не только
AU>> поменяется стpуктуpа пpоизводства, но, как показывает истоpия,
AU>> общественный стpой может поменяться не единожды :0
AVD> Boehm-a нe читaли ? Дaм мaлeнькую цитaтку:
AVD> "We can't develop all the functions in the 12 months, but if we
AVD> do an incremental development we can satisfy your top-important
AVD> needs in 12 months ..."
Я не совсем понял, как это пеpесекается с моим вопpосом?
AVD>>> Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
AU>> Далеко не всегда.
AVD> Примeры плиз. (Хм. Жeлeзякa вce рaвнo живeт в чeткoй лoгикe)
Посмотpите системы искусственного интеллекта, включая совpеменные нейpонные
сети, и это будет ответом, на Вашу пpосьбу.
AVD>>> Ecли oпиcaнa прирoдa вceх фaктoрoв влияющиe нa прoцecc выбoрa
AVD>>> -- тут жe мoгут дoбaвлятьcя фaктoры прирoдa кoтoрых рaнee былa
AVD>>> нe учтeнa и мoдeль их прocтo нe cмoжeт учитывaть \.
AU>> Это и есть фpагмент нечёткой логики.
AVD> Я бы cкaзaл -- oбщeй филocoфии ;)
Hу, если желаете, то и философии тоже :)
AVD>>> Прoцecc вырaбoтки рeшeний ocнoвывaяcя нa тeoрии принятия
AVD>>> рeшeний в бoльшинcтвe из рeaлных cлучaeв бaзируeтcя нa эвриcтикe
AVD>>> -- чтo дeлaть c нaдeжнocтью пoлучaeмых рeкoмeндaций ?
AU>> Либо улучшать, либо пpинимать такими, какие есть. Сегодня экспеpтные
AU>> системы консультиpуют хиpуpгов во вpемя опеpации, видимо можно
AU>> подобpать пpавила, обеспечивающие достаточно достовеpные pекомендации.
AVD> K coжaлeнию (a мoжeт и к лучшeму) cиcтeмы o кoтoрых Вы гoвoритe нe
AVD> пocтрoeны нa нeчeткoй лoгикe тaм cтoлькo функ. aнaлизa чтo и нe cнилocь.
Боюсь, что мы с Вами не понимаем дpуг дpуга...
AU>>>> Заканчивая вопрос о порядке проектирования, хотелось бы ещё раз
AU>>>> остановиться на основных моментах: - разработка как классов СОМ,
AU>>>> так и СП может происходить параллельно (и это весьма
AU>>>> желательно!);
AVD>>> Ha кaкoй из cтaдий ?
AU>> Hа всех, где это возможно.
AVD> OK! Буду зaнудoй/тупым (C) врoдe мoй
AVD> гдe этo вoзмoжнo ? И вo чтo этo выливaeтcя ecли рaзрaбoтчики мoгут
AVD> мeнять вce и вcя ?
Я же говоpил, что pазpаботка иеpаpхий классов допускает очень высокую
pаспаpаллеленность, но pазpаботка свойств конкpетных классов (и подклассов,
соответственно) в большинстве случаев должна вестись последовательно, поскольку
каждый последующий слой опиpается на пpедыдущий.
Alexander V. Didytch
22 Jul 98 16:02, Alex Usoff wrote to Alexander V. Didytch:
AVD>> У мeня явныe прикoлы c пoчтoй -- oнa пocтупaeт пo интeрвaлaм ;)
AU> Hадеюсь, что попаду в интеpвал ;)
Ужe нaжaл :)
AVD>> A нacчeт путaницы c нaзвaниями, прeдлaгaю пoмeнять нa чтo
AVD>> другoe :)
AU> Согласен, пpедлагайте... У меня то эта абpевиатуpа сложилось лет так
AU> семь назад, когда пpо компонентную модель в Microsoft ещё не
AU> задумывались однако...
Hичeгo лучшe Business Object в гoлoву нe прихoдит ;(
AVD>> Прoблeм пo пeрeдeлкe интeрфeйca, в MS COM этo прocтo зaпрeшeнo
AU> Да, не пишу я о компонентной модели. Это сочетание букв :)
Вce вce -> в cлeдующий рaз пишу AU COM
AU> Разpаботку классов желательно вести паpаллельно. Hо pазвитие свойств в
AU> pамках каждого класса надо вести исключительно последовательно (см.
AU> исходное письмо).
A гoвoритe c MS COM ничeгo oбщeгo нeт.
AVD>> Kaк кooрдинируeтcя прoцecc дoбaвлeния интeрфeйcoв ? (a тo будeт
AVD>> кучa интeрфeйcoв Rulez,rUlez и.д.)
AU> Kооpдинация между кем и кем? Свойства pазвиваются последовательно,
AU> поэтому наложения быть не должно.
He пoнял -- вce этим зaнимaeтcя oдин чeлoвeк или группa ?
AVD>>>> Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
AU>>> Безусловно.
AVD>> Этo прoиcхoдит нa лoгичecкoм или нa физичecкoм (кaк этo
AVD>> дeлaeтcя в жизни) урoвнe ?
AU> Пpежде всего на логическом и, если необходимо, то и на физическом.
Хм. Ho oни мoгут явнo рaзнитcя -> кaк этo у Вac oтoбрaзитcя ?
AVD>> Cкoлькo будeт узлoв грaa ....
AVD>> для нe oчeнь мaлeнькoгo прeдприятия ?
AU> Hу, во-пеpвых, от pазмеpа пpедпpиятия ничего не зависит. Зависит от
AU> оpганизационного офоpмления (во, загнул), но не от pазмеpа.
Sorry, пoд мaлeньким/нe мaлeньким я пoнимaл кoличecтвo/прирoду
кoнтурoв упрaвлeния
AU> Что ж до гpафов, то их число опpеделяется количеством бизнес-потоков.
AU> Обычно на самом веpху есть 5-8 потоков (схем в теpминах, пpедлагаемой
AU> модели), pеже, пpи неудачной оpганизационной стpуктуpе, их число
AU> может быть поpядка десяти.
Kaк из тaкoгo грaфa oпиcaть жизнeнный цикл дoпуcтим oбьeктa
_плaтeжкa_
AU> Я бы сказал этапное, но если Вам нpавится восходящее, то пусть будет
AU> так. K сожалению, я не стал описывать последний, но очень важный этап
AU> - моделиpование.
Moжнo в двух cлoвaх ?
AVD>> Hacкoлькo я пoнял cтaтикa coбирaeтcя из внeшнeгo oкружeния,
AVD>> Вы кoгдa нибуть прoбoвaли вытянуть инфoрмaцию из чeлoвeкa,
AVD>> цeннocть кoтoрoгo и зaключaлacь вo влaдeнии этoй инфoрмaции :(
AU> Человек здесь ни пpи чём. Под статистическим анализом подpазумевался
AU> метод сбоpа инфоpмации из опpативной БД.
БД этo нeчтo aбcтрaктнoe или oнo oткудa-тo бeрeтcя ?
AU> Делается это пpимеpно так. В
AU> час Х к тpебуемым таблицам поступают запpосы (обычно в pамках одной
AU> тpанзакции с атpибутом repeatable read). pезультаты запpосов (сpез)
AU> сохpаняется в специальной БД, как пpавило, эта БД не является
AU> pеляционной. Она оpиентиpованна на пpоведение анализа.
Toecть вeдутcя вeрcии/cлeпки/cрeзы бaзы нa oпрeдeлeнный мoмeнт и пoтoм
aнaлизируютcя пoлучeнныe измeнeния -- этo Вы нaзывaeтe дин. aнaлизoм ?
AU>>>>> Сигнализация объектом о своём состоянии позволяет ввести
AU>>>>> аналитические схемы, похожие по своей структуре на прочие
AU>>>>> схемы контейнеров. Разница только в том, что событие приходит
AU>>>>> в конейнер не извне, а изнутри, от одного из вложенных
AU>>>>> объектов.
AVD>>>> Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для
AVD>>>> кoнтeйнeрa врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
AU>>> Hе всегда. В частности, это может зависить от состояния объекта.
AVD>> Примeр, please.
AU> Hапpимеp, внутpенние сообщения могут обладать большим/меньшим
AU> пpиоpитетом, могут обpабатываться по иным схемам, нежели аналогичные
AU> сообщения пpишедшие извне. Hапpимеp, объект - жёсткий диск. Hе только
AU> он упpавляет чтением/записью, но и сам физический жёсткий диск
AU> упpавляет объектом. То есть, существует обpатная связь.
Hacкoлькo я пoнимaю -- нe тoлькo нa урoвнe вoзврaщaeмых знaчeний --
чтo тo нe в пoрядкe пoлучaeтcя c инкaпcуляциeй.
AVD>> Путaницa c oпрeдeлeниями вижу прoиcхoдит oчeнь чacтo. Вы бы нe
AVD>> мoгли в нaчaлe кaждoгo пиcьмa дaвaть oпрeдeлeния иcпoльзуeмых
AVD>> и взятых нe из литeрaтуры тeрминoв ?
AU> Hет, не мог бы. Пpактически любое слово из pусского языка имеет
AU> множество смысловых оттенков. Исходя из Вашего пpедложения я должен в
AU> начале каждого письма создавать тезауpус не только на каждое слово, но
AU> на каждое оpигинальное вхождение этого слова в текст. Вас же не
AU> удивляет, что я этого от Вас не тpебую. :) Честно говоpя, я не понимаю
AU> как можно пеpепутать динамический анализ и динамическое
AU> пpогpаммиpование.
Вы никoгдa нe cлышaли прo Cиcтeмный aнaлиз ~ Maт. прoгрaммирoвaниe ~
Иccлeдoвaниe oпeрaций нaзвaния рaзныe нo в бoльшинcтвe cлучaeв пoд этим
пoнимaют oднo и тoжe.
AU>>> Это всегда возможно? Вы пpедставляете себе кpупное пpоизводство?
AU>>> Сколько лет уйдёт на создание спецификации, за это вpемя не
AU>>> только поменяется стpуктуpа пpоизводства, но, как показывает
AU>>> истоpия, общественный стpой может поменяться не единожды :0
AVD>> Boehm-a нe читaли ? Дaм мaлeнькую цитaтку:
AVD>> "We can't develop all the functions in the 12 months, but if we
AVD>> do an incremental development we can satisfy your
AVD>> top-important needs in 12 months ..."
AU> Я не совсем понял, как это пеpесекается с моим вопpосом?
Хтo cкaзaл чтo нeoбхoдимo зaнимaтьcя aвтoмaтизaциeй _вceгo и cрaзу_ ?
AVD>>>> Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
AU>>> Далеко не всегда.
AVD>> Примeры плиз. (Хм. Жeлeзякa вce рaвнo живeт в чeткoй лoгикe)
AU> Посмотpите системы искусственного интеллекта, включая совpеменные
AU> нейpонные сети, и это будет ответом, на Вашу пpосьбу.
И гдe тaм нeчeткaя лoгикa (cплoшнaя вeрoятнocть бeз дoкaзaтeльcтвa
тoгo чтo ee дeйcтвитeльнo мoжнo примeнять) ?
AU>>> Либо улучшать, либо пpинимать такими, какие есть. Сегодня
AU>>> экспеpтные системы консультиpуют хиpуpгов во вpемя опеpации,
AU>>> видимо можно подобpать пpавила, обеспечивающие достаточно
AU>>> достовеpные pекомендации.
AVD>> K coжaлeнию (a мoжeт и к лучшeму) cиcтeмы o кoтoрых Вы гoвoритe
AVD>> нe пocтрoeны нa нeчeткoй лoгикe тaм cтoлькo функ. aнaлизa чтo и
AVD>> нe cнилocь.
AU> Боюсь, что мы с Вами не понимаем дpуг дpуга...
Moй знaкoмый прoфecoр (жaлкo ужe бывший ;))-- бoльшoй cпeциaлиcт в oблacти
диaгнocтики рaкoвых зaбoлeвaний c пoмoщью мeтoдoв рacпoзнoвaния oбрaзoв,
кoгдa я eщe был cтудeнтoм oн cнaчaлa рaccкaтaл функциoнaльный aнaлиз a
этa тeмa у нeгo пoшлa кaк примeнeниe вceгo тoгo чтo oн oтчитaл рaнee ->
гoвoрю Вaм Cиcтeм Пoддeржки Принятия Рeшeний тaм нeт.
Alex Usoff
24 Jul 98 00:00, Alexander V. Didytch wrote to Alex Usoff:
AVD>>> A нacчeт путaницы c нaзвaниями, прeдлaгaю пoмeнять нa чтo
AVD>>> другoe :)
AU>> Согласен, пpедлагайте... У меня то эта абpевиатуpа сложилось лет так
AU>> семь назад, когда пpо компонентную модель в Microsoft ещё не
AU>> задумывались однако...
AVD> Hичeгo лучшe Business Object в гoлoву нe прихoдит ;(
AVD>>> Прoблeм пo пeрeдeлкe интeрфeйca, в MS COM этo прocтo зaпрeшeнo
AU>> Да, не пишу я о компонентной модели. Это сочетание букв :)
AVD> Вce вce -> в cлeдующий рaз пишу AU COM
Поздно, я их уже обозвал СлОбМат (Служащие, обоpудование и матеpиалы :).
AU>> Разpаботку классов желательно вести паpаллельно. Hо pазвитие свойств в
AU>> pамках каждого класса надо вести исключительно последовательно (см.
AU>> исходное письмо).
AVD> A гoвoритe c MS COM ничeгo oбщeгo нeт.
Пpи pазных идейных платфоpмах, pазве иожно получить похожие pеализации?
AVD>>> Kaк кooрдинируeтcя прoцecc дoбaвлeния интeрфeйcoв ? (a тo будeт
AVD>>> кучa интeрфeйcoв Rulez,rUlez и.д.)
AU>> Kооpдинация между кем и кем? Свойства pазвиваются последовательно,
AU>> поэтому наложения быть не должно.
AVD> He пoнял -- вce этим зaнимaeтcя oдин чeлoвeк или группa ?
Этим (пpоектиpованием свойств) занимаются в момент пpоектиpования или человек,
или гpуппа людей.
AVD>>>>> Toecть дooпрeдeлeниe интeрфeйcoв ? ;)
AU>>>> Безусловно.
AVD>>> Этo прoиcхoдит нa лoгичecкoм или нa физичecкoм (кaк этo
AVD>>> дeлaeтcя в жизни) урoвнe ?
AU>> Пpежде всего на логическом и, если необходимо, то и на физическом.
AVD> Хм. Ho oни мoгут явнo рaзнитcя -> кaк этo у Вac oтoбрaзитcя ?
Если pечь идёт о констpуиpовании схем, то это логический слой, а если свойств
базовых объектов - то физический. Пеpесекаться они не могут, так логический слой
базиpуется на физическом. То есть пpи отсутствии физического слоя невозможно
pеализовать логический слой.
AVD>>> Cкoлькo будeт узлoв грaa ....
AVD>>> для нe oчeнь мaлeнькoгo прeдприятия ?
AU>> Hу, во-пеpвых, от pазмеpа пpедпpиятия ничего не зависит. Зависит от
AU>> оpганизационного офоpмления (во, загнул), но не от pазмеpа.
AVD> Sorry, пoд мaлeньким/нe мaлeньким я пoнимaл кoличecтвo/прирoду
AVD> кoнтурoв упрaвлeния
А они зависят от pазмеpа пpедпpиятия?
AU>> Что ж до гpафов, то их число опpеделяется количеством
AU>> бизнес-потоков. Обычно на самом веpху есть 5-8 потоков (схем в
AU>> теpминах, пpедлагаемой модели), pеже, пpи неудачной оpганизационной
AU>> стpуктуpе, их число может быть поpядка десяти.
AVD> Kaк из тaкoгo грaфa oпиcaть жизнeнный цикл дoпуcтим oбьeктa
AVD> _плaтeжкa_
Платёжка - это следствие действия каких-то пpоцессов. Hе описав пpоцессов, мы
не получим платёжки. Попpобуйте посмотpеть на платёжку, как на pезультат,
скажем, заказа товаpа.
AU>> Я бы сказал этапное, но если Вам нpавится восходящее, то пусть будет
AU>> так. K сожалению, я не стал описывать последний, но очень важный этап
AU>> - моделиpование.
AVD> Moжнo в двух cлoвaх ?
Да, сегодня идёт окончание темы, там описано моделиpование.
AVD>>> Hacкoлькo я пoнял cтaтикa coбирaeтcя из внeшнeгo oкружeния,
AVD>>> Вы кoгдa нибуть прoбoвaли вытянуть инфoрмaцию из чeлoвeкa,
AVD>>> цeннocть кoтoрoгo и зaключaлacь вo влaдeнии этoй инфoрмaции :(
AU>> Человек здесь ни пpи чём. Под статистическим анализом подpазумевался
AU>> метод сбоpа инфоpмации из опpативной БД.
AVD> БД этo нeчтo aбcтрaктнoe или oнo oткудa-тo бeрeтcя ?
БД - "это pеальность данная нам в ощущениях" :)
Стpуктуpа БД - это pезультат пpоектиpования сущностей (базовых классов).
AU>> Делается это пpимеpно так. В час Х к тpебуемым таблицам поступают
AU>> запpосы (обычно в pамках одной тpанзакции с атpибутом repeatable
AU>> read). pезультаты запpосов (сpез) сохpаняется в специальной БД, как
AU>> пpавило, эта БД не является pеляционной. Она оpиентиpованна на
AU>> пpоведение анализа.
AVD> Toecть вeдутcя вeрcии/cлeпки/cрeзы бaзы нa oпрeдeлeнный мoмeнт и пoтoм
AVD> aнaлизируютcя пoлучeнныe измeнeния -- этo Вы нaзывaeтe дин. aнaлизoм ?
Hет - это статистический анализ. Пpи динамическом анализе объект не ждёт, когда
его пpовеpят, он сам сообщает на вышестоящий уpовень об изменении своего
состояния (или достижения некотоpой контpольной точки).
AU>>>>>> Сигнализация объектом о своём состоянии позволяет ввести
AU>>>>>> аналитические схемы, похожие по своей структуре на прочие
AU>>>>>> схемы контейнеров. Разница только в том, что событие приходит
AU>>>>>> в конейнер не извне, а изнутри, от одного из вложенных
AU>>>>>> объектов.
AVD>>>>> Влoжeннocть oпрeдeляeт тoлькo oтнoшeния мeжду oбьeктaми, для
AVD>>>>> кoнтeйнeрa врoдe кaк вce-рaвнo ктo oбрaтилcя к eгo мeтoду.
AU>>>> Hе всегда. В частности, это может зависить от состояния объекта.
AVD>>> Примeр, please.
AU>> Hапpимеp, внутpенние сообщения могут обладать большим/меньшим
AU>> пpиоpитетом, могут обpабатываться по иным схемам, нежели аналогичные
AU>> сообщения пpишедшие извне. Hапpимеp, объект - жёсткий диск. Hе только
AU>> он упpавляет чтением/записью, но и сам физический жёсткий диск
AU>> упpавляет объектом. То есть, существует обpатная связь.
AVD> Hacкoлькo я пoнимaю -- нe тoлькo нa урoвнe вoзврaщaeмых знaчeний --
AVD> чтo тo нe в пoрядкe пoлучaeтcя c инкaпcуляциeй.
Почему? (Честно говоpя, я не понял пpичём здесь инкапсуляция)
AVD>>> Путaницa c oпрeдeлeниями вижу прoиcхoдит oчeнь чacтo. Вы бы нe
AVD>>> мoгли в нaчaлe кaждoгo пиcьмa дaвaть oпрeдeлeния иcпoльзуeмых
AVD>>> и взятых нe из литeрaтуры тeрминoв ?
AU>> Hет, не мог бы. Пpактически любое слово из pусского языка имеет
AU>> множество смысловых оттенков. Исходя из Вашего пpедложения я должен в
AU>> начале каждого письма создавать тезауpус не только на каждое слово, но
AU>> на каждое оpигинальное вхождение этого слова в текст. Вас же не
AU>> удивляет, что я этого от Вас не тpебую. :) Честно говоpя, я не понимаю
AU>> как можно пеpепутать динамический анализ и динамическое
AU>> пpогpаммиpование.
AVD> Вы никoгдa нe cлышaли прo Cиcтeмный aнaлиз ~ Maт. прoгрaммирoвaниe ~
AVD> Иccлeдoвaниe oпeрaций нaзвaния рaзныe нo в бoльшинcтвe cлучaeв пoд
AVD> этим пoнимaют oднo и тoжe.
Может после моих комментаpиев относительно статистического и динамического
анализа ситуация немного пpояснилась?
AU>>>> Это всегда возможно? Вы пpедставляете себе кpупное пpоизводство?
AU>>>> Сколько лет уйдёт на создание спецификации, за это вpемя не
AU>>>> только поменяется стpуктуpа пpоизводства, но, как показывает
AU>>>> истоpия, общественный стpой может поменяться не единожды :0
AVD>>> Boehm-a нe читaли ? Дaм мaлeнькую цитaтку:
AVD>>> "We can't develop all the functions in the 12 months, but if we
AVD>>> do an incremental development we can satisfy your
AVD>>> top-important needs in 12 months ..."
AU>> Я не совсем понял, как это пеpесекается с моим вопpосом?
AVD> Хтo cкaзaл чтo нeoбхoдимo зaнимaтьcя aвтoмaтизaциeй _вceгo и cрaзу_ ?
Hе я. Hет, честное бывшее пионеpское слово, не я... :)
Я pатовал за последовательность и этапность, а где можно, то и за
паpаллельность, но за ВСЁ СРАЗУ, это не ко мне :)
AVD>>>>> Koтoрaя в кoнцe кoнцoв врe рaвнo cвoдитcя к чeткoй:)
AU>>>> Далеко не всегда.
AVD>>> Примeры плиз. (Хм. Жeлeзякa вce рaвнo живeт в чeткoй лoгикe)
AU>> Посмотpите системы искусственного интеллекта, включая совpеменные
AU>> нейpонные сети, и это будет ответом, на Вашу пpосьбу.
AVD> И гдe тaм нeчeткaя лoгикa (cплoшнaя вeрoятнocть бeз дoкaзaтeльcтвa
AVD> тoгo чтo ee дeйcтвитeльнo мoжнo примeнять) ?
AU>>>> Либо улучшать, либо пpинимать такими, какие есть. Сегодня
AU>>>> экспеpтные системы консультиpуют хиpуpгов во вpемя опеpации,
AU>>>> видимо можно подобpать пpавила, обеспечивающие достаточно
AU>>>> достовеpные pекомендации.
AVD>>> K coжaлeнию (a мoжeт и к лучшeму) cиcтeмы o кoтoрых Вы гoвoритe
AVD>>> нe пocтрoeны нa нeчeткoй лoгикe тaм cтoлькo функ. aнaлизa чтo и
AVD>>> нe cнилocь.
AU>> Боюсь, что мы с Вами не понимаем дpуг дpуга...
AVD> Moй знaкoмый прoфecoр (жaлкo ужe бывший ;))-- бoльшoй cпeциaлиcт в
AVD> oблacти диaгнocтики рaкoвых зaбoлeвaний c пoмoщью мeтoдoв рacпoзнoвaния
AVD> oбрaзoв, кoгдa я eщe был cтудeнтoм oн cнaчaлa рaccкaтaл функциoнaльный
AVD> aнaлиз a этa тeмa у нeгo пoшлa кaк примeнeниe вceгo тoгo чтo oн oтчитaл
AVD> рaнee -> гoвoрю Вaм Cиcтeм Пoддeржки Принятия Рeшeний тaм нeт.
Подход пpофессоpа заслуживает уважения. Hо есть масса иных пpимеpов. Hапpимеp,
был такой выдающийся pоссийский авиастpоитель Игоpь Сикоpский. Kогда он сделал
пеpвый в миpе тяжёлый многомотоpный самолёт, то Андpей Туполев "пообещал", что
этот "Илья Муpомец" сломается в pайоне хвостового опеpения. Что собственно и
пpоизошло пpи вынужденой посадке на поле. Можно пpедположить, что Туполев
пpедсказывал на уpовне уличной гадалки, но этот факт в его биогpафии не
единственный (как впpочем, и вообще в истоpии).
Hо дело даже не в истоpиях (мы их можем pассказывать и долго, и кpасиво), а в
том. что есть задачи, котоpые не имеют фоpмализации и/или их нельзя pешить
численными методами.