Форум: "Потрепаться";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];
Вниз
---|Ветка была без названия|--- Найти похожие ветки
← →
euru (2003-09-18 13:12) [0]Есть ли желание поговорить о методах проектирования?
← →
AlexRush (2003-09-18 13:15) [1]Было бы весьма полезно. Я как то книжечку читал (шеф заставил :)
Н.Т. Клещев, А.А Романов "Практическое руководство по организации и проектированию информациооных систем" - просто и доступно. Прочитав третью часть, понял что я полный ламер.
Рекомендую почитать всем :)
← →
Владислав (2003-09-18 13:18) [2]Есть.
← →
Е-Моё имя (2003-09-18 13:20) [3]вот бывает проектирование на пальцах, например....
← →
euru (2003-09-18 13:45) [4]Насколько я знаю, последним модным методом проектирования стало объектно-ориентированное проектирование. Или я ошибаюсь?
← →
AlexRush (2003-09-18 14:09) [5]2euru © (18.09.03 13:45) [4] Да, но далеко не все имеют представление о отм, что ето такое.
← →
euru (2003-09-18 14:22) [6]>AlexRush © (18.09.03 14:09) [5]
Один из отцов объекто-ориентированного программирования:
http://www.helloworld.ru/texts/comp/other/oop/index.htm
← →
Некрофил-затейник__ (2003-09-18 14:48) [7]AlexRush
где можно книжку эту качнуть?
← →
Игорь Шевченко (2003-09-18 15:08) [8]Последним стало аспектно-ориентированное программирование, судя по MSDN Magazine
← →
euru (2003-09-18 15:14) [9]>Некрофил-затейник__ © (18.09.03 14:48) [7]
А это и есть книжка. Каждая html-страница - отдельная глава.
← →
Vuk (2003-09-18 15:18) [10]to Игорь Шевченко:
>Последним стало...
Я не совсем понял идею, но похоже, что там имелось в виду что-то типа автоматического обеспечения среды, в которой работает объект...
← →
euru (2003-09-18 15:20) [11]>Игорь Шевченко © (18.09.03 15:08) [8]
А ссылку можно? А то еще окажется, что я плагиатом занимался :)
← →
AlexRush (2003-09-18 15:21) [12]2Некрофил-затейник__ © (18.09.03 14:48) [7] нигде не качнуть. У нее и тираж то маленький. © ООО "Научтехиздат", Москва 2001
← →
Mystic (2003-09-18 15:23) [13]Для себя я стараюсь использовать идеи XP. Считаю, что не нужно тщательно проектировать все заранее, проект сам покажет, куда ему лучше развиваться... По крайней мере так получается красивее...
← →
vuk (2003-09-18 15:29) [14]to Mystic:
>Считаю, что не нужно тщательно проектировать все заранее
Может на маленьких проектах это и прокатит... Сейчас пишем (уже к завершению дело идет) не самый маленький проект. Четко выделенного этапа проектирования практически не было (времени мало). Чтобы я еще раз взялся за такое... Ну нафиг...
>По крайней мере так получается красивее...
Только кривая может вывести не туда, куда надо.
← →
Игорек (2003-09-18 15:44) [15]Для себя я вывел только два метода проектирования: сверху вниз и снизу вверх. Я предпочитаю первый, напарник - второй. Вот и ссоримся постоянно.
← →
euru (2003-09-18 15:49) [16]>vuk © (18.09.03 15:29) [14]
Согласен. Проектировать нужно. Только, по-моему, в подавляющем большинстве через некоторое время в спроектированной (и уже реализованной) системе нужны будут корректировки. Поэтому, я считаю, хороший проект - это не просто детально и тщательно продуманный проект. Хороший проект - это проект, который позволяет свою модификацию (даже уже будучи реализованным) с наименьшими затратами.
← →
Игорь Шевченко (2003-09-18 15:57) [17]Mystic © (18.09.03 15:23)
> Считаю, что не нужно тщательно проектировать все заранее,
> проект сам покажет, куда ему лучше развиваться... По крайней
> мере так получается красивее...
Первый раз встречаюсь с утверждением о красоте геморроя :) А геморрой будет, не сомневайся :)))
← →
Mystic (2003-09-18 16:00) [18]vuk © (18.09.03 15:29) [14]
Обязательным условием для меня при разработке является написание unit-тестов. При этом тесты стараюсь писать до. Потом то, что получилось криво, всегда можно подправить... А спроектировать все и вся во всех деталях у меня никогда не получалось.
Единственное, что я не использую из XP, это программирование в паре. Собственно говоря, из-за отсуствия оной.
Я, например, слышал, что при CMM для компании пятого уровня кодирование начинается на 18-й месяц проекта...
← →
Юрий Федоров (2003-09-18 16:00) [19]И вообще мне показалось, что XP - штука достаточно странная...
Среди описанных методов половина очевидна и лежит на поверхности, а вторая половина более чем спорна...
← →
euru (2003-09-18 16:01) [20]>Игорь Шевченко © (18.09.03 15:57) [17]
Прошу прощение за назойливость. В каком разделе MSDN искать про аспектно-ориентированное проектирование?
← →
euru (2003-09-18 16:04) [21]ХР - это что?
← →
Игорь Шевченко (2003-09-18 16:05) [22]euru © (18.09.03 16:01)
Журнал MSDN Magazine russian edition
http://www.microsoft.com/rus/msdn/magazine/archive/special_1/aop.asp
← →
Юрий Федоров (2003-09-18 16:07) [23]>>euru © (18.09.03 16:04) [21]
>>ХР - это что?
Экстремальное программирование
← →
Mystic (2003-09-18 16:10) [24]Игорь Шевченко © (18.09.03 15:57) [17]
Может и будет, но пока что я от него избавился... Во всяком случае, если сравнивать код, написанный при помощи ХР, и просто, то архитектура первого лучше, практичнее.
Юрий Федоров © (18.09.03 16:00) [19]
А что по вашему лежит на поверхности, а что спорно?
← →
vuk (2003-09-18 16:12) [25]to Mystic:
Что толку от unit-тестов, если меняются исходные требования?
to euru:
Статья на английском. В Русском переводе была в MSDN Magazine.
http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/
← →
euru (2003-09-18 16:14) [26]>Игорь Шевченко © (18.09.03 16:05) [22]
Спасибо. Сейчас закачаю и почитаю.
Про ХР. Давно я про него читал. Может и ошибаюсь, но мне кажется, что это не метод проектирования, а методология. Т.е. там без разницы, какой метод использовался (объектно-ориентированный, структурный и т.д.), главное как, используя этот метод, эффективно внедрить проект.
← →
Mystic (2003-09-18 16:17) [27]>Что толку от unit-тестов, если меняются исходные требования?
1. Уверенность в работе системы
2. Облегчается рефакторинг
+
мы сильно детально не проектируем, поэтому поменялось и черт с ним --- будем пистать под новые...
← →
Игорь Шевченко (2003-09-18 16:19) [28]Mystic © (18.09.03 16:10)
Андрей, позволь с тобой не согласиться. Архитектура кода зависит исключительно от программиста(ов), его пишущих. И не важно, XP-методики они используют или не-XP, причем, сдается мне, что при самопроизвольном развитии проекта о красоте кода речи идти просто не может, если даже красота будет на микроуровне за счет рефакторинга и прочих приемов, то на макроуровне будет наблюдаться баа-аальшой бардак.
← →
euru (2003-09-18 16:24) [29]>vuk © (18.09.03 16:12) [25]
Тоже спасибо. Теперь будет что в метро почитать.
← →
vuk (2003-09-18 16:45) [30]to Mystic:
Я вообще не очень представляю, как можно делать unit-тесты на систему, у которой почти вся логика живет на сервере БД, а клиент почти только отображением и вызовами процедур и занимается. Не пользовательский же интерфейс тестировать...
← →
Mystic (2003-09-18 16:45) [31]Честно говоря, большой разницы между макро и микро уровнями я не замечаю. Те же классы, те же тесты...
Само проектирование (RUP, CMM, ...) оно несколько далеко от кода и используемых библиотек. Глядя на UML-диаграммы трудно сказать, хорошая или плохая архитектура системы. На это можно ответить лишь изучив исходный код.
При проектировании без учета кода лично у меня возникают некоторые болезни, с которыми трудно бороться. Основную из них я назвал (для себя) болезнью "CreateProcess". Это стремление написать наиболее абстрактное и общее решение проблемы. По UML--диаграмме легко обобщить всю нужную функциональность. Но в UML-диаграмме мало информации о том, как часто должно использоваться общее решение. Когда упрощенный вариант работает примерно в 95% случаев, это начинает напрягать. В XP в таком случае ты как-то автоматом выходишь на паттерн "декоратор", что довольно удобно.
← →
Mystic (2003-09-18 16:52) [32]>vuk © (18.09.03 16:45) [30]
Я обычно пишу тесты на сами хранимые процедуры, и на классы, которые их используют.
← →
euru (2003-09-18 16:55) [33]Так, нужно освежить память. Киньте, пожалуйста, ссылку, где можно познакомиться с принципами ХР, а то, наверно, я что-то путаю.
>Mystic © (18.09.03 16:45) [31]
>Глядя на UML-диаграммы трудно сказать, хорошая или плохая
>архитектура системы. На это можно ответить лишь изучив исходный код.
Как это? Глядя на исходный код, мы можем ответить, хорошо или плохо реализована архитектура системы.
>При проектировании без учета кода...
А учет кода может наложить ограничения на проектирование и усложнить само проектирование
← →
Игорь Шевченко (2003-09-18 17:04) [34]euru © (18.09.03 16:55)
www.xprogramming.ru
← →
euru (2003-09-18 17:56) [35]Ну, точно. ХР - это больше о том, как эффективно программировать на заранее выбранном языке программировании. Проектирование там не главное.
← →
vuk (2003-09-18 17:59) [36]to euru:
>Проектирование там не главное.
Угу. Точно. Считается, что проектирование - лишняя деталь в процессе.
← →
Игорь Шевченко (2003-09-18 18:02) [37]vuk © (18.09.03 17:59)
Там должен доставлять удовольствие сам процесс программирования :) А не результат. Результата там, кстати, похоже достичь не удается никогда, так как если не изменились требования заказчика, то всегда есть время для рефакторинга :)
← →
euru (2003-09-22 11:10) [38]Еще раз спасибо Игорю Шевченко и vuk за ссылки по аспектно-ориентированному программированию. Попытался найти дополнительную информацию на русском языке, но мои попытки оказались неудачны. Если у кого есть ссылки, киньте плз.
Зато мне попалась ссылка на курс СПбГУ "Технологии компонентного программирования" - может кому пригодится:
http://oasis.apmath.spbu.ru/~vdobr/
Вчера мне попала в руки книга Г. Буча "Объектно-ориентированный анализ и проектирование с примерами приложений на С++". Сегодня, пока ехал на работу, прочел первую часть - "Концепции". Так и хочется написать возражения... :)
Про ХР - уточнение [35]. Там и программирование не главное. Это больше похоже на процесс организации группы людей в экстремальных условиях.
← →
Игорь Шевченко (2003-09-22 12:23) [39]
> Так и хочется написать возражения...
Бучу ? Интересно было бы послушать :)))
← →
euru (2003-09-22 12:50) [40]>Игорь Шевченко © (22.09.03 12:23) [39]
Это реплика или действительно интересно?
Книга представляет собой монолог автора читателю. Не всегда все, что хотел сказать, понятно читателю. Иногда потому что читателю, скажем так дипломатично, не хватает знаний, иногда потому что автор считает что-либо само собой разумеющееся, а у читателя существует свое мнение по этому поводу. Оно может быть неверным, но ведь возможно, что и автор ошибался (мы же все-таки люди). Раз есть собственное мнение, то естественной реакцией на слова автора будет возражение, на которое (при диалоге) автор может уточнить свою точку зрения, после чего, возможно, возражение снимется.
Так как непосредственно с Бучем я вести диалог не могу, то и обратился в этот форум.
← →
Игорь Шевченко (2003-09-22 12:54) [41]Я тоже не Буч, разумеется, но послушать было бы интересно, так как книжку Буча считаю очень неплохой и достаточно ясно написанной :)
← →
Vuk (2003-09-22 12:59) [42]to euru:
>Это реплика или действительно интересно?
Хоть и не ко мне обращение, но мне тоже было бы интересно. Серьёзно.
P.S. У меня, помнится, было странное ощущение после прочтения первой главы книги "ООА: моделирование мира в состояниях" (авторы Шлеер и Меллор). Это была первая книга по ООА, которую я прочитал. Там на читателя вываливалась куча терминогогии и концепций, и становилось несколько страшновато от этого потока. Потом до меня дошло, что первую главу лучше пропустить. :o) Во воторой главе начали потихоньку вводить термины и объяснять концепции и т.д. А после прочтения всей книги оказалось, что можно и первую главу нормально прочитать. :o)
← →
euru (2003-09-22 13:23) [43]Согласен (и что не Буч, что неплохо и ясно написано :)). Я тоже по ней учился и старался использовать ее выводы. Но это же не значит, что она - истина в последней инстанции и, как библия, необсуждаема (кстати, и библию обсуждают...)
Можно, в принципе, последовательно, начиная с 1-й главы, высказывать свои возражения, но для начала о заголовке книги:
"Объектно-ориентированный анализ и проектирование с примерами приложений на С++"
А теперь цитата из раздела 2.2:
Дженкинс и Глазго считают, что "в большинстве своем программисты используют в работе один язык программирования и следуют одному стилю. Они программируют в парадигме, навязанной используемым ими языком. Часто они оставляют в стороне альтернативные подходы к цели, а следовательно, им трудно увидеть преимущества стиля, более соответствующего решаемой задаче"
Те есть ограничившись языком С++ (от себя: и его аналогами - напр. Delphi), он строит свой вариант объектно-ориентированного дизайна (ООД) (ООД - чтобы не путать с ООП - объектно-ориентированным программированием).
И хотя С++ достаточно мощный язык, но все ли возможности ОО концепции им предоставляются? Пример тому аспектно-ориентированное программирование - тоже ведь разновидность ООП.
← →
euru (2003-09-22 13:26) [44]>Vuk © (22.09.03 12:59) [42] и всем-всем-всем
Обращение ко всем, кто хочет разобраться в этом самом ООД
← →
Игорь Шевченко (2003-09-22 13:59) [45]euru © (22.09.03 13:23)
Дженкинс и Глазго довольно правильно считают :)
А программист строит свой вариант не в зависимости от средств, предоставляемых языком, чаще всего, так как и C++ и Object pascal довольно развитые языки, чтобы предоставить массу средств, а в силу своей собственной ограниченности в понимании ООП и ООД :))
← →
Vuk (2003-09-22 14:00) [46]to euru:
Главное - это не язык реализации, а реализованная концепция. Кстати, не помню, чтобы в книге были какие-то примеры, реализация которых на сзыке, отличном от C++ была бы невозможна. Вообще говоря, в первом издании книги Буча концепции рассматривались отдельно, а примеры были даны отдельно и для разных языков программирования...
← →
euru (2003-09-22 14:41) [47]>Игорь Шевченко © (22.09.03 13:59) [45]
Так ведь в общем случае программист и проектировщик (дизайнер) - это разные люди. Программист создает по модели, разработанной дизайнером, программный код, и его "собственная ограниченность" ограничивается пониманием возможностей этого языка. На модель это никак не сказывается.
А вот если дизайнер при разработке архитектуры модели будет учитывать ЯП, на котором это будет реализовано, может существенно ограничить возможности самой модели. Пример: если дизайнер выберет Delphi, то ему нужно учитывать простое наследование, если C++, то можно и множественное наследование.
Vuk © (22.09.03 14:00) [46]
1. Допустим, в ней не рассматривались модели, которые невозможно реализовать на С++ :)
2. Хоть концепции и рассматриваются отдельно, но их примеры (не путать с примерами, реализованными по этим концепциям) делаются с учетом возможностей С++.
← →
Игорь Шевченко (2003-09-22 14:50) [48]euru © (22.09.03 14:41)
> Так ведь в общем случае программист и проектировщик (дизайнер)
> - это разные люди. Программист создает по модели, разработанной
> дизайнером, программный код
Нда ? Значит, мы о разном...
← →
Некрофил-затейник__ (2003-09-22 14:57) [49]euru
А вы не пробывали резко перейти с Delphi на VC и обратно?
Путешествие хоббита туда обратно отдыхает.
Вас не смущает фраза мыслить на русском языке или мыслить на английском языке?
Язык точнее его возможности навязывают свой стиль это точно просто у Буча пример про искимосов не много не в тему в другой книге(не помню название) про тоже самое говорится менее образно в том смысле что если язык предлагает простые средства организации множественного наследия то множественным насдедованием пользуются.
Пример в VC можно просто организовать наследование хоть от 20 класссов в Delphi наследование через Interface и Dispinterface усложнено много вы делали программ с множественным наследованием на Delphi?
← →
euru (2003-09-22 18:08) [50]>Игорь Шевченко © (22.09.03 14:50) [48]
>Некрофил-затейник__ © (22.09.03 14:57) [49]
Так ведь я сразу говорил о проектировании (см. subj)
Буч тоже говорит о проектировании (если верить названию книги).
Я не заставляю никого переходить с одного языка программирования на другой.
← →
euru (2003-09-22 20:29) [51]up
← →
Vuk (2003-09-22 20:30) [52]А в чем тогда проблема - то? ;o)
← →
euru (2003-09-22 22:43) [53]>Vuk © (22.09.03 20:30) [52]
А я разве говорил о проблемах? Мне просто хотелось обсудить, кто и как проектирует. Неужели все сразу программы пишут? Совсем не проектируют? Прямо как казахские акыны: что вижу, о том и пою.
← →
Vuk (2003-09-23 01:42) [54]to euru:
>Неужели все сразу программы пишут?
Ну... Не то, чтобы совсем сразу, но в текущем проекте этапа проетирования практически не было (см. [14]). Просто периодически определяются направления дальнейшего развития, некоторые детали реализации, анализируются требования данного этапа. Иногда требования довольно-таки расплывчатые... Так что иной раз приходится акынствовать помаленьку, хотя и очень не хочется. :o(
← →
[NIKEL] (2003-09-23 06:26) [55]проектирование вобщем очень интересно, но может спуститься до, например, проектирования определенных информационных систем?
например бухгалтерия,склад\логистика; или к предстовлению документа,обработка, вообщем ближе к предметной области, к автоматизации.
Как кто пишет(почему так?), поделимся опытом.
← →
Viktor Kushnir (2003-09-23 07:50) [56]По моему большая часть проектирования происходит в уме. У меня, например, когда еду в транспорте и делать нечего. Программа в это время продумываюется, ищутся слабые места. Конечно так нельзя продумать все максимально детализованно, но этого и не требуется.
← →
euru (2003-09-23 18:22) [57]>[NIKEL] © (23.09.03 06:26) [55]
А чем интереснее проектирование определенной информационной системы от проектирования вообще? Не зная проектирование, как таковое, невозможно успешно спроектировать какю-либо систему. Это как чтение. Не умея читать вообще, невозможно будет прочесть конкретную книгу.
Viktor Kushnir © (23.09.03 07:50) [56]
Это не проектирование. Это составление и оптимизация кода уже спроектированной задачи. Причем если спроектировано хреново, то как ни оптимизируй, алгоритм тоже будет хреновый.
← →
[NIKEL] (2003-09-24 08:36) [58]>[NIKEL] © (23.09.03 06:26) [55]
А чем интереснее проектирование определенной информационной системы от проектирования вообще? Не зная проектирование, как таковое, невозможно успешно спроектировать какю-либо систему. Это как чтение. Не умея читать вообще, невозможно будет прочесть конкретную книгу.
А чем интереснее летать на самолете от чтения книг, о том как летать на самолете...
Чем ближе к практике\реалиям жизни, тем интереснее, поверь.
← →
euru (2003-09-24 09:15) [59]>[NIKEL] © (24.09.03 08:36) [58]
Это смотря как летать. Если в качестве пассажира, то можно и не читать. Тогда, действительно, гораздо интереснее летать. А вот если в качестве пилота, то все-таки, наверно, желательно изучить теорию полетов и принципы управления самолетом. И если есть чувство самосохранения, лучше все-таки это делать не в реальных условиях.
← →
Некрофил-затейник__ (2003-09-24 10:38) [60][NIKEL]
почитай Гради Буча
← →
euru (2003-09-24 14:18) [61]>Некрофил-затейник__ © (24.09.03 10:38) [60]
Ну, осознает он свою ошибку, прочтет Буча. А дальше что? Молиться что ли на это произведение? И по каждому поводу ссылаться на него, как на святое писание?
Уже ведь 10 лет прошло с момента написания этой книги.
← →
euru (2003-09-24 15:47) [62]up
← →
euru (2003-09-25 09:47) [63]А есть какой-нибудь форум, где обсуждается сабж?
← →
Некрофил-затейник__ (2003-09-25 09:51) [64]euru
Это только начало.
"А дорога идет дальше и дальше"
Толкиен.
← →
Некрофил-затейник__ (2003-09-25 10:49) [65]up
ЗЫ
чтоб ветку достовать потом с 15 позиции не пришлось да может еще кто решит высказать свои сооброжения по поводу subj.
← →
euru (2003-09-25 11:06) [66]>Некрофил-затейник__ © (25.09.03 10:49) [65]
:)
спасибо за помощь
:)
← →
Mike B. (2003-09-25 11:08) [67]euru ©
На RSDN есть форум проектирование. Вот, например, интересные обсуждения:
http://www.rsdn.ru/Forum/Message.aspx?mid=304302
http://www.rsdn.ru/Forum/Message.aspx?mid=262074
← →
[NIKEL] (2003-09-25 12:43) [68]
euru © (24.09.03 09:15) [59]
>[NIKEL] © (24.09.03 08:36) [58]
Это смотря как летать. Если в качестве пассажира, то можно и не читать. Тогда, действительно, гораздо интереснее летать. А вот если в качестве пилота, то все-таки, наверно, желательно изучить теорию полетов и принципы управления самолетом. И если есть чувство самосохранения, лучше все-таки это делать не в реальных условиях.
Некрофил-затейник__ © (24.09.03 10:38) [60]
[NIKEL]
почитай Гради Буча
понятно что надо знать теорию... ты меня просто не понял.
я то думал что теорию Вы уже узнали\читали...
на данный момент, для меня интереснее практические навыки и конкретные примеры
← →
[NIKEL] (2003-09-25 12:44) [69]кстати на SQL.ru есть хорошие форумы, проектирование и т.д.
← →
Некрофил-затейник__ (2003-09-25 13:05) [70][NIKEL]
Тогда есть книжка в том числе и в инете в свободном скачивании
"Смертельный марш" есть смысл почитать там как раз про практику и теорию и как они согласуются между собой
← →
Некрофил-затейник__ (2003-09-25 13:20) [71]Mike B.
там про развитие причем одной отдельно парадигмы ООП
хотя тоже интересно...
← →
euru (2003-09-25 13:59) [72]>[NIKEL] © (25.09.03 12:43) [68]
Ну так это не по сабжу. Можно завести отдельную ветку.
>Mike B. © (25.09.03 11:08) [67]
С отрывом на работу и перерывом на обед прочел. Довольно-таки интересные обсуждения. Правда, по большей части они посвящены методам программирования, и до уровня пректирования они так и не поднялись (опустились).
← →
euru (2003-09-25 16:18) [73]А знаете, почему Буч выбрал объектно-ориентированный метод проектирования? Потому что:
Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
Дальше идут еще три небесспорных причины.
Наконец, объектная модель ориентирована на человеческое восприятие мира...
Т.е. основная причина - потом проще будет писать на ООП (в частности, на С++).
← →
euru (2003-09-25 16:20) [74]А знаете, почему Буч выбрал объектно-ориентированный метод проектирования? Потому что:
Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
Дальше идут еще три небесспорных причины.
Наконец, объектная модель ориентирована на человеческое восприятие мира...
Т.е. основная причина - потом проще будет писать на ОО-языке (в частности, на С++).
← →
Некрофил-затейник__ (2003-09-26 06:25) [75]euru
ну еще наверное потому что С++ популярен
С++ знают многие.
Вообще у Дейкстры и Кнута по этому поводу есть другой вариант у обоих есть свой псевдоязык на котором можно писать проги.
Но суть то не меняется просто им всем троим был нужен язык чтобы показать на примерах теорию.
← →
Некрофил-затейник__ (2003-09-26 06:34) [76]2 All
Программистский камень
\/
http://progstone.narod.ru/
что вы думаете об этом?
← →
Некрофил-затейник__ (2003-09-26 11:46) [77]2 All
Программистский камень
\/
http://progstone.narod.ru/
что вы думаете об этом?
← →
Игорь Шевченко (2003-09-26 14:06) [78]Некрофил-затейник__ © (26.09.03 11:46)
Хорошая книга :))
Пример с Рихтером понравился, еще полтора года назад
← →
euru (2003-09-26 23:25) [79]>Некрофил-затейник__ © (26.09.03 11:46) [77]
Вот что Буч пишет про структурный анализ:
Если же по каким-либо уважительным причинам приходится взять за основу структурный анализ, прекратите строить диаграммы, как только они начинают смахивать на проект программы, а не на модель предметной области. Помните, что материалы проектирования, такие, как диаграммы потоков данных, это не конечный продукт, а инструмент разработчиков. Обычно строятся диаграммы, а затем разрабатываются механизмы, обеспечивающие необходимое поведение системы, то есть сам акт проектирования видоизменяет начальную модель.
Т.е. сначала он говорит: 1) Используйте ОО-анализ и ОО-проектирование, потому что потом будет легче писать на ОО-языке. Тем самым делается ограничение на возможные варианты анализа и проектирования. Однако если считать, что структурный анализ - это одна из разновидностей анализа, то к ОО-анализу тоже можно применить вышеприведенное правило. Т.е. 2) не стоит строить иерархию классов и взаимодействие между ними, если "они начинают смахивать на проект программы, а не на модель предметной области". Но согласно 1) мы уже выбрали, как мы будем анализировать предметную область, и поэтому, как бы мы ни старались, она будет "смахивать на проект программы".
Бегло просмотрел ссылку. Довольно-таки интересно. Только мне кажется, там больше об эффективной организации труда программиста (может, я что-то упустил?).
>Игорь Шевченко © (26.09.03 14:06) [78]
Да, пример хорош. Я бы, правда, остановился на предпоследнем варианте - тогда бы не понадобилось объяснять, почему Index проверяется дважды.
← →
euru (2003-09-29 09:04) [80]up
← →
Некрофил-затейник__ (2003-09-29 10:41) [81]Ну так он в книге "водопадом" все примеры строит то есть есть какой то этап все обдумывается следующий проектируется следующий пишется. Хотя он тоже иной раз прыгает между этапами но редко а вообще вся учебная литература оперирует "водопадом".
← →
Некрофил-затейник__ (2003-09-29 13:19) [82]up
← →
euru (2003-09-29 16:30) [83]Так водопада-то и не получается.
Если бы он в своей книге написал, что есть такие ОО-языки, типа С++, Object Pascal и т.д, а на них очень удобно реализовывать один из видов объектного анализа и проектирования, я бы с ним согласился. Это была бы книга прикладного назначения, типа "Как использовать С++ для ООА и ООД."
Или если бы он доказал без привлечения языка пр, что ООА и ООП - это лучший метод анализа и проектирования, поэтому были созданы такие языки как С++ и т.д., на которых эти методы удобно претворять в жизнь, я бы тоже согласился. Это был бы какой-нибудь теоретический труд, типа "Теоретическое обоснование ООА и ООД как единственно возможных оптимальных методов анализа и проектирования".
А у него какой-то замкнутый круг получается: доказываем, что нужно использовать ОО-проектирование, потому что результат проектирования удобно осуществлять на ОО-языках, а, с другой стороны, нужно использовать ОО-языки, потому что, как мы доказали выше, нужно использовать ОО-проектирование.
Это все равно что утверждать (возможно, пример не очень удачен), что нужно на автомобилях ездить задом, потому что там есть передача заднего хода, а, с другой стороны, при езде нужно использовать передачу заднего хода, потому что, как мы уже доказали выше, нужно ездить задом.
← →
vuk (2003-09-29 17:07) [84]to euru:
>А у него какой-то замкнутый круг получается
Блин, да плюньте Вы на это и смотрите глубже, в суть методики. Язык там ни при чем.
← →
euru (2003-09-29 20:13) [85]vuk © (29.09.03 17:07) [84]
>Блин, да плюньте Вы на это и смотрите глубже, в суть методики. Язык там ни при чем.
Как раз-таки причем. Если бы использовался какой-нибудь структурированный язык (типа Си или Паскаля), то решения проектов выглядели бы по-другому. Да даже если взять аспектно-ориентированные языки (вариант объектно-ориентированных языков), то и с ними решения проектов были бы другими.
Т.е. выбор языка влияет на процесс анализа и проектирования и, соответственно, искажает модель.
← →
vuk (2003-09-29 20:28) [86]to euru:
>решения проектов выглядели бы по-другому
Решения - да, но не принципы анализа.
← →
euru (2003-09-29 20:49) [87]>vuk © (29.09.03 20:28) [86]
А я на принципы и не посягался. Они, я думаю, везде одинаковы: исследовать реальное явление, выявить закономерности, связи, построить модель.
Теперь берем проектировщика. Он знает, что в дальнейшем программирование того, что он наваяет, будет идти на каком-то структурированном языке. Он знает, что там важны структуры данных, алгоритмы их обработки обработки, и спроектирует соответствующую этой идеологии модель.
Если бы применялся какой-нибудь ОО-язык, проектирвщик учел бы особенности языка этого типа (выявление классов, объединение одинаковых свойств и поведения в один класс, специализация с помощью наследования) и спроектировал бы модель в соответствии с этой идеологией.
← →
Vuk (2003-09-29 21:05) [88]Все зависит от того, модель чего рассматривается. Если модель программных компонентов, то, естественно, язык должен учитываться. Если же рассматривается модель предметной области, то в этом случае не стоит принимать такие решения, которые потом могут сказаться на возможности реализации на конкретном языке программирования. Ведь если посмотреть внимательно, то, по большому счету, возможности конкретного языка нужно учитывать при проектировании иерархии и реализации классов, но ведь это уже проектирование, а не анализ (OOD, а не OOA)...
← →
euru (2003-09-29 21:18) [89]>Vuk © (29.09.03 21:05) [88]
А откуда взялась эта иерархия классов, которую нужно проектировать? Сдается мне, при анализе. А почему иерархия классов, а не что-либо другое?
← →
vuk (2003-09-29 21:28) [90]>А откуда взялась эта иерархия классов, которую нужно
>проектировать?
Там до иерархии классов еще много чего интересного есть... Use Cases, например (на русский обычно термин переводится как "инциденты").
>А почему иерархия классов, а не что-либо другое?
Да вовсе не обязательно. Это могут получиться интерфейсы, а не классы...
← →
vuk (2003-09-29 21:36) [91]Тьфу, блин, Use Case - не инцидент, а прецедент.
← →
Некрофил-затейник__ (2003-09-30 07:47) [92]euru
так в книге по мойму была оговорка что он использует С++ только по тому что его знает много народу на самом деле нечто подобное можно реализовать на любом ООП(я не стал искать его фразу только смысл как помню).
C++
class a{
protected:
int x;
};
cass b(){
public:
GetX(){return x;}
};
Delphi 5 ))))
type
a = class
protected
a:integer;
end;
b = class(a)
public
function GetX: integer;
end;
implementation
function b.GetX:integer;
begin
Result := x;
end;
разници особой нет на языке зацикливатся не стоит.
← →
euru (2003-09-30 10:39) [93]>vuk © (29.09.03 21:28) [90]
Использование прецедентов, стереотипов, диаграмм состояний и т.д. - вещь полезная и нужная. Только это, по-моему, в большей части относится к методологии анализа и проектирования, облегчающей формализацию описания модели, и одинаково применимо как к ООА, так и другим методам анализа.
Другое дело метод проектирования. Он влияет на то, как проектировщик отобразит реальную систему в своей модели. См. также euru © (29.09.03 20:49) [87]. Это касается и модели программных компонентов. За примером далеко ходить не нужно - возьмем интерфейс пользователя. Он состоит из стандартного набора компонентов: окна, поля ввода, меню, комбобоксы и т.д. Его модель при структурированном подходе представлена в Win32, а при ОО-подходе - в VCL.
>Некрофил-затейник__ © (30.09.03 07:47) [92]
ОО-языки действительно очень похожи друг на друга и базовые вещи достаточно легко однозначно отображаются между ними. Но даже и в этих языках есть некоторые понятия, которые не так-то легко отобразить из одного ОО-языка в другой (например, перегрузка операторов, множественное наследование из С++ в Delphi или множества, делегирование интерфейсов из Delphi в С++, а еще есть Java с поддержкой многопоточности, C# с атрибутами). А ведь ОО-языки - не единственно возможный вариант объектного программирования. В этом классе есть такие виды программирования, как аспектно-ориентированное, субъектно-ориентированное, аддитивное программирование (я эти названия встретил, пока знакомился с аспектно-ориентированным, возможно, существуют и еще какие-то варианты). Помимо объектного подхода еще есть автоматный, функциональный и т.д.
Я не хочу как-то умалить или очернить труд Буча (да у меня это и не получится :)). Его работы (и работы его единомышленников и последователей) сделали в свое время очередной шаг, позволяющий более реально отображать в модели реальную систему. Но неужели верен только предложенный им подход в построении модели? А если его подход наиболее верный, то неужели предложенный им вариант максимально лучший?
← →
Некрофил-затейник__ (2003-09-30 12:29) [94]euru
IMHO
Скорее всего ООП это не единственно правильный метод проектирования ведь писались программы и до ООП. Проектирование как и сами языки не стоят на месте отрицать опыт того что было до ООП конечно нельзя но информации по ним сейчас найти очень сложно(если есть ссылки на информацию по этим методам дай ссылки пожалуйста). Просто ООП инструмент которым модно пользоватся сейчас.
IMHO*IMHO
Не всегда новое значит лучшее.
← →
Vuk (2003-09-30 12:46) [95]to euru:
>Другое дело метод проектирования. Он влияет на то, как
>проектировщик отобразит реальную систему в своей модели.
И мало того, проектирование должно уже выполняться, в отличие от анализа, с учетом языка реализации.
>Помимо объектного подхода еще есть автоматный, функциональный и
>т.д.
Хм... Если пользоваться другими языками, то и подход к проектированию будет другим. Я нигде не вижу здесь противоречия.
← →
euru (2003-09-30 14:40) [96]>Некрофил-затейник__ © (30.09.03 12:29) [94]
Пока искал информацию про АОП, наткнулся на такой сайт:
http://www.cs.ubc.ca/labs/spl/index.html
По-моему, достаточно интересный
>Не всегда новое значит лучшее.
Я бы сказал, не всегда усиленно рекламируемое новое значит лучшее.
>Vuk © (30.09.03 12:46) [95]
По-моему, анализ, проектирование и программирование должны рассматриваться раздельно. Это, словами Буча, слабосвязанные объекты. Отношения между ними должны описываться понятием "использование".
При анализе требуется просто исследование реальной модели: выявление сущностей, взаимодействий между ними и с внешним миром, каких-то закономерностей и т.д. Это еще называется декомпозицией.
При проектировании используются полученные результаты предыдущего шага для построения модели реальной системы (это уже синтез). При этом используется какой-то определенный метод проектирования. В идеале, конечно, должен использоваться тот метод, который наиболее точно отобразит реальную систему в модель.
При программировании (реализации) полученной модели используются опять-таки результаты предыдущего шага (проектирования). Опять-таки в идеале желательно использовать язык программирования, с помощью которого можно наиболее точно и естественно реализовать полученную модель (вряд ли С++ является естественным языком для реализации ИИ, а Пролог - для задач линейного программирования).
Обычно же поступают наоборот. Сначала выбирают, на каком языке будет реализовываться система (ограниченность собственных ресурсов, требование заказчика), и делают анализ и проектирование с учетом выбранного зарание языка.
← →
Vuk (2003-09-30 14:59) [97]Я ж говорю - на анализ выбор языка не влияет никак. А вот на проектирование...
← →
euru (2003-09-30 15:24) [98]>Vuk © (30.09.03 14:59) [97]
Почему? Если заранее выбрать язык программирования, то это и на анализ повлияет: мы невольно (или явно) будем использовать это знание при анализе. А это, в общем случае, исказит наш анализ (тут можно вспомнить, по-моему, Гейзенберга: использование инструмента в опытах влияет на результаты опыта).
Пример. Есть система, состоящаяя из множества разнородных объектов. Эти объекты совершают какие-то действия. Нужно вести для этих действий логи. Как это реализовать?
← →
vuk (2003-09-30 15:54) [99]>Как это реализовать?
На этапе анализа это пофиг, т.к. там достаточно знать что именно происходит, выявить процессы, а уж как это будет реализовано - задача для этапа проектирования, а то и кодирования.
← →
euru (2003-09-30 16:09) [100]ОК. Допустим, при анализе выявили все, что нам нужно. Как в общих чертах будет выглядеть эта модель? (Код необязательно :), мы же пока проектируем.)
← →
vuk (2003-09-30 16:31) [101]Например так: имеется сущность "Операция", которая при переходе в состояние "Завершено" (или вообще при всех переходах состояний) осуществляет запись в лог.
← →
euru (2003-09-30 19:02) [102]В ходе анализа выяснили, что у нас M независимых сущностей. В каждой такой сущности есть Ni(i = 1..M) операций, требующих записи в лог, для каждой сущности (количество операций может быть различно).
По отношению к этим М сущностям чем является сущность "Операция"? Каким образом она будет знать, что у одной из сущностей совершилась операция?
А еще возможны такие варианты:
- запись в лог перед совершением операции;
- в зависимости от состояния системы запис в лог подразумевает запись в файл, вывод на экран, отправка уведомления;
← →
vuk (2003-09-30 19:15) [103]to euru:
>По отношению к этим М сущностям чем является сущность
>"Операция"?
Эти сущности могут являются, например, атрибутами операции.
>Каким образом она будет знать, что у одной из сущностей
>совершилась операция?
Операция совершается над чем-то и сам же объект "операция" занимается записью в лог. То есть операция уже обладает знаниями о своем завершении.
>- запись в лог перед совершением операции;
См. выше: (или вообще при всех переходах состояний)
>- в зависимости от состояния системы запис в лог подразумевает
>запись в файл, вывод на экран, отправка уведомления;
Это детали реализации. На этапе анализа это пофиг, я уже про это говорил. Достаточно знать, что есть возможность записи в лог.
← →
euru (2003-09-30 19:37) [104]>Эти сущности могут являются, например, атрибутами операции.
Варианты:
- сущность Операция содержит в себе все экземпляры сущностей М (у каждой сущности может быть несколько экземпляров);
- сущность операция является предком сущностей, требующих регистрации;
- каждая сущность содержит в себе сущность Операция;
- какой-то другой вариант?
>Операция совершается над чем-то и сам же объект "операция" занимается записью в лог. То есть операция уже обладает знаниями о своем завершении.
Т.е. каждая операция, требующая регистрации, знает о существовании сущности Операция и с помощью нее сама делает регистрацию? Или я не так понял?
>Это детали реализации. На этапе анализа это пофиг, я уже про это говорил. Достаточно знать, что есть возможность записи в лог.
Все-таки это детали анализа. (К примеру, при проектировании самолета недостаточно знать, что он должен летать. Желательно бы еще знать детали: на каких скоростях, на какой высоте. Это поможет сделать правильную аэродинамику, подобрать количество и мощность двигателей и т.д.) А детали реализации - это, например, реализовать перебор элементов - в цикле или рекурсивно.
← →
vuk (2003-09-30 20:03) [105]>Или я не так понял?
Есть сущность "Операция", у нее есть атрибуты - ссылки на другие сущности, над которыми операция производится. Так понятнее?
>Все-таки это детали анализа.
Тогда исходная задача поставлена неверно. Напоминаю, что изначально имелось в виду то, что запись производится в разные места в зависимости от состояния системы, то есть это свойство системы и это может быть, например, отдельный сервис в ее составе, через который будут работать все, кому нужна запись в лог. В результате получается, что использование того или иного метода записи - дело реализации этого сервиса.
← →
euru (2003-09-30 21:03) [106]Уточняем систему.
Есть некоторые сущности М1, М2, ... Mn. Каждая сущность может быть представлена несколькими экземплярами. Каждая сущность обладает своим набором операций, некоторые из этих операций одинаковы в разных сущностях. Необходимо, чтобы некоторые из этих операций регистрировались. Причем возможен вариант, что для одних экзмпляров одной и той же сущности регистрация необходима, а для других не нужна. Регистрация может осуществляться на различные носители информации. Какой именно выбрать носитель информации зависит от состояния системы в момент записи.
Проектируем модель.
Описываем сущности М1, М2 и т.д. Общих родителей будем искать?
Вводим сущность для регистрации операций, назовем ее Р. Атрибутами этой сущности будут ссылки на коллекции экземпляров для каждой сущности М1, М2, ... Еще одним атрибутом будет коллекция сущностей, реализующих какой-то определенный вид регистрации информации.
Когда какой-то экземпляр сущности выполняет какую-то операцию, он проверяет:
1. нужно ли ему ее регистрировать
2. если нужно, то запросить у системы, как именно регистрировать в данный момент (выбрать вид регистратора)
3. послать регистратору информацию для регистрации перед выполнением
4. выполнить операцию
5. послать регистратору информацию для регистрации после выполнения
← →
vuk (2003-09-30 22:04) [107]А если так?
Есть Есть некоторые сущности М1, М2, ... Mn. Операция - это, в свою очередь, некая сущность, которая предназначена для манипуляции экземплярами M. То есть эти экземпляры выступают как атрибуты операции. Что и когда нужно регистрировать - решает сама операция на основании состояния своих атрибутов. Для регистрации чего-либо операция обращается к регистратору. Что делает регистратор дальше, нас на данном этапе не интересует - ему сказано регистрировать - он регистрирует, а уж как и где - дело регистратора.
← →
euru (2003-10-01 12:28) [108]Система остается без изменений.
Уточняем модель.
Вводим сущность Единичная операция. Ее назначение: регистрация одной определенной операции одной из М-сущностей. Атрибутами этой сущности будет список всех М-сущностей, имеющих такую операцию. В свою очередь, элементом этого списка будет список экземпляров данной М-сущности, для которых нужно регистрировать эту операцию.
Система знает список всех Единичных операций О1, О2, ..., Ор.
Когда какой-то экземпляр М-сущности выполняет какую-то операцию, то:
1. он должен определить, регистрируется ли данная операция (например, запосив у системы, есть ли для данной операции соответствующая сущность О).
Если не регистрируется, то просто выполнить ее, иначе:
2. Каким-то образом передать найденной О-сущности, что он будет выполнять эту операцию.
3. О-сущность ищет среди зарегистрированных для данной М-сущности нужный экземпляр.
4. Если поиск успешен, сообщает Регистратору (Р-сущности) о необходимости зарегистрировать операцию О-сущности для экземпляра М-сущности перед выполнением операции.
5. О-сущность выполняет нужную операцию М-сущности.
6. Если поиск на шаге 3 был успешен, сообщает Р-сущности о необходимости зарегистрировать операцию О-сущности для экземпляра М-сущности перед выполнением операции.
Примечания.
1. Куда и как регистрировать Р-сущность определяет на основании состояния всей системы и переданных ему экземпляров М- и О-сущностей.
2. В общем случае сигнатура данной операции для каждой М-сущности может быть различной, поэтому О-сущность должна знать все сигнатуры М-сущностей.
← →
Vuk (2003-10-01 14:26) [109]А зачем так сложно? Может все же проще?
Если у нас M являются активными объектами, то есть сами выполняют операции, то никакие лишние сущности не нужны и экземпляры M самостоятельно регистрируют все, что нужно. Если же M являются пассивными объектами и действия выполняются над экземплярами, то я уже все описал.
Можно только дополнительно уточнить для второго случая.
Операция О знает, какие экземпляры M нужны ей для корректной работы, и может проверить корректность своих атрибутов и знает сигнатуры только тех M, которые ей необходимы для работы. На остальные ей начхать. Операция знает последовательность действий, которые нужно провести над M для своего выполнения. Также операция знает, когда и как нужно выполнять регистрацию состояния, которой занимается Р.
← →
euru (2003-10-01 15:40) [110]>А зачем так сложно?
Я пытаюсь спроектировать систему, используя методы ОО-проектирования, т.е. выявить классы (это сущности), определить их атрибуты и поведение (выполнение каких-то операций), а также возможные взаимодействия между ними. Возможно, я пошел не по тому пути, тогда жду ваш вариант.
>Если у нас M являются активными объектами,
Экземпляры М-сущностей являются активными объектами, потому что они выполняют операции, изменяя при этом состояние системы (свое состояние и/или состояние других объектов).
>Операция О знает
Что такое операция О? Это сущность? Если да, то какие у нее атрибуты и поведение, как именно она взаимодействует с М-сущностью?
И надо еще учесть, что мы проектируем систему, которая будет работать длительное время, в течение которого могут произойти изменения как с М-сущностями, так и с О-сущностями.
← →
Vuk (2003-10-01 15:56) [111]>Что такое операция О? Это сущность?
Если рассматривать вариант 2, то да. В этом случае атрибутами будут являться экземпляры M (один или несколько) и какие-то дополнительные атрибуты, необходимые для выполнения операции. Для каждого конкретного действия может быть свой класс операции. Взаимодействие же с М будет зависеть от того, чем конкретно О занимается.
Если же операции выполняются не над объектом, а самим объектом, то все эти построения совершенно не нужны.
← →
Некрофил-затейник__ (2003-10-02 08:54) [112]up
← →
euru (2003-10-02 11:13) [113]>Некрофил-затейник__ © (02.10.03 08:54) [112]
Еще раз спасибо за помощь :)
Ваша модель очень проста и лаконична :))))
>Vuk © (01.10.03 15:56) [111]
Сорри. На работе новое задание появилось, так что я некоторое время буду занят. Но ближе к вечеру (в крайнем случае, завтра) я продолжу обсуждение.
← →
Некрофил-затейник__ (2003-10-02 13:54) [114]>euru
мне просто тема интересна.
← →
euru (2003-10-03 14:36) [115]>Vuk © (01.10.03 15:56) [111]
Да у нас, оказывается, аудитория есть :)
Анализ системы.
Чтобы упростить моделирование, предлагаю рассмотреть систему с минимальным количеством элементов и построить для нее модель, но при этом учитывать, что при моделировании реальной системы элементов будет гораздо больше.
Предлагаю такой вариант.
Есть три М-сущности М1, М2, M3. Каждая сущность может быть представлена несколькими экземплярами (от 1 до n). Каждая сущность обладает набором операций, описывающих ее поведение.Некоторые из этих операций должны регистрировать свои действия. Допустим, у М1 - это операции О1 и О2; у М2 - операции О1 и О3; у М3 - операции О2 и О3.
Для каждой регистрируемой операции есть О-сущности. Их назначение - для заданной операции заданной М-сущности и дополнительных параметров зарегистрировать операцию на носителе информации.
Носители информации определяются Н-сущностями. Их назначение - зафиксировать входящую информацию от О-сущности.
Будут какие-нибудь уточнения?
← →
Vuk (2003-10-03 15:06) [116]Да здесь, на мой взгляд, все элементарно.
1. Если операции выполняются самими экземплярами M, то никакие О-сущености не нужны вообще, это лишняя деталь здесь. Экземпляры М при выполнении операций сами зарегистрируют все, что им нужно.
О-сущности нужны только тогда, когда операция не является принадлежностью M. В этом случае Операция является самостоятельной сущностью, внешней для экземпляров М, над которыми эта операция производится. Я уже об этом писал несколько раз.
2. На уровне, где рассматриваются M1..Mn про носители можно забыть, т.к. важен сам факт регистрации, а не конкретный носитель. Достаточно иметь Регистратор. А вот при анализе на уровне Регистратора можно вспомнить и о носителях.
← →
euru (2003-10-03 16:33) [117]Операции являются непосредственной частью М-сущности, потому что:
1. их выполнение может зависить от внутреннего состояния М-сущности, неизвестного Регистратору;
2. они существуют независимо от того, нужно или нет их регистрировать.
Таким образом, отделение операции от самой М-сущности будет не соответствовать реальной системе и усложнит ее модель.
Процесс (событие) регистрации не является непосредственной частью М-сущности. В идеале М-сущность при выполнении операции ничего не должна про регистрацию, т.е. алгоритм выполнения операции не должен включать шаги регистрации.
Таким образом, внесение процесса регистрации (возбуждения события о регистрации) в операцию М-сущности также не соответствует реальной системе и также усложнит модель.
С другой стороны, выполнение операции, которую необходимо регистрировать, должно быть зарегистрировано. Значит, должны быть сущности (возможно, одна сущность), которые будут выполнять необходимую регистрацию для определенных операций определенных экземпляров М-сущностей. При этом об их существовании ни М-сущности, ни их операции не должны знать.
Я пока не вижу, как это можно решить с помощью ООД.
← →
vuk (2003-10-03 16:48) [118]>Таким образом, внесение процесса регистрации (возбуждения
>события о регистрации) в операцию М-сущности также не
>соответствует реальной системе и также усложнит модель.
IMHO как раз наоборот, это резко упрощает дело, т.к. всегда четко понятно, на ком лежит ответственность за инициацию регистрации (в данном случае - на экземпляре М).
← →
euru (2003-10-03 17:33) [119]Выполнение операции - это выполнение каких-то вполне определенных действий, по истечению которых операция будет считаться завершенной. Причем это никак не зависит, регистрируется операция или нет.
Внесение регистрации в операцию приведет к следующему. В операцию будут добавлены действия, связанные с регистрацией. Это не увеличит сложность всей модели (где-то эти действия все равно должны были выполняться), но увеличит сложность М-сущности, не имеющуюся в реальной системе.
Как будет выглядеть модель? Так как в общем случае регистрируемые операции будут различны даже для разных экземпляров одной М-сущности, то возможны 2 варианта:
1. действия, связанные с регистрацией, будут выполняться на уровне М-сущностей (классов в ООД);
2. действия, связанные с регистрацией, будут выполняться на уровне экземпляров М-сущностей (объектов в ООД).
В первом случае необходимо будет определить дополнительные М-сущности для всех возможных комбинаций регистрируемых операций. В реальной системе таких сущностей нет.
Во втором случае в каждую регистрируемую операцию придется добавить проверку, а не регистрируется ли данная операция в этом экземпляре. А также в М-сущности определить атрибуты, определяющие, какие операции у данного экземпляра должны регистрироваться.
Где же здесь упрощение?
А ведь еще и система может со временем развиваться, причем по нескольким направлениям.
1. Через некоторое могут появиться новые регистрируемые операции, а в некоторых старых, наоборот, регистрация отмениться.
2. Может появиться еще какой-нибудь процесс, подобный регистрации. С другой стороны, регистрация может быть вообще отменена.
← →
euru (2003-10-03 18:49) [120]>vuk ©
Рабочая неделя закончилась. А в выходные у меня не будет возможности выйти в Интернет. Если есть желание, можно будет продолжить на следующей неделе.
>Некрофил-затейник__ ©
Может за выходные еще несколько решений предложите? :)
Это эмоции. Просто было неожиданно узнать, что кто-то еще наблюдает за нашей дискуссией с Вуком.
← →
iZEN (2003-10-04 09:46) [121]Касательно баз данных и хранимых процедур.
Для vuk © (18.09.03 16:45) [30]:
Я вообще не очень представляю, как можно делать unit-тесты на систему, у которой почти вся логика живет на сервере БД, а клиент почти только отображением и вызовами процедур и занимается. Не пользовательский же интерфейс тестировать...
Я тут одно мнение вычитал в книжке "Горький вкус ava"
http://www.piter.com/book_about.phtml?id=978588782323&web_ok=yes
, что в трёхуровневой системе при работе с БД можно полностью отказаться от хранимых процедур и переложить всю логику бизнес-приложения на слой сервера приложений. Увеличение быстродействия (понятно, что х.п. выполняются быстрее любого прикладного кода) достигается за счёт кэширования команд, результатов запросов в сервере приложений, кардинального уменьшения удалённых вызовов клиентом сервера с помощью программной прослойки - "фасада".
Автор книжки приводит несколько примеров, каким образом полностью абстрагироваться от БД, делая всю систему независимой от сторонних разработчиков.
← →
Vuk (2003-10-04 11:57) [122]to iZEN:
Если не стоит задача абстрагирования от БД или автоматического распределения нагрузки, то я вообще не вижу смысла в построении системы с количеством звеньев больше двух. Трехзвенка ради трехзвенки? А оно надо? Ведь получается лишнее усложнение как взаимодействия так и внутренней архитектуры приложения. Да и где гарантия того, что среднее звено и взаимодействие с ним получится построить эффективнее, чем взаимодействие с сервером БД? К тому же абстрагирование от ДБ получается довольно-таки условное, т.к. для эффективной работы на другом сервере скорее всего придется перекраивать среднее звено. Если оно, конечно, не работает чисто на хранимых процедурах. :o) И чем это тогда лучше двузвенной системы?
← →
iZEN (2003-10-04 12:27) [123]Для Vuk © (04.10.03 11:57) [122].
Так дело может обернуться обратной стороной: программисты будут вынуждены поддерживать ещё и бизнес-логику в проприетарной БД, таким образом возлагая на себя ответственность за правильную работу б.л. в БД, что, согласитесь, специфично.
Если имеется независимый от БД слой сервера приложений (и клиента), то программистам придётся поддерживать только это ПО (в дебри конфигураций различных БД) они уже могут не смотреть - для них актуально только структура таблиц и связей главный/подчинённый, индексы и всё!
Слой "фасада" (кстати, это - одноимённый паттерн проектирования) успешно (я не вижу каких-то сильных заморочек) реализуется в сервере приложений на том языке программирования, на котором пишется сам сервер (Delphi, Java и т.д.).
← →
Vuk (2003-10-06 10:09) [124]to euru:
>Выполнение операции - это выполнение каких-то вполне
>определенных действий, по истечению которых операция будет
>считаться завершенной. Причем это никак не зависит,
>регистрируется операция или нет.
Регистрация в любом случае не может повлиять на возможность завершения операции. Это и так понятно.
>Это не увеличит сложность всей модели, но увеличит сложность
>М-сущности, не имеющуюся в реальной системе.
То есть сложность чего-то увеличивается в любом случае. Просто в одном случае это будут лишние сущности, а в другом - небольшое (на мой взгляд) усложнение функционирования существующих. А то, что лишние сущности не стоит плодить без необходимости, наверное помните.
>В первом случае необходимо будет определить дополнительные
>М-сущности для всех возможных комбинаций регистрируемых
>операций.
Вот здесь не понял. Зачем? Ведь в этом случае операция и сущность неразделимы (операция - аналог метода объекта). Вы же не описываете новый класс для введения каждого метода.
to iZEN:
Не понял. А откуда взялась проприетарная БД? О ней вроде как и речи-то не было...
>Слой "фасада" успешно реализуется в сервере приложений
Средний слой для реализации паттерна вовсе не обязателен. С таким же успехом "фасад" может быть расположен на клиенте (в системе с двумя уровнями).
← →
euru (2003-10-06 10:23) [125]Vuk © (04.10.03 11:57) [122]
Не стоит забывать, что после внедрения продукта мир не замирает, а продолжает развиваться. С течением времени в продукт придется вносить изменения. И чем слабее будут связи между слоями хранения информации, ее обработки и предоставления клиенту, тем легче будет сопровождать такую систему. Пример тому SAP R/3.
Так что с моделью про регистрации операций?
← →
vuk (2003-10-06 10:59) [126]to euru:
>И чем слабее будут связи между слоями хранения информации, ее
>обработки и предоставления клиенту, тем легче будет сопровождать
>такую систему.
Я приводил пример с системой, где вся работа ведется только через хранимые процедуры. По сути это тот же "фасад", только реализованный несколько иначе. При этом эффективность работы с данными выше, чем если бы бизнес-логика располагалась в отдельном слое. Клиентское приложение не знает как хранятся данные (оно даже не имеет доступа к таблицам данных) и как они обрабатываются. Для него существует только процедурный интерфейс к БД и этот интерфейс реализует всю бизнес-логику. К тому же данные сами по себе, в отрыве от бизнес логики, смысла не имеют.
>Так что с моделью про регистрации операций?
Так я ж уже сказал, что на мой взгляд оптимальным решением будет то, когда операция сама регистрирует ход своего выполнения. А уж чем она при этом является - не важно.
← →
euru (2003-10-06 12:39) [127]>vuk © (06.10.03 10:59) [126]
Сорри. Произошла небольшая задержка между временем получения и временем ответа, поэтому [124] прозевал.
>...небольшое (на мой взгляд) усложнение функционирования существующих.
Во-первых, не факт, что усложнение будет небольшим. Во-вторых, такая модель уже не так точно соответствует реальной системе (что в дальнейшем может отрицательно сказаться на модели).
>...Ведь в этом случае операция и сущность неразделимы (операция - аналог метода объекта).
Построим модель одной из М-сущностей - например, М1.
class M1
{
...
o1() {};
o2() {};
...
}
В этой сущности реализованы операции О1 и О2, но пока они не знают ничего про регистрацию. В ходе дальнейшего анализа выясняется, что некоторые экземпляры (не все) этой сущности должны регистрировать некоторые операции, в общем случае разные для для каждого экземпляра. Допустим, выяснилось, что есть следующие варианты:
- экземпляр не регистрирует операции;
- экземпляр регистрирует операцию О1;
- экземпляр регистрирует факт запуска операции О1 и операцию О2.
Как расширить существующую модель?
1. Использовать наследование - наиболее рекомендуемый способ в ООД (в первом же практическом примере Буч создал описание датчиков, которых нет в реальной системе).
class M1
{
...
o1() {};
o2() {};
...
}
class M1_O1: M1
{
o1()
{
R.log("M1", "O1", BEFORE);
super.o1();
R.log("M1", "O1", AFTER);
}
}
class M1_O1O2: M1
{
o1()
{
R.log("M1", "O1", BEFORE);
super.o1();
}
o2()
{
R.log("M1", "O2", BEFORE);
super.o2();
R.log("M1", "O2", AFTER);
}
}
Теперь для каждого вида экземпляра существует собственный класс - потомок сущности М1.
Однако в будущем может так случиться, что процесс регистрации в реальной системе изменится (будут регистрироваться дополнительные операции, поменяется способ регистрации текущих операций, например, регистрация некоторых отменится), тогда нужно будет внести изменения в модель. Если придерживаться данного способа решения, тогда нужно будет порождать дополнительные М-сущности, являющиеся потомками либо класса М1, либо его потомков, которые будут учитывать эти изменения.
2. Реализовать все известные на момент проектирования виды регистрации в самой М-сущности
class M1
{
private:
isLog_o1(...): Boolean;
isLog_o2(...): Boolean;
public:
o1()
{
if isLog_o1(BEFORE)
R.log("M1", "O1", BEFORE);
// Здесь выполняется сама операция
if isLog_o1(AFTER)
R.log("M1", "O1", AFTER);
}
o2()
{
if isLog_o2(BEFORE)
R.log("M1", "O2", BEFORE);
// Здесь выполняется сама операция
if isLog_o2(AFTER)
R.log("M1", "O2", AFTER);
}
}
В данном случае уже усложняется сама М-сущность: мало того, что она сама регистрирует операции, но она еще и сама должна определять, нужно ли регистрировать эту операцию для данного экземпляра. Причем эта проверка будет проводиться во всех регистрируемых операциях всех объектов. И ведь не факт, что проверка будет тривиальной - она может занять непозволительно много времени.
Так ведь еще и М-сущностей может быть гораздо больше, а у них регистрируемых операций может быть тоже не 2. Да и экземпляры этих сущностей регистрируются по-разному.
А теперь еще учтем дополнительный пункт 2 из [119] и попытаемся его реализовать. Во что это выльется? Так ли уж это будет небольшое усложнение?.
← →
Vuk (2003-10-06 13:01) [128]to euru:
>Во-вторых, такая модель уже не так точно соответствует реальной
>системе
Вроде как система только проектируется и имеется необходимость протоколирования операций. Что значит "неточно соответствует"? Неточно соответствует требованиям? Вроде нет, т.к. требуется протоколирование. Тогда что?
>В данном случае уже усложняется сама М-сущность: мало того, что
>она сама регистрирует операции, но она еще и сама должна
>определять, нужно ли регистрировать эту операцию для данного
>экземпляра.
Совершенно верно. Действие должен выполнять тот, кто обладает максимальными знаниями для выполнения этого действия. Тем более, что для правильной регистрации действия может возникнуть необходимость доступа к внутренней структуре М...
>Причем эта проверка будет проводиться во всех регистрируемых
>операциях всех объектов. И ведь не факт, что проверка будет
>тривиальной - она может занять непозволительно много времени.
Ну так эта проверка все равно будет производиться, не в этом месте, так в другом... Проще и легче от этого не будет.
>А теперь еще учтем дополнительный пункт 2 из [119] и попытаемся
>его реализовать.
Вот это, как я понял:
>2. Может появиться еще какой-нибудь процесс, подобный
>регистрации. С другой стороны, регистрация может быть вообще
>отменена.
Это как? Нужно иметь возможность прикрутить неизвестно что, неизвестно к чему и неизвестно зачем? Или как?
← →
euru (2003-10-06 14:37) [129]>Vuk © (06.10.03 13:01) [128]
Так ведь операция уже запротоколирована, а регистрация не имеет никакого к ней отношения.
Пример. Есть сущность "Помещение", у нее есть операции "Войти в Помещение" и "Включить Освещение".
Первая операция включает такие, например, шаги:
1. Открыть дверь в помещение.
2. Войти.
3. Закрыть за собой дверь.
Вторая операция выполняется так:
1. Повернуть рычаг выключателя освещения в положение "Вкл."
Таких помещений и выключателей в здании может быть много. И только у некоторых из них нужно регистрировать проникновение в помещение или включение освещения. Причем есть регистрация или нет ее, алгоритм операции остается без изменений. За регистрацию отвечает другая подсистема, независимая от от этой. И не обязательно (и даже нежелательно) им знать о внутренней структуре друг друга.
Проверок тоже можно избежать - надо просто создать все возможные классы данной М-сущности, учитывающие необходимые варианты регистрации. А при создании нужного экземпляра вызвать соответствующий класс. Вот только при этом сама М-сущность размножится...
Да. Должна быть возможность в будущем прикрутить известно что, известно к чему и известно как. А затраты на использование такой возможности должны быть минивальны. Если будет такая возможность, то сопровождение такого продукта будет гораздо проще и эффективнее. В программировании такие же приемы есть, и их же не рассматривают как какой-то недостаток. Это всякие callback-функции, интерфейсы, плагины или даже те же скины.
← →
vuk (2003-10-06 15:35) [130]>И только у некоторых из них нужно регистрировать проникновение в
>помещение или включение освещения
Насколько я понимаю, это определяется раз и навсегда, то есть при создании экземпляра. Так? Тогда получается, что необходимость регистрации конкретного действия - типичный кандидат на внесение в атрибуты экземпляра. То есть что и когда регистрировать определяет конкретный экземпляр M. А проверки в таком случае не занимают много времени.
>Проверок тоже можно избежать - надо просто создать все возможные
>классы данной М-сущности, учитывающие необходимые варианты
>регистрации. А при создании нужного экземпляра вызвать
>соответствующий класс. Вот только при этом сама М-сущность
>размножится...
Опять не понятно. Если критерии, по которым проводятся проверки статичны, то есть определяются раз и навсегда при создании экземпляров М, то как я уже выше заметил, проверки не занимают много времени. Если же критерии динамические, то во-первых проверки придется производить всегда, а во-вторых получается, что при изменении критериев должен быть удален старый экземпляр и создан новый, который соответствует новым критериям. Что-то здесь не то...
>Должна быть возможность в будущем прикрутить известно что,
>известно к чему и известно как.
Если все именно так, то я не вижу никаких проблем.
← →
euru (2003-10-10 20:38) [131]Однако, задержался я с ответом... Однако, работа...
Я буду отвечать снизу вверх.
>Если все именно так, то я не вижу никаких проблем.
Кроме этих координат (что, где и как) нужно еще учитывать координату времени (когда). Обычно реальная система продолжает развиваться и после того, как была спроектирована, разработана и внедрена ее модель. И наверняка наступит такой момент "когда", когда неизвестные до этого "что", "где" и "как" станут вполне определенными. А эти новые изменения нужно будет внести в уже действующую модель. И чем меньше изменений придется внести, тем больше будет вероятность, что в модели не будет ошибок.
Какой в таком случае должна быть модель? Идеально было бы, если бы модель абсолютно полностью соответствовала реальной системе. Тогда бы и изменений не надо было вносить - она бы реагировала на них также, как и моделируемая ею система. В действительности же такая модель не требуется - обычно достаточно, чтобы она моделировала только какие-то существенные элементы. И чем более точно удастся смоделировать эти элементы, тем больше они будут соответствовать элементам реальной системы.
В чем разница между существенными элементами модели и реальной системы? Возможно я ошибаюсь, но я пока вижу всего два пункта:
1. Отсутствие в модели свойств, которые мы посчитали несущественными.
2. Появление в модели свойств, которых нет в реальной системе, но которые упрощают ее моделирование.
В первом случае процесс контролируемый. Мы точно знаем, где упростили модель, и в случае появления у реальной системы новых свойств, влияющих на несущественные параметры, мы сможем их уточнить, уточняя одновременно и саму модель.
Во втором же случае все зависит от того, где используются эти дополнительные свойства. Если они являются составной частью существенных элементов, то изменения в реальной системе могут привести к тому, что их присутствие в этих элементах только усложнит изменение модели. Если же они отделены от существенных элементов, и связь между ними односторонняя (т.е. только дополнительные свойства имеют информацию о существенных элементах, но не наоборот), то изменение существенного элемента затронет только те его свойства, которые есть и в реальной системе.
Что-то здесь не то...
Естественно, не то. Ведь в реальной системе М-сущность и регистратор независимые объекты. Ни при создании М-сущности, ни при ее существовании она не должна ни проверять, ни выполнять каких-то дополнительных действий, связанных с регистрацией. Регистратор тоже не должен обладать информацией о М-сущностях: невозможно заранее определить все возможные М-сущности и все их операции. В его задачу входит правильно зарегистрировать конкретную операцию конкретной М-сущности.
Насколько я понимаю, это определяется раз и навсегда, то есть при создании экземпляра.
Как я уже писал выше, система со временем может эволюционировать. И чтобы модель соответствовала реальной системе, в нее нужно будет вносить изменения, поэтому "раз и навсегда" действительно только до первого изменения модели. Присутствие дополнительных элементов в сущностях может привести к тому, что в один прекрасный момент проще будет провести анализ и построить модель заново, чем отслеживать зависимости между свойствами самой сущности и дополнительными свойствами, внесенными в сущность при проектировании.
Лучшим решением, по-моему, было бы введение дополнительной сущности, которая обладала бы информацией как о всех М-сущностях, так и о регистраторах. В свою очередь, ни те, ни другие не знали бы о ее существовании. Тогда, с одной стороны, изменение свойств сущностей реальной системы отразилось бы только на соответствующих свойствах сущностей модели и никак не затронуло бы свойства дополнительной сущности. А с другой стороны, изменения, связанные с регистрацией операций, коснулись бы только этой дополнительной сущности и никак не отразились бы на сущностях модели.
Осталось только узнать, как это можно сделать с помощью объектно-ориентированного проектирования.
← →
vuk (2003-10-10 21:53) [132]>Ведь в реальной системе М-сущность и регистратор независимые
>объекты.
А в реальных системах бывает по-разному. Может быть журнал (aka лог), в который кто хочет пишет, что хочет и это уже предлагалось. А может быть подобие датчика, который будет реагировать на какие-то изменения наблюдаемого объекта. Только вот если у Вас регистратор понимается как датчик, то следует помнить, что даже в реальной жизни датчик подключается к чему-то (разъемы на датчике и ответные разъемы на объекте измерения) и измеряет что-то конкретное (например - напряжение).
Проводя аналогии в область анализа разработки ПО приходим к тому, что наблюдаемый объект должен иметь какие-то средства взаимодействия с регистратором а также выдавать ему информацию.
В терминологии объектной модели можно сказать, что М должен предоставлять некий интерфейс, которым воспользуется регистратор. Точно так же регистратор должен предоставить экземпляру М какой-то интерфейс, который М будет использовать для того, чтобы регистратор узнал об изменении состояния М. По наличию конкретного интерфейса у экземпляра M, можно определить, возможно ли подключение к нему конкретного регистратора.
← →
euru (2003-10-11 11:32) [133]>А в реальных системах бывает по-разному.
Допустим, в этой реальной системе эти объекты независимы.
>Может быть журнал (aka лог), в который кто хочет пишет, что хочет
Кто хочет - это кто? Это может быть либо сам объект, выполняющий операцию, либо объект-наблюдатель, отслеживающий операции объекта, сам же журнал пассивен.
>А может быть подобие датчика
Датчик - это не регистратор, это как раз-таки объект-наблюдатель. Он показывает только текущее состояние отслежываемого объекта, но он может фиксировать в регистраторе эти состояния.
> в реальной жизни датчик подключается к чему-то (разъемы на датчике и ответные разъемы на объекте измерения) и измеряет что-то конкретное (например - напряжение).
Интересно, где это у электродвигателя и лампочки такие специальные разъемы, куда нужно подключать вольтметр. И где на вольтметре написано, что данный вольтметр предназначен для измерения напряжения только на лампочках.
А что-то конкретное измеряет только конкретный датчик (конкретный вольтметр измеряет конкретно напряжение, а конкретный амперметр - конкретно силу тока). Но это не значит, что для каждого датчика должны существовать свои разъемы. Туда, куда мы подключали вольтметр, с таким же успехом можно подключить и амперметр. Более того, их можно будет подключить туда одновременно, а в последствии добавить еще какой-нибудь датчик.
>Проводя аналогии ... наблюдаемый объект должен иметь какие-то средства взаимодействия с регистратором а также выдавать ему информацию.
А у меня получилось, что наблюдаемый объект, конечно, может взаимодействовать с регистратором, но не только не должен, но даже и не обязан это делать. Более того, он может даже и не знать, что за ним наблюдают и фиксируют все его операции.
Не отходя от терминологии объектной модели, получаем следующую картину. Есть М-сущности, которые знают, как работают их операции. Есть регистратор, который знает, как и куда фиксировать поступающую на его вход информацию. Так как эти сущности независимые, то никаких интерфейсов взаимодействия, отвечающих за регистрацию, между ними нет. Значит, должна существовать дополнительная сущность (датчик), которая может внедрять конкретные интерфейсы в конкретные М-сущности (или только в отдельные экземпляры этих сущностей) для фиксации их операций.
И как это выразить в объектно-ориентированном подмножестве объектного проектирования?
← →
Vuk (2003-10-11 13:30) [134]to euru:
>Датчик - это не регистратор, это как раз-таки
>объект-наблюдатель.
Да. Возможно я не совсем правильно выразился, но имелось в виду именно это.
>Интересно, где это у электродвигателя и лампочки такие
>специальные разъемы, куда нужно подключать вольтметр.
Два (или три) провода есть? Есть. Вот это и есть место подключения. Это место подключения датчика более-менее универсально и туда можно подключить много чего, но нельзя подключить что угодно, например датчик давления воды.
>И где на вольтметре написано, что данный вольтметр предназначен
>для измерения напряжения только на лампочках.
И не надо. В терминах объектной модели можно сказать, что интерфейс для определенного регистратора могут предоставлять объекты совершенно разных классов. И в этом случае без разницы, какого класса объект. Главное - наличие интерфейса взаимодействия с датчиком.
>А у меня получилось, что наблюдаемый объект, конечно, может
>взаимодействовать с регистратором, но не только не должен, но
>даже и не обязан это делать.
Параметры, которые снимаются с места подключения воздействуют на датчик и путем этого мы можем наблюдать их изменение. То есть в программной среде это сводится к взаимодействию наблюдаемого объекта с наблюдателем или же, если система управляется потоком событий, перехвату потока событий приходящих к наблюдаемому объекту (или исходящих от него). В этом случае следует учесть, что события - это одно, а состояние объекта - совсем другое, если, конечно, это не специальные события сигнализирующие о состоянии объекта.
← →
euru (2003-10-16 19:41) [135]У лампочки, правда, проводов нет, но это к делу не относится (это мое мнение, могу и ошибаться).
Выяснили, что должен быть некий интерфейс между наблюдаемой М-сущностью и объектом-наблюдателем, пересылающим результаты наблюдения в регистратор. Но наблюдение - это все-таки не взаимодействие между наблюдаемым объектом и наблюдателем. Наблюдаемый объект не должен предполагать, что за ним будут наблюдать, и поэтому не обязан каким-либо способом сигнализировать, что у него изменилось состояние или он совершил какое-то действие. Т.е. вся ответственность за наблюдения ложится на объект-наблюдатель. Это он должен знать куда и как внедрить свой интерфейс наблюдения в наблюдаемый объект, чтобы фиксировать его изменения и поведение.
← →
vuk (2003-10-16 20:57) [136]>Но наблюдение - это все-таки не взаимодействие между наблюдаемым
>объектом и наблюдателем.
Если не ошибаюсь, то наблюдения и измерения без взаимодействия не бывает в принципе. Иначе нет возможности зафиксировать изменения в наблюдаемом объекте.
← →
euru (2003-10-16 21:14) [137]а астрономия?
← →
vuk (2003-10-16 21:26) [138]И что, там совсем без взаимодействия? А свет + глаз (или что еще)?
← →
euru (2003-10-16 21:47) [139]Вот именно - свет.
Свет - это не сама звезда (наблюдаемый объект), а то, что с ней было n световых лет назад. Сама звезда не предоставляет никаких интерфейсов. Она просто излучает электромагнитные волны. А мы наблюдаем их с помощью телескопов (встраиваем интерфейс реакции на эти волны).
Причем, с одной стороны, звезде наплевать на наши наблюдения (она как светилась, так и будет светиться), а с другой стороны - не факт, что когда мы за ней не наблюдаем, она светится (эффект закрытого холодильника).
← →
vuk (2003-10-16 22:00) [140]>Она просто излучает электромагнитные волны.
То есть опять же поставляет информацию, которая может быть перехвачена и проанализирована. см. [134]:
<...>в программной среде это сводится к взаимодействию наблюдаемого объекта с наблюдателем или же, если система управляется потоком событий, перехвату потока событий приходящих к наблюдаемому объекту (или исходящих от него). В этом случае следует учесть, что события - это одно, а состояние объекта - совсем другое, если, конечно, это не специальные события сигнализирующие о состоянии объекта.
← →
Анонимщик (2003-10-17 11:51) [141]Сделаю вставку и от себя - расскажу о некоторых проектах, которые сам реализовывал, может, интересно будет, хотел бы увидеть аналогичное.
Самой первой была программа, где с заказчиком я встречался два раза в неделю и сразу, без проектирования, все писал. Итог: деньги мне заплатили заранее обусловленные, но сроки растянулись в три раза. А нервов сколько с обоих сторон было ...
Далее был проект под аппаратуру. Тут этапа проектирования не могло быть в принципе из-за сильной специфики, эта самая аппаратура делалась на глазах и тоже без всякого проекта. Мне непонятно даже было, какие задачи она должна в конце концов решать. Сроки выросли в четыре раза.
Быстрее всего получались демо-версии, где я сам был заказчиком, что позволяло спроектировать почти полностью почти сразу.
Сейчас у меня проект, который в первом приближении реализован, и тоже много аппаратуры, которая тоже до конца не доделана, но хотя бы ясно, что должно быть. Так вот, поскольку мне с начальником удалось пару раз поговорить о цели проекта и я ориентировался именно на возможности этой аппаратуры, которые хорошо знаю, и предполагал, что программа должна реализововывать работу с этими возможностями, то и делал я ее, в общем, недолго, и совсем без перепроектирования. Но вот пришел заказчик, который ориентируется не на аппаратуру (точнее, на нее, но косвенно), а на необходимость решать с ее помощью свои задачи. В результате: нужно перепроектировать базу данных и нужно "чуть-чуть" перепроектировать программу. Это бы я тоже за те же два месяца (или месяц, возможно) сделал, но... начальник говорит: "Выясни у заказчика, что ему нужно", заказчик говорит: "Выясни с начальником задание, я ему рассказал". Боюсь, никогда ничего не заработает, потому как помню и о другом. Не знаю, нормальная ли это ситуация, но в другом проекте мне заказчик говорил: "А эту кнопку смести на пять пикселов вправо, что он был под тем элементом меню, а то мне от кнопки к меню раз триста в день передодить нужно".
И единственный проект, который прошел относительно гладко, начался с двухмесячных обсуждений технического задания, два-три раза в неделю по три часа. После этого программа писалась еще всего два месяца с неархитектурными изменениями. И по объему, возможностям и функциональности это самое большое, что я до сих пор сделал. Причем все более-менее документировано. Сейчас есть необходимость все это довести до очень крутого состояния, и из-за этого все нужно снова переписать, видимо, заново, с учетом выяснившихся деталей, нюансов и возможностей и интеграции с кое-чем другим. Поскольку все это обозримо, то и проблем, видимо, не будет.
Так вот, сравнив усилия, вижу, что попытка полного проектирования экономит и время, и деньги, и нервы.
← →
euru (2003-10-17 16:10) [142]>vuk © (16.10.03 22:00) [140]
Она не поставляет информацию. Она не проектировалась, для того чтобы поставлять информацию. И от того что мы стали за ней наблюдать, у нее не появилось новых атрибутов и она не стала посылать какие-то особые сообщения наблюдателю. Весь интерфейс ложится на плечи наблюдателя. Это он должен знать, куда нужно встроить свой интерфейс в наблюдаемый объект, чтобы получать от него информацию и правильно ее интерпретировать, а если возможно, то и вмешаться в процесс.
То же самое и с лампочкой. Ее напряжение можно измерить, когда она подключена в эл. цепь. Но это не означает, что в этой цепи обязательно должны быть специальные разъемы для подключения измерительных приборов (хотя было бы удобно). Достаточно добраться до токопроводящих элементов этой цепи. А для этого, возможно, придется прокусить изоляционный материал тех самых проводов. Это возможно сделать для любого прибора, измеряющие электрические характеристики цепи и ее элементов. Причем вряд ли проектом был предусмотрен такой вариант подключения датчиков.
А с датчиком измерения давления воды так не получится, потому что он измеряет те характеристики, которых нет у электроцепи. Хотя можно допустить такой вариант (схематично). Если электричество вырабатывает генератор, вращение которого производится с помощью потока воды, то с помощью этого датчика можно замерить давление потока воды, вычислить ее скорость, которая позволит вычислить скорость вращения ротора генератора. Зная сколько оборотов совершает генератор и какие-то его дополнительные характеристики, вычислить напряжение в сети.
Есть еще компьютерные вирусы. Никто же не пишет нормальные программы, заранее встраивая в них интерфейс взаимодействия с вирусами. Всю работу на себя берут сами вирусы. Они находят те уязвимые места, куда можно встроить свой интерфейс, а встроив, могут и поменять поведение программы.
ИТОГО. В общем случае наблюдаемый объект не должен предоставлять никаких интерфейсов или генерировать специальные события для взаимодействия с наблюдателем, но у него должны быть некие места, куда в дальнейшем можно будет "приткнуть" интерфейс. Наблюдатель должен обладать возможностью встраивания своего интерфейса в наблюдаемый объект для получения от него информации, а при необходимости и для воздействия на сам объект.
>Анонимщик © (17.10.03 11:51) [141]
>Так вот, сравнив усилия, вижу, что попытка полного проектирования экономит и время, и деньги, и нервы.
С этим, по большому счету, не поспоришь. Так только если по мелочам...
← →
Vuk (2003-10-17 16:27) [143]to euru:
>Она не поставляет информацию.
Да ну? А излучение как же?
>Но это не означает, что в этой цепи обязательно должны быть
>специальные разъемы
Если Вы еще не поняли, то дело не в разъемах. Дело в том, что любой измеритель измеряет только тот параметр, который умеет измерять при условии, что с наблюдаемого объекта есть возможность снять этот параметр. Точно так же и с программными интерфейсами.
>А с датчиком измерения давления воды так не получится, потому
>что он измеряет те характеристики, которых нет у электроцепи.
Именно! см. выше.
>Никто же не пишет нормальные программы, заранее встраивая в них
>интерфейс взаимодействия с вирусами.
Но дело в том, что исполняемые модули имеют определенную структуру...
>Они находят те уязвимые места, куда можно встроить свой
>интерфейс, а встроив, могут и поменять поведение программы.
Ошибочка, они не уязвимые места находят, а встраиваются в строго определенные места. А уязвимости находят не вирусы, а их авторы.
>Наблюдатель должен обладать возможностью встраивания своего
>интерфейса в наблюдаемый объект для получения от него
>информации, а при необходимости и для воздействия на сам объект.
Это, извините, уже не наблюдатель, а что-то совсем другое.
← →
euru (2003-10-17 18:03) [144]Сначала не по существу.
>А уязвимости находят не вирусы, а их авторы.
Я с этим не спорю. Интеллектуальную часть выполняет человек. И программы пишут не языки программирования. Я подразумевал, что вирусы обладают интерфейсом, в котором есть алгоритм поиска этих строго определнных мест. А этот алгоритм написал автор вируса, хотя и не факт, что он эту уязвимость нашел самостоятельно, а не воспользовался трудами другого человека.
>Это, извините, уже не наблюдатель, а что-то совсем другое.
Ну, можно назвать его агентом. Тоже ведь наблюдает, но при случае и наган может вытащить и пострелять. :)
А теперь по теме.
С вашей легкой руки я узнал про аспектно-ориентированное программирование. Программа про регистрирование операций на языке, поддерживающем АОП, выглядела бы следующим образом (это псевдокод):
class M1 {
void o1(int i) {};
void o2(int i) {};
}
class M2 {
void o2(double d) {};
void o3() {};
}
class M3 {
void o1() {};
void o3() {};
}
class Writer {
static void log(string s) {
write(s);
};
}
Обращаю внимание. М-сущности являются независимыми классами и не имеют каких-либо механизмов для регистрации своих операций. Регистратор (Writer) тоже ничего не знает об М-сущностях.
aspect Log {
pointcut log_o1() = "*.o1(*)";
pointcut log_o2() = "*.o2(*);"
pointcut log_o3() = "*.o2();"
advice call(log_o1()) : around {
Writer.write("Вызов операции o1()");
trigger(); // Здесь происходит вызов метода o1 нужного класса
Writer.write("Операция о1 завершена");
}
advice call(log_o2()) : before {
Writer.write("Вызов операции o2()");
}
advice call(log_o2()) : after {
Writer.write("Операция о3 завершена");
}
При компиляции программы все места, где будет происходит вызов операций o1, o2, o3 независимо от типа класса М-сущности и параметра операции (кроме о3), этот вызов будет заменяться соответсвующей последовательностью описанной в аспекте Log.
Все будет регистрироваться, при этом не понадобилось добавлять дополнительных атрибутов и событий в М-сущности, что пришлось бы сделать в ОО-языке.
← →
euru (2003-10-17 19:40) [145]Ошибочка небольшая
aspect Log {
pointcut log_o1() = "*.o1(*)";
pointcut log_o2() = "*.o2(*);"
pointcut log_o3() = "*.o3();"
advice call(log_o1()) : around {
Writer.write("Вызов операции o1()");
trigger(); // Здесь происходит вызов метода o1 нужного класса
Writer.write("Операция о1 завершена");
}
advice call(log_o2()) : before {
Writer.write("Вызов операции o2()");
}
advice call(log_o3()) : after {
Writer.write("Операция о3 завершена");
}
}
← →
euru (2003-10-20 14:46) [146]up
← →
euru (2003-10-21 19:30) [147]up
← →
Vuk (2003-10-21 19:36) [148]Я дико извиняюсь, но отвечать пока не имею времени.:o(
Страницы: 1 2 3 4 вся ветка
Форум: "Потрепаться";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];
Память: 0.99 MB
Время: 0.036 c
