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

Любая предметная область обладает сложностью, большей нуля, т.е. сложность любой предметной области составляет, как минимум, 1 бит. Любая часть предметной области может рассматриваться как самостоятельная предметная область. Разные предметные области обладают разной сложностью.

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

Простейшая модель (решение), по определению, должна содержать минимум информации. Но быть проще предметной области (т.е. содержать меньше информации, чем предметная область) модель, в общем случае, не может. Следовательно,

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

Такое требование ограничивает модель сложностью, не превосходящей сложности предметной области. Из этого также следует, что, в общем случае, для сложной предметной области невозможно построить простую модель, т.к. количество информации в модели ограничено снизу количеством информации в предметной области.

Одним из методов поддержания модели в простейшем состоянии является использование только словаря предметной области. Т.е. вся терминология, используемая в модели, берется без изменений из предметной области. Это позволяет избежать внесения в модель сущностей, которых нет в предметной области. Никакой термин не изменяется, и как следствие, новой информации не добавляется. Любая попытка изменить терминологию приведет к появлению синонимов, что является дополнительной информацией, и усложнением модели. Терминологию предметной области нужно рассматривать с позиции обоснованной сложности: если некоторый термин предметной области кажется создателю модели слишком длинным (коротким), то существуют причины в предметной области, по которым термин является именно таким, а не как-то иначе. В противном случае, термин упростился бы уже в предметной области, ведь никто не хочет делать что-то сложнее, чем того требуется.

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

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

Исходя из вышесказанного, любая модель (решение) представима в виде:

модель = простейшая модель + оптимизация

Сложность модели будет определяться сложностью простейшего решения, плюс сложностью, вносимой оптимизацией. Как следствие, простейшая модель получиться в том случае, если в ней полностью отсутствует оптимизация.

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

Другой «проблемой» оптимизации является ее неотделимость от модели: очень часто, после оптимизирования модели, из нее уже невозможно выделить, ни простейшую модель, ни саму оптимизацию, в чистом виде. Оптимизация, что называется, «размазана» по модели, т.е. оптимизация становиться частью модели.

Существует точка зрения, что решения (модели) не накапливаются как человеческое знание. В разных проектах для одних и тех же предметных областей строятся одни и те же модели. Одной (если не единственной) из причин такой потери моделей как знания и изобретение велосипедов является невозможность отделения простейшей модели от оптимизации. Повторное использование модели, в которую «встроена» оптимизация, затрудняется двумя причинами. Первая причина: такая модель элементарно сложнее простейшей модели для понимания, и вторая причина: в каждом случае повторного использования модели критерии оптимизации могут быть отличными от тех, которые уже «встроены» в модель. Для повторного использования важна именно простейшая модель, которая построена только на знаниях из предметной области. Можно сказать, что простейшая модель отражает смысл модели, а оптимизация – окружение, в котором исполняется модель.

Остается определить, что является оптимизацией, а что – нет. Список элементов оптимизаций, видимо довольно большой, поэтому рассмотрим лишь некоторые.

1. Паттерны проектирования – это оптимизация модели по критерию гибкости внесения изменений в модель. Основным приемом паттернов проектирования является косвенность. Паттерны усложняют модель, увеличивая количество информации в ней.

2. Не все элементы языков программирования подойдут для записи простейшей модели. По-видимому, самый распространенный пример – это использование указателей для записи ассоциаций между объектами (имеется ввиду семантика обычных указателей С++; в других языках есть ссылки со схожей семантикой, например ссылки в Delphi). Указатель является оптимизацией по производительности. В предметной области объекты ссылаются друг на друга по ключу, а сами ключи заданы по значению (выражаясь языком С++). Значит и в простейшей модели объекты должны ссылаться друг на друга только по ключам. Состояние объектов в этом случае всегда стабильное, т.к. ключи заданы по значению. Если же в состоянии объекта есть указатель на другой объект, то такое состояние нестабильно: если объект, на который ссылаются, удален, то простое чтение состояния объекта, который ссылается на «труп», приведет к исключению. Это можно даже задать как критерий стабильного состояния: читать состояние объекта можно в любой момент времени. Именно такое поведение присутствует в предметной области.

3. Простейший поиск – это перебор. Применение любых других методов – это оптимизация по производительности.


По-видимому, проблему простейшей модели и оптимизации пытается решить языково-ориентированное программирование

Автор(ы): Сергей Дмитриев
Дата: 02.03.2006
Пришло время следующей технологической революции в разработке софта – и становится все очевиднее, какой она должна быть. Новая парадигма программирования – вот она, перед нами. Она еще не вполне сформировалась – разные части известны под разными именами вроде Intentional Programming, MDA, порождающее программирование и т.д. Я предлагаю объединение этих новаторских подходов под общим именем «языково-ориентированного программирования»; данная статья объясняет основные принципы новой парадигмы.

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

Здравствуйте, m_n:

Кроме простоты модели еще нужно учитывать такую вещь как "понятность". И если более сложная модель более понятная лучше выбирать ее. Не зря все естественные языки (русский, английский и т. д.) обладают приличной избыточночтью. Кроме того избыточность при описании модели помоему облегчает ее дальнейшую эволюцию, а этот параметр часто самый важный. Так что думаю что простейшая модель != лучшей.

Здравствуйте, m_n, Вы писали:

m_n>Существует точка зрения, что решения (модели) не накапливаются как человеческое знание. В разных проектах для одних и тех же предметных областей строятся одни и те же модели.

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

Здравствуйте, m_n, Вы писали:

Так и не понял, где обещанное в заголовке определение...

Область понятий обладает сложностью, которая выражается через:
1. Как вы и сказали, общее число понятий
2. Как вы забыли: связях между понятиями
3. Сложностью аксиом и понятий, используемых из других понятийных областей. Сложность очевидных понятий
4. Сложностью восприятия и манипулирования понятиями для человека и компьютера.

Понимание модели не может быть тестом на сложность или простоту, так как необходимо иметь эталонный "пониматель", который будет силён во всех областях и т.п. Понимание процесс субъективный.

Здравствуйте, m_n, Вы писали:

m_n>Тестом модели на простоту, или, другими словами, на минимум информации, является понимание модели и ее результатов (если такие есть) экспертом из предметной области, при условии, что для этого эксперту может потребоваться изучение только языка, на котором записана модель.

Прежде чем строить модель, надо подумать — зачем она вообще нужна? Кто ею будет пользоваться? И тестом на простоту должно быть именно понимание ее тем, кто будет этой моделью пользоваться.
Эксперт же должен проверить правильность этой модели, но не простоту. То, что просто и понятно для эксперта в предметной области, запросто может быть абсолютно непонятно программисту, который будет эту модель реализовывать... И что с такой моделью он будет делать? Правильно, стол вытирать и использовать как черновики, рисуя на обратной стороне что-то более понятное.


Вот собственно в этом корень проблемы. Все прочее в сообщении явно не принимает в расчет, что модель нужна кому-то конкретному и ориентироваться надо на него, а не на какой-то математический минимум.
И вообще простейшее — не всегда наименьшее. Человеческая память — это не ящик на строго Х Кб, что чем меньше данных — тем лучше. Человеческая память — сложная ассоциативная структура. Потому избыточная система с четко понятными взаимосвязями запросто запомнится лучше, нежели сухая "минимальная" в которой нифига не ясно без 20 лет обучения в данной области

Кстати, потому и делают разные модели одного и того же. У них разные цели и разные конечные пользователи.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, m_n:

FR>Кроме простоты модели еще нужно учитывать такую вещь как "понятность".

Понятность — это следствие сложности, а сложность — следствие количества информации.
Общая теория относительности сложнее арифметики, потому что в первой намного больше информации, чем во второй.
Не потому ли количество людей, понимающих ОТО, меньше количества людей, понимающих арифметику?

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, m_n, Вы писали:

m_n>>Существует точка зрения, что решения (модели) не накапливаются как человеческое знание. В разных проектах для одних и тех же предметных областей строятся одни и те же модели.

AVK>Да нет. Если мы построили модель, точно такую же, как уже реализована, то это значит что мы изобрели велосипед. По сути, наше решение, в твоей терминологии, будет отличаться только оптимизациями.
AVK>На практике же конкурирующие решения для одной и той же предметной области отличаются именно моделями.

Да, я считаю, что в данном примере разница конкурирующих моделей (решений) только в оптимизации.
Если посмотреть на эти конкурирующие модели, а еще лучше в код (к примеру, С++), то модели будут, скорее всего, разные.
А разные они из-за того, что оптимизация уже "встроена" в модель (в код).
Если бы существовал некий способ выделить оптимизацию из этих моделей,
то оставшиеся части моделей были бы одинаковые.
Если вы пишете модель бухгалтерии, убираем оптимизацию, что остается?
Было бы странно, если бы в этих моделях остались разные понятия о предметной области бухгалтерии.

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

Я не согласен, что модели в этих случаях разные.
Предметная область у них одна — это библиотека (статьи), форум и пр.
Соответственно простейшая модель тоже одна.
Для веб-варианта простейшая модель записана на ASP.NET, для януса та же модель записана на C#.
Модель просто записана на разных языках, от этого модель не меняется.
В каждом из этих случаев добавлена какая-то оптимизация.

Здравствуйте, m_n, Вы писали:

m_n>Я не согласен, что модели в этих случаях разные.
m_n>Предметная область у них одна — это библиотека (статьи), форум и пр.
m_n>Соответственно простейшая модель тоже одна.
m_n>Для веб-варианта простейшая модель записана на ASP.NET, для януса та же модель записана на C#.
m_n>Модель просто записана на разных языках, от этого модель не меняется.
m_n>В каждом из этих случаев добавлена какая-то оптимизация.

Модель напрямую зависит от языка. Если сформулировать модель явления на другом языке это будет другая модель описания того же явления.

Мы можем составлять более простые и сложные модели, пользуясь только понятиями предметной области: например, линейные и нелинейные уравнения для изгиба стержня: эти модели различаются, как вы выражаетесь, "функционально", описывая одно и то же явление они дают качественно разные результаты

Здравствуйте, m_n, Вы писали:

m_n>Если вы пишете модель бухгалтерии, убираем оптимизацию, что остается?

Модель бухгалтерии.

m_n>Было бы странно, если бы в этих моделях остались разные понятия о предметной области бухгалтерии.

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

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

m_n>Я не согласен, что модели в этих случаях разные.

Это не вопрос твоего согласия, это факт. Модели поведения пользователя и хранения стейта (а вокруг этого строятся эти решения) в этих случая кардинально отличаются.

m_n>Предметная область у них одна — это библиотека (статьи), форум и пр.

Да.

m_n>Соответственно простейшая модель тоже одна.

Нет.

m_n>Для веб-варианта простейшая модель записана на ASP.NET, для януса та же модель записана на C#.

ASP.NET это тоже C#.

m_n>Модель просто записана на разных языках, от этого модель не меняется.

Еще раз дело не в языках (тем более что языки одинаковые), дело в разных моделях, которые взяты за основу.

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, m_n, Вы писали:

FDS>Так и не понял, где обещанное в заголовке определение...

Если кратко, то простейшая модель — это модель, либо постоенная только на терминологии предметной области, либо в модели отсутствует оптимизация.

Обе части самодостаточны, и дают одинаковый результат (минимум информации).
Т.е. можно пользоваться любой из них, или двумя одновременно.

FDS>Область понятий обладает сложностью, которая выражается через:
FDS>1. Как вы и сказали, общее число понятий
FDS>2. Как вы забыли: связях между понятиями

Связь между сущностями сама является сущностью:
у связи есть по крайней мере один атрибут, имя, этого достаточно для обобщения связей в понятие сущностей.

FDS>3. Сложностью аксиом и понятий, используемых из других понятийных областей. Сложность очевидных понятий

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

FDS>4. Сложностью восприятия и манипулирования понятиями для человека и компьютера.

FDS>Понимание модели не может быть тестом на сложность или простоту, так как необходимо иметь эталонный "пониматель", который будет силён во всех областях и т.п. Понимание процесс субъективный.

Уточню, понимание модели экспертом из предметной области.
Эксперт и есть, как Вы выразились, эталонный пониматель.
Эксперт — это носитель знаний предметной области.

Любая модель пишется, в конечном итоге, для людей, и только человек может сказать,
верны результаты модели, или нет.
Эксперт — именно тот, и только тот, кто может такое сказать.

Я бы уточнил вот какой момент.
Есть критерий простейшей модели, и есть тест на прототу модели.
Критерий простейшей модели — это однозначное (не субъективное) правило, пользуясь которым мы получим простейшую модель, используйте только словарь предметной области.

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

Все вместе это нужно понимать так:
пользуясь критерием простейшей модели, тест на простоту всегда будет успешно пройден.

Здравствуйте, m_n, Вы писали:

m_n>Здравствуйте, FDSC, Вы писали:

FDS>>Здравствуйте, m_n, Вы писали:

FDS>>Так и не понял, где обещанное в заголовке определение...

m_n>Если кратко, то простейшая модель — это модель, либо постоенная только на терминологии предметной области, либо в модели отсутствует оптимизация.

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

В частности, этому неявно противоречит ваше утверждение "Никакой термин не изменяется, и как следствие, новой информации не добавляется" — ведь мы можем не только изменять термин, но и изменять связи. Термин же — не связь.

m_n>Обе части самодостаточны, и дают одинаковый результат (минимум информации).
m_n>Т.е. можно пользоваться любой из них, или двумя одновременно.

FDS>>Область понятий обладает сложностью, которая выражается через:
FDS>>1. Как вы и сказали, общее число понятий
FDS>>2. Как вы забыли: связях между понятиями

m_n>Связь между сущностями сама является сущностью:
m_n>у связи есть по крайней мере один атрибут, имя, этого достаточно для обобщения связей в понятие сущностей.

Это нужно вводить дополнительно, из того что вы говорили это не следует совершенно, даже наоборот.

FDS>>3. Сложностью аксиом и понятий, используемых из других понятийных областей. Сложность очевидных понятий

m_n>Предметная область всегда ограничивается какими-то рамками.
m_n>Иначе мы придем к тому, что для моделирования любой предметной области нужно будет рассматривать все человеческое знание.

В пункте ещё есть сслыка на сложность аксиом и очевидных понятий — это смысл пункта и его вы не опровергли.

Что касается конкретно вашего возражения по понятиям из других областей, то мы никогда не придём к тому, что нам придётся использовать все знаниям, накопленные человеком, т.к. это бы означало циклическую зависимость этих данных и, следовательно, их неопределённость. Для того, что бы построить определённую модель мне скорее всего не нужно знать, что делал вчера Билл Гейтс и какой у него рост и т.п.

Если мы рассмотрим различные модели, то придём к тому, что, скажем, бухгалтерская модель использует некоторые (далеко не все) понятия математики. Математика же, практически не использует понятий других наук. Даная модель будет использовать малое количество знаний.

Если мы рассмотрим модель ОТО, то мы будем использовать совершенно другие знания Математики, и эта модель будет более сложной, хотя сама по себе ОТО без математики (и связанных с ней трудностей манипулирования понятий) очень проста, проще чем бухгалтерия.

FDS>>4. Сложностью восприятия и манипулирования понятиями для человека и компьютера.

FDS>>Понимание модели не может быть тестом на сложность или простоту, так как необходимо иметь эталонный "пониматель", который будет силён во всех областях и т.п. Понимание процесс субъективный.

m_n>Уточню, понимание модели экспертом из предметной области.

"Эксперт" понятие очень относительное:
1. Кого считать экспертом
2. Жизненная ситуация из моего личного опыта: если взять несколько людей, обладающих довольно большим опытом, то только определённая часть из этих людей поймёт концепцию сразу, а определённая, возможно, будет отрицать её правильность до самой своей смерти.

m_n>Эксперт и есть, как Вы выразились, эталонный пониматель.
m_n>Эксперт — это носитель знаний предметной области.

Эксперт не есть эталонный пониматель. Эталон должен быть единственным или очень точно повторяемым.

m_n>Любая модель пишется, в конечном итоге, для людей, и только человек может сказать,
m_n>верны результаты модели, или нет.
m_n>Эксперт — именно тот, и только тот, кто может такое сказать.

Думаю ни один эксперт никогда не скажет верны ли результаты численного расчёта — для этого нужно задать точность. Заметьте, не все вычислительные модели в асимптотике сходятся к правильному решению.
Как узнать насколько правильна некоторая эвристика?

Что делать, если один "эксперт" скажет, что модель правильна, а другой — что неправильна?

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

m_n>Я бы уточнил вот какой момент.
m_n>Есть критерий простейшей модели, и есть тест на простоту модели.
m_n>Критерий простейшей модели — это однозначное (не субъективное) правило, пользуясь которым мы получим простейшую модель, используйте только словарь предметной области.

Т.е. вы хотите сказать, что верна

ТЕОРЕМА:
Для любой предметной области существует однозначный алгоритм получения модели некоторого явления в этой предметной области с использованием только понятий этой предметной области.

А теперь докажите

m_n>Тест на простоту — это проверка того, что критерий выдержан.

Как найти этот критерий? Т.е. ваше доказательство должно ещё и быть конструктивным: указывать на то, где искать алгоритм-критерий. Если вы сможете это сделать хотя бы для парочки тяжёлых для изучения отраслей — нобелевка обеспечена.

m_n>Проверка субъективна — но другой вообще нет.

Ваше субъективное мнение. Если вы не видите другой проверки, то это не значит, что её нет. Так же, как не значит, что она есть или что её отсутствие можно доказать.

m_n>Как я уже говорил, целевые пользователи модели (решения) — люди,
m_n>и только им решать, корректна модель или нет.

Корректность модели понятие субъективное в некотором плане — так что согласен. Однако не всегда люди могут за разумные сроки (не за столетия) корректность модели. Модель, которая когда-то считалась корректной через некоторое время может стать некорректной.

Именно по этому было бы неплохо иметь при себе некоторый объективный критерий корректности, который бы позволил путём проверки, скажем, на формальное соответствие аксиомам и логике предметной области определить корректность модели. Иначе мы никогда не будем знать истинных качеств модели, а будем опираться на мнение экспертов. А ведь и Эйлер ошибался!

m_n>Все вместе это нужно понимать так:
m_n>пользуясь критерием простейшей модели, тест на простоту всегда будет успешно пройден.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, m_n, Вы писали:

m_n>>Если вы пишете модель бухгалтерии, убираем оптимизацию, что остается?

AVK>Модель бухгалтерии.

m_n>>Было бы странно, если бы в этих моделях остались разные понятия о предметной области бухгалтерии.

AVK>В моделях не только понятия. В моделях решения.

Давай уточним терминологию. Я употреблял модель и решение как синонимы.
Решение и есть модель, модель реальных (объективных) процессов.
Реальный процесс — это задача, а модель — это решение.

Для разработчика модели эта задача (т.е. реальный процесс) представлен некоторым объемом человеческих(!) знаний, т.е. предметной областью.
Носителем знаний является эксперт.
Так вот эти знания и есть простоейшая модель.
Другими словами, видение экспертом предметной области является эталонным.
Следовательно, точно такое же знание и видение должно быть во всех моделях данной предметной области,
и модели разработчиков ПО не исключение...

AVK>Т.е. для одной и той же области могут существовать модели примерно одинаковой сложности, но при этом разные. С этим ты не будешь возражать?

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

AVK>А коль так, что и соответствие этих моделей реальной действительности тоже будет не идентичным. В каких то местах одна модель лучше подходит,в каких то другая.
AVK>Коротко — для мало-мальски сложных решений не существует единственной оптимальной модели заданной сложности.

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

m_n>>Я не согласен, что модели в этих случаях разные.

AVK>Это не вопрос твоего согласия, это факт. Модели поведения пользователя и хранения стейта (а вокруг этого строятся эти решения) в этих случая кардинально отличаются.

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

m_n>>Предметная область у них одна — это библиотека (статьи), форум и пр.

AVK>Да.

m_n>>Соответственно простейшая модель тоже одна.

AVK>Нет.

m_n>>Для веб-варианта простейшая модель записана на ASP.NET, для януса та же модель записана на C#.

AVK>ASP.NET это тоже C#.

Согласен, ASP.NET это тоже C#. Но сути не меняет: интерфейс не меняет модель.

Здравствуйте, m_n, Вы писали:

AVK>>В моделях не только понятия. В моделях решения.

m_n>Давай уточним терминологию. Я употреблял модель и решение как синонимы.

Тогда почему на основании равенства понятий ты делаешь вывод о равенстве моделей? Во-первых, как я уже говорил, часть понятий зависит от самой модели. Т.е. модель может вводить собственные понятия в предметную область. Во-вторых, на основе одних и тех же понятий можно придумать разные решения (не эквивалентные на 100%!).

m_n>Реальный процесс — это задача,

Нет и еще раз нет. Модель в том числе предлагает и процесс. Никогда не наблюдал за внедрением? После него процессы меняются! Возвращаясь к приведенному мной примеру — процесс чтения форума посредством веб-интерфейса и при помоще януса, это разные процессы. Эти решения прежде всего предлагают способ чтения форума, а потом уже соответствующию поддержку ввиде реализации.

m_n>Носителем знаний является эксперт.
m_n>Так вот эти знания и есть простоейшая модель.

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

m_n>Другими словами, видение экспертом предметной области является эталонным.

Ни в коем случае. Хотя бы потому что не существует двух экспертов с одинаковым представлением предметной области. Более того, у одного эксперта может быть несколько представлений, удобных в различных случаях.

AVK>>Т.е. для одной и той же области могут существовать модели примерно одинаковой сложности, но при этом разные. С этим ты не будешь возражать?

m_n>... и я буду возражать,

Т.е., по сути, ты утверждаешь, что у каждой задачи есть единственно правильное решение? Знаешь, мне даже спорить с этим не хочется, бо очевидная несуразица.

AVK>>Это не вопрос твоего согласия, это факт. Модели поведения пользователя и хранения стейта (а вокруг этого строятся эти решения) в этих случая кардинально отличаются.

m_n>Твой "факт" как-то не убедителен.

Ну если мы будем расценивать факты по убедительности, мы далеко не уйдем. Позиция "если факт не подходит под мою теорию, то тем хуже для факта" абсолютно неконструктивна.

m_n>Поведение пользователя и хранение состояний — это реализация,

Нет, это модель. Реализация это воплощение этой модели ввиде программного кода. Если я перепишу янус на С++, то модель останется той же самой, а вот реализация будет кардинально иной.

m_n> и ты говоришь о модели реализации

Модель реализации это сильно

m_n>В простейшей модели есть функция "навигация по форуму".

Эта модель негодная, она слишком примитивна. Она не соответствует потребностям.

m_n>То, что в веб-варианте для этого потребуется заводить состояние сессии — это частная реализация веб-варианта.

Нет, это уточнение модели.

AVK>>ASP.NET это тоже C#.

m_n>Согласен, ASP.NET это тоже C#. Но сути не меняет: интерфейс не меняет модель.

Зато модель меняет интерфейс.

Здравствуйте, m_n, Вы писали:

m_n>Не потому ли количество людей, понимающих ОТО, меньше количества людей, понимающих арифметику?

Нет, понимающих ОТО меньше потому, что она не используюется в реальной жизни большинством людей — навык даже если вдруг и приобретается, быстро теряется.
Хорошо понимать и говорить на русском языке гораздо сложнее, чем вычислять логарифмы (напиши программу того и другого?), но в России вот гораздо больше людей хорошо понимают русский язык, нежели вычисляют логарифмы...

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

ну давай рассмотрим придуманный случай.

вот тебе 2 модели (описания) структуры столов "Ярутама-М":
первая:
ЯРМП/ЯРМД
ЯРОП
ЯРОЛ
ЯКК

Эксперт по столам "Ярутама" псмотрел и согласился, что все очень просто и понятно.

вторая:
Столы "Ярутама-М" собираются из столешницы, двух опорных стоек и фиксирующей перемычки, которая соединяет опорные стойки и столешницу, придавая жесткость конструкции. Модель "Ярутама-М" имеет специально изготовленные для нее столешницы, поставляемые в двух вариантах — с пластиковым покрытием (ЯРМП) или деревянным (ЯРМД). Опорные стойки стандартны для большинства столов серии "Ярутама-ОФис" (серия стоек ЯРО) и делятся на левые(ЯРОЛ) и правые(ЯРОП). Фиксирующая перемычка используется стандартная для всех столов "Ярутама" — ЯКК.
(+схема соединения частей)

Про вторую модель эксперт по столам "Ярутама" сразу сказал, что она большая, сложная, и напрасно поясняет очевидные вещи. Запомнить и понять 5 коротких слов, как это сделано в первой модели — гораздо проще. "А схема там — вообще нафик не уперлась — и так ясно что куда соединяется, поскольку это единственный возможный способ в этой серии."
Вот такие дела...

Здравствуйте, m_n, Вы писали:

m_n>Здравствуйте, AndrewVK, Вы писали:

AVK>>Здравствуйте, m_n, Вы писали:

m_n>>>Если вы пишете модель бухгалтерии, убираем оптимизацию, что остается?

AVK>>Модель бухгалтерии.

m_n>>>Было бы странно, если бы в этих моделях остались разные понятия о предметной области бухгалтерии.

AVK>>В моделях не только понятия. В моделях решения.

m_n>Давай уточним терминологию. Я употреблял модель и решение как синонимы.
m_n>Решение и есть модель, модель реальных (объективных) процессов.
m_n>Реальный процесс — это задача, а модель — это решение.

m_n>Для разработчика модели эта задача (т.е. реальный процесс) представлен некоторым объемом человеческих(!) знаний, т.е. предметной областью.
m_n>Носителем знаний является эксперт.
m_n>Так вот эти знания и есть простоейшая модель.
m_n>Другими словами, видение экспертом предметной области является эталонным.
m_n>Следовательно, точно такое же знание и видение должно быть во всех моделях данной предметной области,
m_n>и модели разработчиков ПО не исключение...

Я не эскперт, но свою предметную область (сопротивление материалов) я вижу по разному. В зависимости от того, что мне надо, я буду использовать разные типы решений одной и той же задачи.

AVK>>Т.е. для одной и той же области могут существовать модели примерно одинаковой сложности, но при этом разные. С этим ты не будешь возражать?

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

Вот мне очень интересно: есть две самых простых модели, касающихся изгиба стержней. Все они в простейшем случае сводятся к формулам, типа FL^3/EI. Одна простая модель позволяет мне рассчитать на прочность стержень, т.е. узнать, не разрушится ли он от заданной нагрузки. Вторая модель, то же простая, позволяет мне рассчитать стержень на устойчивость, т.е. узнать не разрушится ли он от заданной нагрузки . Оба рассчёта обязательны. Если бы мы могли построить более точную модель, мы могли бы объединить два расчёта в один (что не очень-то практично), но эта модель была бы далеко не такая простая и требовала бы значительно лучшей математики.

AVK>>А коль так, что и соответствие этих моделей реальной действительности тоже будет не идентичным. В каких то местах одна модель лучше подходит,в каких то другая.
AVK>>Коротко — для мало-мальски сложных решений не существует единственной оптимальной модели заданной сложности.

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

m_n>>>Я не согласен, что модели в этих случаях разные.

Тогда объясните, чем они одинаковы

AVK>>Это не вопрос твоего согласия, это факт. Модели поведения пользователя и хранения стейта (а вокруг этого строятся эти решения) в этих случая кардинально отличаются.

m_n>Твой "факт" как-то не убедителен.
m_n>Поведение пользователя и хранение состояний — это реализация, и ты говоришь о модели реализации, в которой присутствует оптимизация по окружению, в котором будет работать модель.
m_n>В простейшей модели есть функция "навигация по форуму".
m_n>То, что в веб-варианте для этого потребуется заводить состояние сессии — это частная реализация веб-варианта.

Т.е. вы хотите сказать, что в обсуждаемой предметной области такого понятия как, скажем, IP-адрес или кук — нет? Если идти по такому пути, то можно сказать, что простейшая модель некоторой предметной области — это один термин предметной области. Например, модель доступа к форуму сайта есть термин "Действия Для Доступа К Форуму Сайта". В таком случае каждая новая модель будет добавлять термин в предметную область тем самым усложняя её, а сложность области будет зависить от количества различных задач, решаемых в этой области (последнее, кстати, не так уж и нелогично)

m_n>>>Предметная область у них одна — это библиотека (статьи), форум и пр.

Выразите это одним словом. Что это за область, которая включает в себя и статьи и форум?

m_n>ASP.NET это тоже C#. Но сути не меняет: интерфейс не меняет модель.

Способ записи меняет модель, так как при этом используется разная терминология.

Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, m_n, Вы писали:

m_n>>Тестом модели на простоту, или, другими словами, на минимум информации, является понимание модели и ее результатов (если такие есть) экспертом из предметной области, при условии, что для этого эксперту может потребоваться изучение только языка, на котором записана модель.

F>Прежде чем строить модель, надо подумать — зачем она вообще нужна? Кто ею будет пользоваться? И тестом на простоту должно быть именно понимание ее тем, кто будет этой моделью пользоваться.

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

F>Эксперт же должен проверить правильность этой модели, но не простоту.

Эксперт проверяет не только правильность (адекватность) модели, но и простоту.
Практическая ситуация: эксперту показывают код на С++. Это модель реализации.
Как я уже говорил, для понимания модели эксперту максисмум нужно выучить язык модели, т.е. С++.
Если после этого эексперт понял модель, значит это простейшая модель.
Добавте в модель опритимизацию в виде паттернов проектирования, хэширование, любые другие виды оптимизации и у эксперта возникнут вопросы.

F>То, что просто и понятно для эксперта в предметной области, запросто может быть абсолютно непонятно программисту, который будет эту модель реализовывать...И что с такой моделью он будет делать? Правильно, стол вытирать и использовать как черновики, рисуя на обратной стороне что-то более понятное.

В разработке решения есть роль аналитика, который обязан представить предметную область в виде аналитической модели, понятной остальным ролям процесса разработки, программистам в том числе. А аналитик общается с экспертом.


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

Минимум — это количественная оценка простоты.

F>И вообще простейшее — не всегда наименьшее.
F>Человеческая память — это не ящик на строго Х Кб, что чем меньше данных — тем лучше. Человеческая память — сложная ассоциативная структура. Потому избыточная система с четко понятными взаимосвязями запросто запомнится лучше, нежели сухая "минимальная" в которой нифига не ясно без 20 лет обучения в данной области

F>Кстати, потому и делают разные модели одного и того же. У них разные цели и разные конечные пользователи.

Здравствуйте, m_n, Вы писали:

m_n>Сложность определяется как количество информации: чем больше информации, тем сложнее, чем меньше информации, тем проще. Субъективно больший объем информации труднее понять.

Коллега, неужели вы знаете, что такое информация и даже, как ее измерять в битах? Не поделитесь? Я-то всегда думал, что в битах измеряют количество данных.

Здравствуйте, craft-brother, Вы писали:

CB>Здравствуйте, m_n, Вы писали:

m_n>>Сложность определяется как количество информации: чем больше информации, тем сложнее, чем меньше информации, тем проще. Субъективно больший объем информации труднее понять.

CB>Коллега, неужели вы знаете, что такое информация и даже, как ее измерять в битах? Не поделитесь? Я-то всегда думал, что в битах измеряют количество данных.

Данные это и есть информация, хотя информация данными не ограничивается.
Информация измеряется в битах, а данные, это видимо один из видов информации, следовательно данные тоже измеряются в битах.
А что Вы понимаете под "данными"?

Здравствуйте, m_n, Вы писали:

m_n>Здравствуйте, fmiracle, Вы писали:

F>>Здравствуйте, m_n, Вы писали:

m_n>>>Тестом модели на простоту, или, другими словами, на минимум информации, является понимание модели и ее результатов (если такие есть) экспертом из предметной области, при условии, что для этого эксперту может потребоваться изучение только языка, на котором записана модель.

F>>Прежде чем строить модель, надо подумать — зачем она вообще нужна? Кто ею будет пользоваться? И тестом на простоту должно быть именно понимание ее тем, кто будет этой моделью пользоваться.

m_n>Эксперт.
m_n>Это эксперт видит в своей предметной области возможноть применения ИТ-решения.
m_n>Эксперт выступает как постановщик, и как будущий пользователь.
m_n>Это такая обобщающая роль, которую могут исполнять один или несколько человек.

F>>Эксперт же должен проверить правильность этой модели, но не простоту.

m_n>Эксперт проверяет не только правильность (адекватность) модели, но и простоту.
m_n>Практическая ситуация: эксперту показывают код на С++. Это модель реализации.
m_n>Как я уже говорил, для понимания модели эксперту максисмум нужно выучить язык модели, т.е. С++.
m_n>Если после этого эексперт понял модель, значит это простейшая модель.
m_n>Добавте в модель опритимизацию в виде паттернов проектирования, хэширование, любые другие виды оптимизации и у эксперта возникнут вопросы.

Если C++ — это модель реализации, то при той же самой реализации (вплоть до ассемблерного кода) я могу написать разную модель на C++.

F>>И вообще простейшее — не всегда наименьшее.
F>>Человеческая память — это не ящик на строго Х Кб, что чем меньше данных — тем лучше. Человеческая память — сложная ассоциативная структура. Потому избыточная система с четко понятными взаимосвязями запросто запомнится лучше, нежели сухая "минимальная" в которой нифига не ясно без 20 лет обучения в данной области

Интересно, почему на это небыло ответа, ведь довольно хорошее утверждение...

Здравствуйте, m_n, Вы писали:

m_n>Здравствуйте, craft-brother, Вы писали:

CB>>Здравствуйте, m_n, Вы писали:

m_n>>>Сложность определяется как количество информации: чем больше информации, тем сложнее, чем меньше информации, тем проще. Субъективно больший объем информации труднее понять.

CB>>Коллега, неужели вы знаете, что такое информация и даже, как ее измерять в битах? Не поделитесь? Я-то всегда думал, что в битах измеряют количество данных.

m_n>Данные это и есть информация, хотя информация данными не ограничивается.

Данные могут не быть информацией. Если я уже извлёк всю информацию из данных, то для меня эти данные уже не содержат новых знаний, т.е. не содержат информации

m_n>Информация измеряется в битах, а данные, это видимо один из видов информации, следовательно данные тоже измеряются в битах.
m_n>А что Вы понимаете под "данными"?


Ну, припёрлись на программисткий форум и говорите, что информация измеряется в битах... Скоро с вами никто спорить не захочет