OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 12:12

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




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 09:11 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
В чём было отличие системы для расчётов от программы расчёта заработной платы?..
1. Расчётные схемы создаются, тестируются и отлаживаются специалистами без привлечения программистов;
2. Система расчётов не привязывается к каким-либо конкретным расчётам, она должна позволить вводить любые расчётные схемы, будь то расчёт заработной платы или начисление дивидендов, или расчёт прибыли/издержек/взаиморасчётов, или любые другие;
3. Система расчётов должна поддерживать версии расчётных схем, помнить авторов схем, время создания, принятия и отмены, и пр. атрибуты;
4. Каждый результат расчёта, сохранённый в БД, должен ссылаться на свою расчётную схему, дату и время проведения расчёта, сотрудника, выполнявшего расчёт (исходные данные не имели связи с результатом и не имели версий, что могло привести (и приводило) к расхождению при повторном проведении расчётов по одной и той же расчётной схеме).
5. Взаимодействие с системой расчётов должно было быть максимально простым и понятным; для каждой расчётной схемы возможно выполнение и контроль тестовых прогонов, формирование полной распечатки исходных (тестовых) данных, исходных формул, формул с замещением формальных параметров фактическими, результатов расчёта).

Самой простой метафорой проекта являлась электронная таблица (а-ля Quadro Pro, Excel и т.п.), с той разницей, что источник данных, как и хранитель результатов были определены - БД предприятия. Сама работа с системой, должна была быть упрощена за счёт минимизации ручного ввода, автоматической проверки (верификации) формул и используемых в них исходных данных.
Собственно, так была создана система расчётов. Пользователям предоставлялись структурированные данные (левая часть рабочего поля), далее вводились формулы, оперирующие исходными данными (центральная часть рабочего поля), и формировались временные и расчётные данные (правая часть рабочего поля). Введённые формулы в первых версиях интерпретировались, в последующих версиях компилировались в машинный код (i386).
Расчёт выполнялся программой более суток (использовалась СУБД Paradox), при переходе к системе в режиме интерпретации около 4-х часов, откомпилированный код работал менее 15 мин. (в системе расчётов использовалась СУБД Interbase).
Однако ускорение расчётов... хоть и мелочь, но приятно... основная же заслуга системы в том, что она всё расставила по местам. Те, кто планировал расчёты, сами их создавали и отлаживали, они не бегали за программистами, но и несли всю полноту ответственности. Программисты спокойно и без надрыва/спешки/склок планово(!) совершенствовали инструмент пользователей (систему). Наконец, руководство могло получить результаты предварительных(!) расчётов и оценить их в контексте текущей ситуации и выбрать наиболее подходящий вариант.

Вот, собственно, и вся история... и никакого рефакторинга...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 09:21 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Иван Кузьмицкий писал(а):
Я понимаю осуждение рефакторинга как средства, стоящего наравне с проектированием и моделированием.
Совершенно верно!.. Мало того, рефакторинг, в некотором смысле, стоит над моделированием и проектированием, поскольку порождает пакостные мысли, вроде того: "А, и так сойдёт... если что... выполним рефакторинг". Деминг как-то писал, что если нет времени сразу сделать хорошо, то потом обязательно найдётся гораздо больше времени на то, чтобы исправить... (пишу по памяти).
Иван Кузьмицкий писал(а):
Вот, мы позавчера начали перекраивать стартовые механизмы системы. Да, недопроектирование. Да, недодуманность. Да, были причины сделать так, а не лучше. Но всё же - время, потраченное на рабочие исходники можно рассматривать как инвестиции, а перекройку как упущенное время. Поэтому рефакторинг надо рассматривать как крайнее средство (когда наука и медицина бессильны), а не рутину, или там, пункт меню вижуал студии.
+5 Очень точно!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 09:55 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
alexus писал(а):
... Программисты спокойно и без надрыва/спешки/склок планово(!) совершенствовали инструмент пользователей (систему). ... и никакого рефакторинга...
:)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 09:58 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Валерий Лаптев писал(а):
alexus писал(а):
igor писал(а):
Рефакторинг нужен тогда, когда вместо системы создают большую программу и... сильно гордятся этим.Другими словами, рефакторинг является следствием ошибок моделирования и проектирования... ширмой, за которой прячут эти ошибки. И поэтому должен подвергаться осуждению.

C этим не соглашусь.
Я этого не писал. Прошу быть повнимательнее. Спасибо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 10:05 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
alexus писал(а):
Иван Кузьмицкий писал(а):
Вот, мы позавчера начали перекраивать стартовые механизмы системы. Да, недопроектирование. Да, недодуманность. Да, были причины сделать так, а не лучше. Но всё же - время, потраченное на рабочие исходники можно рассматривать как инвестиции, а перекройку как упущенное время. Поэтому рефакторинг надо рассматривать как крайнее средство (когда наука и медицина бессильны), а не рутину, или там, пункт меню вижуал студии.
+5 Очень точно!
-1
2 Иван Слова красивые, но совершенно оторванные от жизни, и подтверждение тому - Ваш пример.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 10:14 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
igor писал(а):
alexus писал(а):
Иван Кузьмицкий писал(а):
Вот, мы позавчера начали перекраивать стартовые механизмы системы. Да, недопроектирование. Да, недодуманность. Да, были причины сделать так, а не лучше. Но всё же - время, потраченное на рабочие исходники можно рассматривать как инвестиции, а перекройку как упущенное время. Поэтому рефакторинг надо рассматривать как крайнее средство (когда наука и медицина бессильны), а не рутину, или там, пункт меню вижуал студии.
+5 Очень точно!
-1
2 Иван Слова красивые, но совершенно оторванные от жизни, и подтверждение тому - Ваш пример.
Мой пример... взят из жизни, и он в русле того, что написал Иван. Ну, не нравится Вам, это я понимаю, но спорить с очевидным... не доблесть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 10:34 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
albobin писал(а):
alexus писал(а):
... Программисты спокойно и без надрыва/спешки/склок планово(!) совершенствовали инструмент пользователей (систему). ... и никакого рефакторинга...
:)
Вотыменно :)

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

Шаг назад -- два шага вперёд.
Вот без этих "шагов назад" обойтись невозможно. Они суть instances of рефакторинга.

У алексуса произошел тот же рефакторинг, только глобальный.
А потом пошли локальные -- как тонко подчеркнул albobin.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 12:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
...
Самой простой метафорой проекта являлась электронная таблица (а-ля Quadro Pro, Excel и т.п.), с той разницей, что источник данных, как и хранитель результатов были определены - БД предприятия. Сама работа с системой, должна была быть упрощена за счёт минимизации ручного ввода, автоматической проверки (верификации) формул и используемых в них исходных данных.
Собственно, так была создана система расчётов. Пользователям предоставлялись структурированные данные (левая часть рабочего поля), далее вводились формулы, оперирующие исходными данными (центральная часть рабочего поля), и формировались временные и расчётные данные (правая часть рабочего поля).
...
Вот, собственно, и вся история... и никакого рефакторинга...
Верно я понимаю, что:
    * метаметафорой замены рефакторинга является: "каждой предметке - правильную её схему";
    * задача программистов - создавать средство работы со схемами предметок
?
Под "правильной" понимается схема, которую предметник может преобразовывать наиболее естественно - следовательно, можно переложить на него эту работу. Тогда язык схемы - результат информатизации языка предметки - т.е. DSL. Он включает лексику, передающую "вещи предметки и отношения между вещами - и м.б. отношения между отношениями" и правила употребления лексики для составления схем.
    Понятно, что "схема" - термин условный по отношению к форме записи. Это м.б. графы, изображения, тексты, таблицы в различных сочетаниях (но алгоритмически формируемых).
А развитие системы (разработчиками-программистами) в основном есть выявление сущностей/отношений предметки, операций над ними и закладка этого в программу - редактор/транслятор схем. Наряду с этим - конечно, отработка операций программы (над схемами и вспомогательных) и оптимальное их включение в операторский интерфейс.
Короче, всё, что перечислено Вами в этом посте как шаги 1...6, делается только по вышеперечисленным поводам - а не по поводу конкретных задач предметников. Отсюда сосредотачиваемся на модели (информатической, а значит до этого/вместе с этим - математической и качественной) предметки в целом. Т.е. на "возможных/допустимых вещах и отношениях" - а не на "существующих/мыслимых задачах" - что есть дело аналитика, работающего в т.ч. и с данными эксплуатации среды. И тогда проще аналитику и программисту. Так?

В Вашем примере за правильную схему была принята метафора динамической (распространяющей <вычисления согласно зависимостям формул>, жарг. "электронной") таблицы. Каковая на самом деле играла роль предметно-естественной формы определения параметров запросов к СУБД - как для манипулирования данными, так и для их расчётно-логических преобразований. Верно?
А перейди мы к другой "предметке" - и понадобится новая метафора, новый язык - что оформляется как "домайно-специфичный плагин" над ядром (в данном случае - приложением СУБД)... isn't it?..

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


Последний раз редактировалось Владислав Жаринов Четверг, 22 Сентябрь, 2011 13:33, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 13:19 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
igor писал(а):
-1
2 Иван Слова красивые, но совершенно оторванные от жизни, и подтверждение тому - Ваш пример.
Что же именно "оторвано от жизни"? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 14:05 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван Кузьмицкий писал(а):
igor писал(а):
Слова красивые, но совершенно оторванные от жизни, и подтверждение тому - Ваш пример.
Что же именно "оторвано от жизни"? :)
Как Вам объяснить! Мне по духу ближе в этом вопросе позиция Никлауса Вирта и сотоварищи, которые отвергли теорию безошибочного кодирования. Ошибки были, есть и будут всегда (в том числе в проектировании связей внутри системы). Наивно было бы надеятся, что можно обойтись без рефакторинга.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 14:20 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
igor писал(а):
Иван Кузьмицкий писал(а):
igor писал(а):
Слова красивые, но совершенно оторванные от жизни, и подтверждение тому - Ваш пример.
Что же именно "оторвано от жизни"? :)
Как Вам объяснить! Мне по духу ближе в этом вопросе позиция Никлауса Вирта и сотоварищи, которые отвергли теорию безошибочного кодирования. Ошибки были, есть и будут всегда (в том числе в проектировании связей внутри системы). Наивно было бы надеятся, что можно обойтись без рефакторинга.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 16:30 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван Кузьмицкий писал(а):
igor писал(а):
Мне по духу ближе в этом вопросе позиция Никлауса Вирта и сотоварищи, которые отвергли теорию безошибочного кодирования. Ошибки были, есть и будут всегда (в том числе в проектировании связей внутри системы). Наивно было бы надеятся, что можно обойтись без рефакторинга.
О, ну так это же бесспорно. Вопрос-то несколько в другом.
Думаю, что мы поняли друг друга :)

Честно признаюсь, что статью, ссылку на которую Вы дали, я не осилил. Начал читать, и бросил. Товарищ чего-то не понимает. Взять хотя бы его лозунг: "Рефакторинг должен стать перманентным состоянием вашего проекта". Рефакторинг ради рефакторинга? Чушь! Любую идею можно взять и довести до абсурда. Напомню, что первоначально я выступил против категоричности суждения alexus'а. Я бы выдвинул другой лозунг: "Рефакторинг бывает полезен. И не более того!" :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 16:52 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
alexus писал(а):
Ну, не нравится Вам, это я понимаю, но спорить с очевидным... не доблесть.
Точно такую же риторику я мог бы применить по отношению к Вам (но не стану этого делать). Весь вопрос в том, что является очевидным. Для Вас очевидно одно, а для меня - другое.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 16:53 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Вот, собственно, и вся история... и никакого рефакторинга...
Верно я понимаю, что:
    * метаметафорой замены рефакторинга является: "каждой предметке - правильную её схему";
    * задача программистов - создавать средство работы со схемами предметок
?
Вопросы... "не в бровь, а в глаз"... :) Задача программистов состоит в программировании. Формирование моделей задача аналитиков, а проектировщики должны... конечно... проектировать. У каждой предметной области, несомненно, должна быть "правильная схема". (Вопрос в том, какую схему считать правильной?) Программисты должны стараться создавать качественные инструменты в тех случаях, когда речь идёт о том, что предметную область невозможно или не нужно/бесполезно (как в приведённом случае) формализовать.
Драконограф писал(а):
Под "правильной" понимается схема, которую предметник может преобразовывать наиболее естественно - следовательно, можно переложить на него эту работу. Тогда язык схемы - результат информатизации языка предметки - т.е. DSL. Он включает лексику, передающую "вещи предметки и отношения между вещами - и м.б. отношения между отношениями" и правила употребления лексики для составления схем.
В примере просто устранялось "лишнее звено" - программисты, при решении конкретной задачи. Программисты занимались развитием инструмента.
Что понимается под "правильной схемой"?.. Схема/модель должна быть, как и любая другая модель, адекватной предметной области. ... Нет, решил удалить дальнейшие комментарии... если у форумчан не сложилось понимание того, чем отличается "рефакторинг" от "развития", то говорить о более "тонких материях" смысла не имеет. Может быть потом...
Драконограф писал(а):
    Понятно, что "схема" - термин условный по отношению к форме записи. Это м.б. графы, изображения, тексты, таблицы в различных сочетаниях (но алгоритмически формируемых).
Да, конечно. Изображение (проекция модели) должно быть понятным, а, следовательно, "изображать" надо понятными/принятыми в данной предметной области средствами/языками/образами.
Драконограф писал(а):
А развитие системы (разработчиками-программистами) в основном есть выявление сущностей/отношений предметки, операций над ними и закладка этого в программу - редактор/транслятор схем. Наряду с этим - конечно, отработка операций программы (над схемами и вспомогательных) и оптимальное их включение в операторский интерфейс.
Нет, это уже следствия. Развитие должно опираться на "правильную схему/модель"... иначе неизбежно вернёмся к рефакторингу (переделки то в одном месте, то в другом). Так вот... "выявление сущностей/отношений предметки, операций над ними" - это относится к получению "правильной модели", но не её развитию.
Драконограф писал(а):
Короче, всё, что перечислено Вами в этом посте как шаги 1...6, делается только по вышеперечисленным поводам - а не по поводу конкретных задач предметников. Отсюда сосредотачиваемся на модели (информатической, а значит до этого/вместе с этим - математической и качественной) предметки в целом. Т.е. на "возможных/допустимых вещах и отношениях" - а не на "существующих/мыслимых задачах" - что есть дело аналитика, работающего в т.ч. и с данными эксплуатации среды. И тогда проще аналитику и программисту. Так?
Нет. Общее движение (аналитика, проектировщика, программиста) должно происходить от семантики в сторону насыщения/многообразия форм, а не от ошибок и недочётов (в модели/проектной документации/коде) к их исправлению. Исходная мысль здесь: "смысл всегда прост, трудно даётся его обретение". Ладно... я, кажется, опять увлёкся "тонкими материями"... Напрасно...
Драконограф писал(а):
В Вашем примере за правильную схему была принята метафора динамической (распространяющей <вычисления согласно зависимостям формул>, жарг. "электронной") таблицы.
Нет, основа в данной задаче ФОРМУЛА. Всё остальное "крутится" вокруг этого "центрального" понятия.
Драконограф писал(а):
Каковая на самом деле играла роль предметно-естественной формы определения параметров запросов к СУБД - как для манипулирования данными, так и для их расчётно-логических преобразований. Верно?
См. выше. (в конечном итоге данные брались не только из БД, но и других источников, от пользователей, например, в интерактивном режиме, из реальных электронных таблиц и пр.).
Драконограф писал(а):
А перейди мы к другой "предметке" - и понадобится новая метафора, новый язык - что оформляется как "домайно-специфичный плагин" над ядром (в данном случае - приложением СУБД)... isn't it?..
Разумеется.
Драконограф писал(а):
И ещё - логика подсказывает, что должна существовать "самая правильная схема" - т.е. инвариант всех мыслимых предметок.
Это неформально... можно понимать двояко... Например так, есть некоторая супер-модель ("правильная схема"), которая включает в себя все модели ("схемы"). Эта "супер-модель" является собирательным образом и постоянно дополняется новыми моделями (схемами). А можно так, супер-модель, проецируется на разные области, и поэтому она не является собирательным образом, а является про-образом тех образов-моделей, которые являются её проекциями на предметные области. Это два принципиально разных... взгляда/подхода... Первый путь объясняет рефакторинг, второй его вредность. И то, и другое... "тонкие материи"... Тьфу на них...
Драконограф писал(а):
На её базе выстраивается "домайная специфика" для каждой очередной предметки, добавляемой в список поддерживаемых в конкретной оргсистеме-эксплуатанте такого решения. Ещё и потому, что предметки м.б. не независимы - и тогда надо добавлять как "гибрид ужа с ежом" (а также лебедем, раком, щукой etc... только это не ирония над Вашим подходом, а художественно-наглядное обозначение проблем масштабирования решения - возможно, Вы уже знакомы с ними). При этом каждый раз имея инвариант как отправную точку - чтобы действительно всё не переделывать.
См. выше.
Драконограф писал(а):
Интуитивно из Ваших предыдущих рассуждений я понял, что схема-инвариант Вами представляется как модель трактов переработки оргсистемы (её выделенной части). Что и отразил в этом посте. Что-то можете сказать по этому поводу?
Я читал... честно... но ничего не понял... (второй раз промолчу).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 16:55 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
igor писал(а):
Я этого не писал. Прошу быть повнимательнее. Спасибо!

Извините, наверное не тот тег удалил при цитировании.
Тем не менее, мысль моя остается в силе: рефакторинг - это механизм внесения изменений при развитии системы-программы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 16:56 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
igor писал(а):
alexus писал(а):
Ну, не нравится Вам, это я понимаю, но спорить с очевидным... не доблесть.
Точно такую же риторику я мог бы применить по отношению к Вам (но не стану этого делать). Весь вопрос в том, что является очевидным. Для Вас очевидно одно, а для меня - другое.
Очевидно то, что можно очами увидеть, то есть, реально существующее.

PS. Всё прекращаю... разговор потерял смысл и стал полным офтопиком...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 17:25 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
alexus писал(а):
Очевидно то, что можно очами увидеть, то есть, реально существующее.
Очевидно (!) то, что мы с Вами опять смотрим на предмет спора разными глазами, простите... очами. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 18:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
...
Программисты должны стараться создавать качественные инструменты в тех случаях, когда речь идёт о том, что предметную область невозможно или не нужно/бесполезно (как в приведённом случае) формализовать.
Читай - когда, скажем, требуется просто отработать задачу от начала до конца по дной и той же схеме? М.б. неоднократно - но с рестартом каждый раз с определённого места (возможно, одного из нескольких)?
alexus писал(а):
...
Драконограф писал(а):
А развитие системы (разработчиками-программистами) в основном есть выявление сущностей/отношений предметки, операций над ними и закладка этого в программу - редактор/транслятор схем. Наряду с этим - конечно, отработка операций программы (над схемами и вспомогательных) и оптимальное их включение в операторский интерфейс.
Нет, это уже следствия. Развитие должно опираться на "правильную схему/модель"... иначе неизбежно вернёмся к рефакторингу (переделки то в одном месте, то в другом). Так вот... "выявление сущностей/отношений предметки, операций над ними" - это относится к получению "правильной модели", но не её развитию.
Драконограф писал(а):
Короче, всё, что перечислено Вами в этом посте как шаги 1...6, делается только по вышеперечисленным поводам - а не по поводу конкретных задач предметников.
...
Так?
Нет. Общее движение (аналитика, проектировщика, программиста) должно происходить от семантики в сторону насыщения/многообразия форм, а не от ошибок и недочётов (в модели/проектной документации/коде) к их исправлению. Исходная мысль здесь: "смысл всегда прост, трудно даётся его обретение". Ладно... я, кажется, опять увлёкся "тонкими материями"... Напрасно...
М.б. и нет... ну потом так потом. :)
Т.е. суммируя - один раз, уяснив смысл предметки, формируем её ДСЛ (язык моделей, которые считаем правильными)?
Вообще я имел в виду под изменением ДСЛ (кроме указанных Вами введений его изоморфных представлений) не столько его исправление, сколько расширение... подобно тому, как интегро/диффисчисления расширяют арифметику... ну и т.д. Вряд ли это всегда сразу видимо... или нет?..
alexus писал(а):
...
Драконограф писал(а):
В Вашем примере за правильную схему была принята метафора динамической (распространяющей <вычисления согласно зависимостям формул>, жарг. "электронной") таблицы.
Нет, основа в данной задаче ФОРМУЛА. Всё остальное "крутится" вокруг этого "центрального" понятия.
Ну да.. по правде-то я себе мысленно и представил формулу в ячейке динатаба... от/к зависимостных операндов которой идут связи к другим формулам... но при формулировке упростил, полагая это самоочевидным... :) Ну это так...
alexus писал(а):
...
Драконограф писал(а):
Каковая на самом деле играла роль предметно-естественной формы определения параметров запросов к СУБД - как для манипулирования данными, так и для их расчётно-логических преобразований. Верно?
См. выше. (в конечном итоге данные брались не только из БД, но и других источников, от пользователей, например, в интерактивном режиме, из реальных электронных таблиц и пр.).
ну да... ДСЛ-надстройка "умеет" брать из каждого источника данные, а юзеру надо только скомандовать "отсюда". :) И одна из основных составляющих развития - "учить" её выполнять эти команды применительно к вновь желаемым типам источников?..
alexus писал(а):
...
Драконограф писал(а):
И ещё - логика подсказывает, что должна существовать "самая правильная схема" - т.е. инвариант всех мыслимых предметок.
Это неформально... можно понимать двояко... Например так, есть некоторая супер-модель ("правильная схема"), которая включает в себя все модели ("схемы"). Эта "супер-модель" является собирательным образом и постоянно дополняется новыми моделями (схемами). А можно так, супер-модель, проецируется на разные области, и поэтому она не является собирательным образом, а является про-образом тех образов-моделей, которые являются её проекциями на предметные области. Это два принципиально разных... взгляда/подхода... Первый путь объясняет рефакторинг, второй его вредность. И то, и другое... "тонкие материи"... Тьфу на них...
Драконограф писал(а):
На её базе выстраивается "домайная специфика" для каждой очередной предметки, добавляемой в список поддерживаемых в конкретной оргсистеме-эксплуатанте такого решения. Ещё и потому, что предметки м.б. не независимы - и тогда надо добавлять как "гибрид ужа с ежом" (а также лебедем, раком, щукой etc... только это не ирония над Вашим подходом, а художественно-наглядное обозначение проблем масштабирования решения - возможно, Вы уже знакомы с ними). При этом каждый раз имея инвариант как отправную точку - чтобы действительно всё не переделывать.
См. выше.
Ну, мне тоже кажется правильным проекция... в этом смысле и говорил. И она в Вашем понимании возможна так - просто даём уже определённым в инварианте вещам/отношениям названия, принятые в предметке? Т.е. можно определить некий базис типов отношений и сущностей?
alexus писал(а):
...
Драконограф писал(а):
Интуитивно из Ваших предыдущих рассуждений я понял, что схема-инвариант Вами представляется как модель трактов переработки оргсистемы (её выделенной части). Что и отразил в этом посте. Что-то можете сказать по этому поводу?
Я читал... честно... но ничего не понял... (второй раз промолчу).
Ну, там ещё и ссылка была неверная одна... исправил. Имелась в виду модель трактов типа описанной в этом подпункте. Правда, дело, возможно, и не в этом... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон и проектирование систем
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 20:58 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
alexus писал(а):
Общее движение (аналитика, проектировщика, программиста) должно происходить от семантики в сторону насыщения/многообразия форм, а не от ошибок и недочётов (в модели/проектной документации/коде) к их исправлению...
Например так, есть некоторая супер-модель ("правильная схема"), которая включает в себя все модели ("схемы"). Эта "супер-модель" является собирательным образом и постоянно дополняется новыми моделями (схемами). А можно так, супер-модель, проецируется на разные области, и поэтому она не является собирательным образом, а является про-образом тех образов-моделей, которые являются её проекциями на предметные области. Это два принципиально разных... взгляда/подхода...
Первая мысль: блин, всё же так просто и очевидно!
И всегда сам знал, только словами выразить не мог :wink:

Вторая мысль: а примеров второго-то я и не видел в жизни... за исключением пары относительно мелких частных задач... Почему? А, может, это всё правильно, но принципиально недостижимо, как абсолютный идеал?

Если ты не знаешь ни одной предметной области - то откуда возьмётся прообраз? Следовательно, нужна подготовка, изучение, опыт построения моделей, рефакторинг тот же... пока не кристаллизуется вот эта самая суть!

С другой стороны, чем больше опыт, тем глубже тонет под ним суть, становится неуловимой, теряясь за частностями и деталями... Дык, где же золотая середина?!
Подозреваю, кстати, что она вообще в другой плоскости... но это опять "тонкие материи" :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Сентябрь, 2011 22:07 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Иван Кузьмицкий писал(а):
Заранее можно обдумать структуру программы, если отчетливо понимаешь, в чем задача.

Чем новее и сложнее задача, тем труднее ее понять.
Вот игра с реальными прототипами как раз и позволяет понять, в чем там дело.

Пример: физик-экспериментатор не может объяснить, что ему нужно. Потому что слишком много вариантов и ситуаций.
Проще подсунуть хоть что-то и смотреть.

В сущности, то, что рассказал алексус, проходит в точности по этой же схеме.


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

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


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

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


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

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