Автор Тема: Размышления на тему логики предметной области (бизнес-  (Прочитано 20448 раз)

DIzer

  • Гость

Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов.  :)
  :) :) :)  Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН  ;) :D

alexus

  • Гость
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов.
Модели должны быть одни и те же и у руководства, и у программистов. Различие в моделях - это область непонимания друг друга.

Цитата: Romiras
Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта.
Модель Вам никто не принесёт "на блюдечке с голубой каёмочкой"... модель надо построить самому.

Цитата: Romiras
Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Да, не так важно, понимает руководство или нет, важно, чтобы понимали Вы и Ваши коллеги. Понимая предметную область можно работать на опережение понимания руководства, на облегчение собственной работы.

Цитата: Romiras
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).
Так об этом и речь. Ну, в качестве примера... Создание ERP систем занимает 3000-8000 чел. лет. А можно тоже самое (с запасом) сделать за 10-20 чел. лет. Вот и соотнесите затраты труда программистов, количество согласований, переделок... и прочих нервных окончаний...
Но, поймите правильно, я Вас ни к чему не призываю... хотите идти "широкой дорогой" проб и ошибок... идите.

DIzer

  • Гость
И дело сдесь не в простоте а в наличие степени развития достаточной для восприятия курса, без нее получается в лучшем случае банально заучивание материала (слова понятны - смысл нет)

alexus

  • Гость

Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов.  :)
  :) :) :)  Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН  ;) :D
Пусть будет так. Не навязываю...

DIzer

  • Гость

Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов.  :)
  :) :) :)  Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН  ;) :D
Пусть будет так. Не навязываю...
Аминь

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.
Гм. А можно пример той самой мифической семантической модели предметной области?

PS. Никогда не понимал разделения на динамический и статический контент.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.
Гм. А можно пример той самой мифической семантической модели предметной области?

PS. Никогда не понимал разделения на динамический и статический контент.
Вопрос по примерам семантической модели - не ко мне. Для меня они являются сферическими конями на сей момент. Я просто "подхватил" идею.

Статический контент - это простой, безусловный HTML. Он не подвержен влиянию никаких внешних параметров при запросе серверу и времени.

by valexey: дальнейшее обсуждение статического и динамического контента перенесено сюда по просьбе автора: http://oberspace.dyndns.org/index.php/topic,209.msg4314.html
« Последнее редактирование: Март 23, 2012, 08:25:59 pm от valexey »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?

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

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?

Получилась бы нормальная клиент-серверная система.
И вся бизнес-логика будет сидеть на клиенте? А ещё добавить сюда постоянную борьбу с совместимостью браузеров...
Это ведь однозначно тихий ужас будет: как в отношении разработки, так и в отношении поддержки.
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.

Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?

Получилась бы нормальная клиент-серверная система.
И вся бизнес-логика будет сидеть на клиенте? А ещё добавить сюда постоянную борьбу с совместимостью браузеров...
Это ведь однозначно тихий ужас будет: как в отношении разработки, так и в отношении поддержки.
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.

Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
В таком случае, нужно придумывать свой веб-каркас. Только для этого нужно сначала проработать идею. С наскоку такие вещи не делаются.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.

Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
В таком случае, нужно придумывать свой веб-каркас. Только для этого нужно сначала проработать идею. С наскоку такие вещи не делаются.
Да. И лучше вначале посмотреть как это сделано у других. Я не верю что нет ни одного веб-фреймворка который бы этот самый ajax не использовал бы таким способом по полной программе.

Тут собственно есть ровно одна проблема - это поисковики. Они хотят только статику (клиентскую статику, на сервер им плевать конечно же). Но на эту тему у гугла есть решение: http://habrahabr.ru/company/roundlake/blog/140291/
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Да господа это оффспин - на со