OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 22 Сентябрь, 2018 19:48

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Четверг, 17 Январь, 2008 13:56 

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье
Хоть здесь и не любят ФП, но вот цитата из "Structure and Interpretation of Computer Programs" (http://mitpress.mit.edu/sicp/full-text/ ... -H-10.html):
Цитата:
A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize our ideas about processes. Thus, when we describe a language, we should pay particular attention to the means that the language provides for combining simple ideas to form more complex ideas. Every powerful language has three mechanisms for accomplishing this:
* primitive expressions, which represent the simplest entities the language is concerned with,
* means of combination, by which compound elements are built from simpler ones, and
* means of abstraction, by which compound elements can be named and manipulated as units.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Четверг, 17 Январь, 2008 14:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
В этом куске в том смысле, в каком я пытался применить "структурировать", сказано organize. Но вот упор делается на combining.. При это "восходящий combining..." Что как-то похоже больше на первый умотип...

Попробую описать точнее, нафига я тут эту тему поднял и чего мне надо :-) Хочется заполучить какой-то небольшой набор мета-правил, верно обобщающих конкретные практические правила разных (хотя бы двух-трёх) сторон разработки ПО. При этом обобщающих не ради красного словца, а чтобы действительно много конкретики из них проецировалось... И, наконец, не хочется лезть за этим в системный подход(ы), теорию(и) систем, т.к. есть большое подозрение, что увязнуть там, отделяя нужные зёрна, можно надолго, а практическая польза в итоге окажется гораздо меньшей, чем от попытки выделить эти несколько мета-принципов программирования из программисткого же опыта...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Четверг, 17 Январь, 2008 23:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Info21 писал(а):
Илья Ермаков писал(а):
... Методы:
а) Декомпозиция ("разделяй и властвуй") - "аналитический метод".
б) Абстракция (последовательное вычленение всё меньшего числа всё более существенных компонент создаваемой структуры) - "синтетический метод".
...

Вот а) и б) -- это не одно и то же?


Почему а) и б) очень тесно связаны - понимаю. Потому что декомпонируя задачу на подзадачи и строя решение, мы на верхнем уровне (решение главной задачи) абстрагируемся от деталей решения подзадач, оставляем несущественные для всей задачи детали каждой подзадачи на уровне её подрешения. Но почему совсем одно и то же?

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

Какие-то братья-близнецы получаются... Но вроде как совсем слить нельзя.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Пятница, 18 Январь, 2008 10:58 

Зарегистрирован: Среда, 12 Декабрь, 2007 19:41
Сообщения: 21
По мне, так а) и б) из первого поста и правда очень близки.
Я бы написал так:
а) анализ, т.е. выделение сущностей, на которые можно разбить задачу
б) синтез, т.е. выстраивание сущностей в определенную структуру (архитектуру)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 00:27 

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье
Илья Ермаков писал(а):
В этом куске в том смысле, в каком я пытался применить "структурировать", сказано organize. Но вот упор делается на combining.. При это "восходящий combining..." Что как-то похоже больше на первый умотип...

В этом куске только перечисление механизмов. Пройдите по ссылке и почитайте, упор там как раз на abstraction, а combination используется при реализации абстракций...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 00:49 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Надеюсь, никто не будет против перевода этого куска SICP?
Цитата:
1.1. Элементы программирования

Мощный язык программирования — это нечто большее. чем просто средство, с помощью которого можно учить компьютер решать задачи. Язык также служит средой, в которой мы организуем свое мышление о процессах. Таким образом, когда мы описываем язык, мы должны уделять особое внимание тем средствам, которые в нем имеются для того, чтобы комбинировать простые понятия и получать из них сложные. Всякий язык программирования обладает тремя предназначенными для этого механизмами:

элементарные выражения, представляющие минимальные сущности, с которыми язык имеет дело;

средства комбинирования, с помощью которых из простых объектов составляются сложные;

средства абстракции, с помощью которых сложные объекты можно называть и обращаться с ними как с единым целым.

В программировании мы имеем дело с двумя типами объектов: процедурами и данными. (Впоследствии мы обнаружим, что на самом деле большой разницы между ними нет.) Говоря неформально, данные — это «материал», который мы хотим обрабатывать, а процедуры — это описания правил обработки данных. Таким образом, от любого мощного языка программирования требуется способность описывать простые данные и элементарные процедуры, а также наличие средств комбинирования и абстракции процедур и данных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 13:14 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1332
Не знаю...

Слова, конечно, все знакомые и смысл даже понимаю.... :о) но не скажу, что у меня за годы работы выработалась чёткая методика или «последовательность шагов» в реализации систем. Конечно, может, это зависит от особенности мышления конкретного индивидума...

Я никогда не выделяю и не стремлюсь к выделению иерархии (иерархий) ИЗНАЧАЛЬНО.
Со временем пришло понимание, что взгляд на систему всегда многопланов и многогранен, поэтому одной чёткой иерархии в системе БЫТЬ НЕ МОЖЕТ. А стремление к нему изначально – дурость несусветная! Поэтому иерархии у меня строятся в процессе анализа и реализации кусков системы. Они «пронизывают» друг друга и пересекаются (как параллельные миры :о) ), имея в основании «определения» совершенно разные критерии размещения элементов и их множеств на уровнях этих иерархий.

Сюда же у меня относится и «критериальность» разбиения на «модули». Здесь всё также зависит от двух факторов: наличия и частотности связи между элементами системы (и их конгломератов).

Кстати, что бы уточнить...
По-моему, или я выразился не совсем точно, или Илья меня не так понял...
Знаменитый «барьер сложности системы» (БСС) в 13% выражается не через

БСС = КВнешС / КвнутрС,

а

БСС = КВнешС / (КвнутрС + КвнешС),

где:
КвнешС – количество внешних связей (между элементами разных подсистем, модулей, блоков)
КвнутрС – количество внутренних связей


Хотя в жизни мне встретилось несколько человек, которым кроме клавы и дисплея ничего для работы больше не надо, но я так не могу. У меня на каждый проект накапливается ворох (стопка) листов, бумажек, «обороток», на которых изображены: где кубики со стрелками и подписями, где куски алгоритмов и описаний полей выделенных объектов, где просто некие предложения на русском языке - «реперные точки»... Чаще всего я сохраняю бумажки с совершенно абстрактными записями наиболее ценных частей системы. Это случаи внесения/удаление элементов в/из множеств(а), потому, что сам факт проведения таких операций может повлечь за собой лавинообразные изменения в объекта-коллекциях фиксации свойств и отношений между элементами системы.

Наибольшее время в проекте у меня уходит на выявление базисных понятий и построение наиболее обобщённых операций над элементами... Иногда на это уходит до 3/4 проектного времени. То есть эти три четверти времени я вообще могу не загружать среду разработки... :о)
В это время модель системы как тесто, я постоянно кручу в голове её «трёхмерную модель», смотря на неё с той или иной точки зрения, анализирую природу взаимодействия элементов, «перемолачиваю» варианты интерфейсов, объектов-носителей аттрибутики и отношений...
Это немного похоже то, как можно манипулировать звёздными системами в трёхмерном представлении в некоторых пошаговых космических стратегиях... :о) Вы крутите и так и эдак, приближаетесь или удаляетесь от участков модели, «разглаживаете» их на плоскость по определённым критериям и проекциям общения и характеристикам элементов.
То есть, вначале я просто «набиваю» «предметку» бессистемной информацией (буквально выделяю из предложений ТЗ и заказчика существительные (объекты), глаголы (некие действия), прилагательные и наречия (атрибутика и качественные/количественные характеристики и показатели всего ранее перечисленного).
Потом, в результате «кручения» модели начинают «играть» «силы притяжения/отталкивания» между выявленными элементами в моей «галактике» и они самопроизвольно «кучкуются» в «центры конденсации». Причём, такие «центры» не одни и те же в одном и том же «мире», - в разных «критериальных вселенных» («проективных плоскостях») они могу не совпадать! Такие «кучкования» и дают основания для синтаксического выражения общности этих элементов (объекты, пространства имён, модули, файлы, структуры – в зависимости от средств используемого ЯП)... Здесь же начинают «сами-собой» «окукливаться» общности и подчинённости – определяются иерархии.

До определённого момента конкретика операций никакой роли не играет. Однако, бывают моменты, когда под давлением требований по оптимизации (память/быстродействие), приходится реорганизовывать данные... В самом начале этапа кодирования всё, о чём можно говорить, как об «элементарной операции» (под определённым углом зрения на систему), В ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ выполняется отдельной исполнимой сущностью (метод, процедура) – даже если это «загромождает код» лишними определениями и сказывается на производительности (что случается редко при «правильно схваченной» архитектуре системы). Такой шаг прежде всего делается для облегчения отладки и локализации ошибок. В дальнейшем, после стабилизации архитектуры системы и снижении «потока заявок на перепроектирование» (поздние итерации цикла разработки :о) ), некоторые из объявленных методов и процедур могут перестать быть отдельными определениями, а их тела «перекочёвывают» в места их вызовов. Основных критериев для принятия такого решения – два: единичность обращения к такому методу в текстах программы и оптимизация. В обоих случаях изначальный код объявления не удаляется, а комментируется. Также комментируются места, куда «перехало» тело метода...

То есть, «этапности» обычно нет... Построение системы идёт параллельно сразу по множеству направлений. Из-за этого случаются казусы, когда начальство, привыкшее к «водопаду» не понимает почему «возникла задержка» в представлении «начавшей работать системы»...
Например, незадолго до Нового Года, я реализовал подсистему отображения характеристик (параметров) полёта самолёта. Трудность была в том, что сами параметры являются значениями различного типа и само их представление носит сугубо неодинаковый вид (например, значение высоты полёта и координат – вещественные величины и непрерывная кривая на графике, а фиксация фактов включения/выключения каких-то подсистем на самолёте – булев тип или «перечисление»(байт) и их представление в графическом виде будет другим). Естественно, что бы сделать универсальную систему для наших изделий, нужно было максимально обобщить подходы для распознавания типа получаемых данных из подсистем самолётов и представления их в окне визуализированных параметров... Работа очень не простая... :о) И сделать её нужно было, как всегда, «вчера»...
Разговор с начальством (упрощённо):
- Через сколько вы рассчитываете получить возможность просмотра графиков?
- Дня через два.
- У вас ведь десятки параметров! Вам ведь осталась неделя! К вечеру вы хотя бы один параметр сможете показать?
- Через два дня! Если я могу показывать хотя бы один параметр – я могу показывать все. Система так спроектирована.
- ??????? Такого НЕ МОЖЕТ БЫТЬ. Так не бывает!...
- Это ООП. Сейчас я прорабатываю обобщённые вещи. Как только каркас представления параметров заработает, мне нужно будет только конкретизировать отдельные небольшие фрагменты алгоритмов для разного типа приходящей информации...
- ??????????????? (коммент: на лице начальства выражение «дяденька, это вы сейчас со мной разговаривали?»)

То есть.
Не смотря на прошедшие уже скоро как 20 лет с начала «повсеместного внедрения» ООП в массы и достаточного времени для возрастания нового менеджерского поколения, обманываться на сей счёт не стоит!... :о) И – программистского, кстати, тоже! Практика планирования и подхода к оценке результативности осталась прежней... Как и практика «копи-пэйста» без проработки архитектурных вопросов: гонится однотипный код для «разных случаев». Как я писАл на КД: для кручения лопастей водяной мельницы, строится не соответствующая местность с нужным профилем ложа реки (по которому что не полей – всё будет крутить колесо мельницы), а делаются попытки строить саму реку во вселенской пустоте без всякой опоры и с метафизикой... :о))))

ЗЫ а, кстати, графики стали выводиться уже к вечеру. Все типы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 14:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Владимир Лось писал(а):
Слова, конечно, все знакомые и смысл даже понимаю.... :о) но не скажу, что у меня за годы работы выработалась чёткая методика или «последовательность шагов» в реализации систем. Конечно, может, это зависит от особенности мышления конкретного индивидума...


Так эта... Отсутствие "чёткой методики" - это тоже есть сама по себе "методика"! И, наверное, за счёт гибкости своей отлично подходящая для задач самого разного рода...
Спасибо, Владимир, за столь интересный рассказ!

На самом деле, когда я выше говорил, что "хочется метапринципов", я, конечно, не имел в виду "методики". "Принципов" - в смысле, каких-то контуров, подстраховывающих от ошибок и подсказывающих, в каком направлении копать...

У меня стиль разработки тоже выработался далеко не "сели - кодируем"... Сначала нужно долго поразглядывать, "пообсасывать" проблему с разных сторон. Потом постепенно начать реализовывать. При этом выработал для себя принцип, что программировать нужно только тогда, когда это происходит легко, "как песня". При первом намёке на "затык" (что-то идёт сложнее, чем ожидалось) нужно бросать клаву и Блэкбокс и возвращаться на стадию "обсасывания", иногда откатываться назад, искать неверное решение, выбирать другое, полностью выбрасывать и перерабатывать какие-то заложенные принципы... Иногда могу ходить два-три дня в раздумьях и не прикасаться непосредственно к "простаивающей работе", пока не будет "эврики". Бумагу с карандашом люблю, но в кое-что почеркать промежуточное, потом выбрасываю... Заметил за собой такое свойство, что не могу проблему "экстернализировать" (на той же бумаге описать и анализировать по частям), могу крутить только образно, в уме, до тех пор, пока решение не сложится (я его не "увижу") сразу целиком... Обычно на небольших проектах у меня бывают два-три таких промежуточных "затыка", потом система уже выстраивается достаточно адекватно - и остаётся неделя-другая кодирования в стиле "как песня" :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 18:58 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1332
Цитата:
И, наверное, за счёт гибкости своей отлично подходящая для задач самого разного рода...

В общем такой подход может и покажется кому-то избыточным, но опыт говорит, что решения получаются более надёжными...
На позапрошлой работе время от времени случались «наезды», что вот мол опять что-то засбоило и пошло не так. В связи с тем, что коллектив был образован и работал до моего прихода уже долгое время, естественно, что вдруг участившиеся случаи сбоев и аварий, все автоматически связали с добавлением в систему переделанных мною модулей... Тем более, что именно в моих логах чаще всего оказывалась «посмертная запись» о недопустимых режимах или выходе значений параметров за безопасные диапазоны (туда, где система просто по логике не могла существовать).... Но, в конце концов, оказалось, что это предыдущий товарищ, разрабатывавший эту подсистему, просто не «уделял столь пристального внимания» логике «ловли» нестандартных состояний системы. То есть, мои модули оказались в роли попугая, которого представлял Хазанов в 80-х годах («Товарищи! В зоопарке тигру не докладывают мяса!») - я, «всего лишь», констатировал факт появления и распространения по системе ошибки. До смены модулей на мои варианты, всё было «тишь да гладь, да божья благодать»! Ну правда иногда связь с антенной прерывалась или её несло чёрти куда с трассы спутника, или картинка на экране «несколько отличалась» от реального положения, или по каналам управления «мусор» принимался, или вдруг программа зависала с ошибками «взаимный дэдлок на канале»...
Дальше – больше. Я мысленно «положил» на все увещевания «делать проще» и претензии и продолжал тихо свою «борозду перелопачивать» - переписывал и совершенствовал свою часть... И вот, на определённом этапе, я, по логам своих модулей, стал указывать что могло привести к очередной ошибке в других модулях, не видя и не зная их внутреннего устройства... :о)))))
Что бы было понятно. Модули мои были просты в плане программной реализации. Но что бы достичь этой простоты ой-как много пришлось мозгами поскрипеть! Та «простота», к которой меня призывали, потом обернулась бы настоящей головной болью! Опыт в этом у меня уже, к сожалению, есть.
Когда-то я зарёкся поддаваться на такие призывы! Пусть зубами скрипят – хоть сточат их нафиг! Мне сознание гарантированной надёжности важнее! Даже если код будет через некоторое время выброшен, опыт, наработанный в процессе обдумывания архитектуры, поиска решений, написания кода, для меня важнее во сто крат!
Буквально во всех системах я стараюсь подходить к первому решению с максимально обобщённой позиции. Как в физике – сначала тяжело получить обобщённое решение. Но, за то потОм его «настройка» на конкретные случаи – лишь «сокращение» переменных одного порядка при заданных условиях и «оконстанивание» переменных... То есть, например, движение спутника можно и по формуле Ньютона считать, но – это – довольно частный случай... Модель движения антенны можно и с равномерными угловыми скоростями считать, но вообще-то там – 80 тонн крутящегося металла + переходные процессы с системе управления + пусковые токи в десятки ампер в обмотках двигателей... Так, что, если хотим достичь точностей порядка долей угловой минуты на всей траектории сопровождения объекта, про линейности надо сразу же забыть!
Или вот сейчас. Возникла задача по отображению траектории полёта самолёта на земную поверхность. Чего проще – точки считал и нарисовал в масштабе карты (а генштабовские карты можно и скачать и Сети)... Угу... просто... А вот когда ставится задача показать полёт над ЛЮБЫМ участком Земли – начинаешь «чесать репу»! Просто? Ну тогда дайте это своим студентам: карта Земли должна быть масштабируема (от изображения всей земли на экране (но не меньше экранна по соотвествующей координате) и до порядка одной тысячной секунды на пиксел), зациклена на прокручивании вдоль экватора («по горизонтали») и позволяла бы выводить полёт самолёта, облетевшего земной шар два раза примерно по экватору... Маленькое уточнение: трасса полёта должна прорисовываться не только точками, но и линиями, между этими точками. Система координат: 0-ой меридиан – Гринвич, 0-ая параллель – экватор, значения восточной долготы и северной широты – положительные углы, а западной долготы и южной широты – отрицательные углы ( -180...+180 и -90...+90 ). Ещё одним контрольным заданием для адекватности представленного решения задачи пусть послужит следующий тест: самолёт взлетает из Анкориджа на Аляске и летит в Елизово на Камчатке, потом – на Гаваи, оттуда – в Новую Гвинею, затем – в Чили и, наконец - в Велингтон в Новой Зеландии. Пусть при этом он постоянно пересекает 180-й меридинан. Пусть студенты нарисуют трассу полёта!... :о) Заранее предупреждаю, что простым циклом в котором выводится массив промасштабированных координат точек трассы полёта ваши студенты не обойдутся... :о) Вспомните хотя бы позапрошлогодний инцидент с Ф-22, вылетевшими из Гаваев в Японию... А ведь там бортовое ПО писАли настоящие зубры вроде... :о))))

Простота простоте – рознь!

Простота средства реализации тоже разной бывает!
Истинная простота может только из обобщённости идти. Никогда не поверю в простоту набора кусочных подходов и решений. Обобщённость лишена «конфликтов на стыках», как в кусочно-базированных средствах реализации. По-моему, именно это в англоязычной литературе называют словом seamllessness...
Кусочные решения создают иллюзии легкости (той или иной глубины заблуждения)... А потом проходит время, противоречия накапливаются и всем ясно, что пришли опять не туда и надо что-то делать... Но делают опять «куски», потому, что таков подход: проблема тоже не обобщается! Ситуативный подход выглядит как подход с набором правильных шагов... Но кто сказал, что цепочка из правильных шагов ведёт в нужном направлении? Завяжите человеку глаза (или даже – напустите туман на ровную, как стол, степь :о) ) и через несколько десятков шагов человек начнёт заворачивать... Чем меньше «горизонт видения» (обобщения), тем меньше гарантий, что последовательность из, по отдельности правильных действий, ведёт в правильном направлении...

Цитата:
На самом деле, когда я выше говорил, что "хочется метапринципов", я, конечно, не имел в виду "методики". "Принципов" - в смысле, каких-то контуров, подстраховывающих от ошибок и подсказывающих, в каком направлении копать...


Хм... Хотя и существует высказывание, что программист, освоивший ООП/ООД, подобен ребёнку с молотком – везде начинает видеть только гвозди, но я думаю, что парадигма привнесла массу полезных инструментов и подходов в упорядочивание представлений о мире...

Когда-то я попросил одного своего знакомого, закончившего универовский иняз с отличием, разъяснить мне один вопрос из английской грамматики. Человек впал в ступор. Английский стал его вторым языком, можно сказать – родным. Конечно, когда-то он его «изучал», но, по прошествии некоторого времени обучения, активного применения знаний и накопления опыта, сами формализованные правила забылись. Человек уже не осознаёт их, а просто «применяет»...
Конечно, и в нашем случае можно произнести нечто вроде «во всякой, вновь анализируемой предметной области стремитесь прежде всего найти объекты с такими признаками:............... . Потом, с такими: .......... . Потом сформируйте объекты, отвечающие за связи между уже найденными с такими: .............. .»

Много ли это даст?

То, что сформировало моё понимание и подходы сложилось из чтения литературы и выполнения работ по самым разным направлениям. Тут и просто классики вроде Буча и Гаммы, и Дэйтовское введение в системы баз дынных, и книги по STL, и разработка встроенного ПО на QNX, и изучение работ виртовского коллектива...
Ну что будут, вообще говоря, «для народа» значить слова «находите элементы и связи между ними»? Банальность? Конечно!
Это я знаю, по опыту, «куды бечь» в новом проекте, а кому-то, работающему рядом, я могу только сказать «Делай как я, спрашивай, почему я так делаю и читай книжки, которые я тебе дал!» :о)

Всё конечно зависит от задач.
Кому-то, кто вполне успешно «на потоке» «клепает» веб-приложения, это может показаться лишними рассусоливаниями, кто-то прекрасно обходится знанием boost+STL, кто-то законченно умилился книгами Александреску, кто-то видит «конец истории» в появлении Си-шарпа и дотНЕТа... Наверное это или им повезло, или мне – не очень... :о) Мне до сих пор как-то не попадались задачи с чётко очерченными границами в рамках одного подхода или полностью 1-в-1 ложащиеся на фреймвок или на ту или иную библиотеку...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 21:13 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
Владимир Лось писал(а):
Наверное это или им повезло, или мне – не очень...
Скорее уж не невезение, а беда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Суббота, 19 Январь, 2008 21:16 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1332
GUEST писал(а):
Владимир Лось писал(а):
Наверное это или им повезло, или мне – не очень...
Скорее уж не невезение, а беда.

В том смысле, что "меньше знаешь - крепче спишь"? :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Воскресенье, 20 Январь, 2008 09:26 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
Владимир Лось писал(а):
GUEST писал(а):
Владимир Лось писал(а):
Наверное это или им повезло, или мне – не очень...
Скорее уж не невезение, а беда.

В том смысле, что "меньше знаешь - крепче спишь"? :о)
Отнюдь.То о чем здесь высказывалось сожаление есть палка о двух концах. С одной стороны неудовлетворительность скелета framework-ов для Ваших задач косвенно свидетельствует о недостаточности теоретической базы его решений, а с другой
желание строить теоретические умозаключения при решении каждой задачи можно классифицировать как преувеличение её роли. Беда в общем.
P.S. Извините, если что не так сказал. Ничего дурного в виду не имел.


Последний раз редактировалось Сергей Оборотов Понедельник, 21 Январь, 2008 18:19, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Воскресенье, 20 Январь, 2008 23:25 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1332
GUEST писал(а):
P.S. Извините, если что не так сказал. Ничего дурного в виду не имел.

Да ничего-ничего! Мне вот и самому интересно!
Ведь "абыдно"-то - что? - построить и "одухотворить" систему на стадии анализа предметки и проектирования, со временем (в смысле возраста и опыта), проблем - всё меньше... Главная проблема - начинать преодолевать семантический разрыв с имеющимся средством реализации (фреймвоки и библиотеки).
... Я ведь почему собсна и "скатился" ко встроенным системам и системам РВ? - да там я - сам себе хозяин! Средства реализации настолько низкорувневы, что собственные "миры" (после первых итераций анализа и проектирования) - имеют меньшее число промежуточных слоёв (фреймвлки и библиотеки) - мне не надо заниматься дополнительным "сшиванием смыслов"...
В этом смысле мне QNX ну оченна сильно понравилась - эдакая "золотая середина": с одной стороны, достаточно высокоуровневый (но не избыточный) набор юникс-совместимых вещей, а, с другой, - приходилось меньше всего заниматься упомянутой "сшивкой" уровней. Вернее, лучше так: уровни-то я сшивал, но, в большинстве случаев это были МОИ (запрограммированные мной) уровни и, для реализации этих уровней, мне не приходилось проделывать слишком много работы по причине "монструозности" или неадекватности средств их реализации...

GUEST писал(а):
С одной стороны неудовлетворительность framework-ов для Ваших задач косвенно свидетельствует о недостаточности теоретической базы его решений

Что значит ЕГО? Может быть, имелось в виду слово "их"?

GUEST писал(а):
, а с другой желание строить теоретические умозаключения при решении каждой задачи можно классифицировать как переоценивание её роли.

Так это - кто какие задачи решает... У меня это - ДАЛЕКО не "накидывание контролов на форму"...
Например, подсистему ввода/вывода в автономной встроенной системе как "переоценишь"?... которая как ставится в "ящик", так и должна в нём работать годы и десятилетия. И не полезешь дампы смотреть и отладчик запускать... Бо - высоко и далеко больно... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Понедельник, 21 Январь, 2008 18:50 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
Владимир Лось писал(а):
...мне не надо заниматься дополнительным "сшиванием смыслов"...
В этом смысле мне QNX ну оченна сильно понравилась - эдакая "золотая середина": с одной стороны, достаточно высокоуровневый (но не избыточный) набор юникс-совместимых вещей, а, с другой, - приходилось меньше всего заниматься упомянутой "сшивкой" уровней. Вернее, лучше так: уровни-то я сшивал, но, в большинстве случаев это были МОИ (запрограммированные мной) уровни и, для реализации этих уровней, мне не приходилось проделывать слишком много работы по причине "монструозности" или неадекватности средств их реализации...
Собственно, эти оценки более количественные. Как связано количество уровней со сложностью к примеру конструкций в природе сказать сложно, но в монструозности её упрекнуть нельзя.
Владимир Лось писал(а):
Например, подсистему ввода/вывода в автономной встроенной системе как "переоценишь"?... которая как ставится в "ящик", так и должна в нём работать годы и десятилетия. И не полезешь дампы смотреть и отладчик запускать... Бо - высоко и далеко больно... :о)
Одно не совсем ясно. То ли далеко от нас, потому что задача другая, то ли задача другая, потому что далеко.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Вторник, 22 Январь, 2008 00:26 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1332
GUEST писал(а):
Собственно, эти оценки более количественные. Как связано количество уровней со сложностью к примеру конструкций в природе сказать сложно, но в монструозности её упрекнуть нельзя.
...
Одно не совсем ясно. То ли далеко от нас, потому что задача другая, то ли задача другая, потому что далеко.

Так что по теме сказать-то хотели?...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Вторник, 22 Январь, 2008 21:34 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
Владимир Лось писал(а):
Так что по теме сказать-то хотели?...
Того, что уже сказано, недостаточно? В таком случае, интересно о чем ещё не сказали?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Принципы структурирования
СообщениеДобавлено: Пятница, 25 Январь, 2008 21:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Замечательная для обучения программированию книга Н.Вирта "Систематическое программирование".
http://europrog.ru/book/spnw1977r.pdf
К вопросу структурирования, декомпозиции и нисходящего подхода - глава 15.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 37 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB