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

Любая предметная область обладает сложностью, большей нуля, т.е. сложность любой предметной области составляет, как минимум, 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>А что Вы понимаете под "данными"?


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

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

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

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

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

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

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

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

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

Если на то пошло, для вас данные как минимум были источником информации.
Информацию вы получили, ее можно измерить. А данные больше не является для вас источником информации.

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

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

Вы Википедию признаете?

Бит
Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Бит (от англ. binary digit; также игра слов: англ. bit — немного) м. скл

1. По Шеннону бит — это двоичный логарифм вероятности равновероятных событий или сумма произведений вероятности на двоичный логарифм вероятности при разновероятных событиях.

2. Один разряд двоичного кода (двоичная цифра). Может принимать только два взаимоисключающих значения: да/нет, 1/0, включено/выключено, и т. п.

3. Базовая единица измерения количества информации, равная количеству информации, содержащемуся в опыте, имеющем два равновероятных исхода. Это тождественно количеству информации в ответе на вопрос, допускающий ответы «да» либо «нет» и никакого другого (то есть такое количество информации, которое позволяет однозначно ответить на поставленый вопрос). В одном двоичном разряде содержится один бит информации.

Третий пункт — для Вас.

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

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

А мера какая?
Я вот могу придумать такой формат представления данных:
Понятно, что 1 бит — это два значения. Считаем, что
1 — все данные во вселенной (включая это сообщение )
0 — нет данных.

Таким образом я в одном бите могу сохранить все данные во Вселенной!
Я клевый!

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

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

...

F>1 — все данные во вселенной (включая это сообщение )
F>0 — нет данных.

И вдогонку — собственно суть вопроса:
Даю данные:
1
Ты извлек из этих данных (а в них ведь закодированы ВСЕ данные Вселенной! )- какую-нибудь полезную тебе информацию? Ну скажем там, алгоритм извлечения квадратного корня?

Данные сами по себе значат мало. Одни и те же данные можно протрактовать так или иначе. Можно извлечь из них что-то полезное или ничего не понять. Информация — это то, что получается от трактовки данных.
Где содержится больше информации — на ДВД с подробным описанием процесса обогащения урана (8000Мб) или на ДВД с порнофильмом(8000Мб)?
Для многих порнофильм пополезнее будет А у кого-то гарем есть, но уран нужен.
А кто-то вообще в пустыне сидит без электричества и ему оба диска одинаково неинформативны.

Объем данных можно замерить в битах. Объем информации?
Одну и ту же информацию можно представить одними данынми или другими.

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

Ну что, я основательно все запутал?
Я старался.
Надеюсь, будет над чем подумать. Хотя бы что в чем мерять.
Но не надо все же говорить "1 бит информации".
Ибо в 1 бите — вся Вселенная!

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

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

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

F>А мера какая?
F>Я вот могу придумать такой формат представления данных:
F>Понятно, что 1 бит — это два значения. Считаем, что
F>1 — все данные во вселенной (включая это сообщение )
F>0 — нет данных.

F>Таким образом я в одном бите могу сохранить все данные во Вселенной!
F>Я клевый!

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

Твой 1 бит — это факт что данные во Вселенной либо существуют, либо нет.
Экперимент к твоей информации в 1 бит — это проверка, существует ли Вселенная? или существует ли данные во Вселенной? ответ дает 1 бит информации — да, существует, либо нет, не существует.
Больше информации за твоей фразой "1 — все данные во Вселенной" нет.
Проверка любого факта потребует как минимум еще одного бита. а на самом деле фактов — очень много.
Те же звезды: если на твой вопрос ответить да, Вселенная существует (1 бит информации), мы задаем другой вопрос (и проводим экперимент по проверке) существуют ли звезды во Вселенной? Ответ — да. Итого мы имеем 2 бита информации, которые дают нам знание что Вселенная существует, и в ней существуют звезды.

Задавая вопросы (и проводя эксперименты) ко всем фактам нашего знания, мы получим объем информации нашего знания. Битов будет "до фига и больше".

Короче говоря, в один бит все факты (которые и составляют наше знание), запихать не получится.
1 бит дает лишь информацию знание либо существует, либо нет. Любой дополнительный факт потребует как минимум еще одного бита.

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

m_n>А что Вы понимаете под "данными"?

50 лет назад Н. Винер сказал, что информация есть информация, а не материя и не энергия. «Информация — это обозначение содержания, черпаемого нами из внешнего мира в процессе нашего приспособления к нему и приведения в соответствии с ним нашего мышления» [1]. По поводу того, что есть информация с тех пор сказано много. Диапазон мнений простирается от узкоспециальных определений: «информация — это то, что устраняет неопределенность выбора» [2], до всеобъемлющих трактовок: «информация – первооснова Вселенной» [4]. Поэтому, пока «согласия в товарищах нет» дадим свое понимание определения информации.

Если обратиться к этимологии, то слово информация вошло в русский язык в Петровскую эпоху в значении "представление, понятие о чем-либо" [5]. Следуя Н.Винеру, предлагаю, не мудрствуя лукаво, вернуть слову исходный смысл и дать простое определение:

Определение 1. Информация — представление, понятие о чем-либо.

Согласно [7] представление это образ предметов, воздействовавших на органы чувств человека, а понятие, это форма мышления, отражающая существенные свойства, связи и отношения предметов и явлений. Не будем обижать «братьев наших меньших» и будем полагать, что способностью представлять и понимать наделена вся живая природа. Но только живая природа. Информация, это специфическая для живой природы форма отражения. Отражение — всеобщее свойство материи, которое заключается в том, что один предмет может изменяться при взаимодействии с другим предметом, и это изменение может характеризовать отражаемый объект.

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

Следствие 1. Информация есть продукт живой материи и только живой материи.

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

К. Шеннон, «назначенный» одним из отцов-основателей теории информации, писал применительно к техническим системам, лишь о сигналах и связи и сам указывал, что информация, которая передается сигналами, его не интересует [2]. И не существует никаких объективных критериев, чтобы определить, какую информацию несет (и несет ли вообще) конкретный сигнал, если не знать правила его интерпретации. Любое материальное представление информации вне сознания субъекта ее породившего есть знак, сигнал, сообщение, закодированное на определенном языке, и не может рассматриваться в отрыве от интерпретатора. Поэтому,

Следствие 2. Информация вне сознания субъекта ее породившего может рассматриваться только относительно пары сообщение-интерпретатор.

Свисток для собаки Павлова будет информацией о приглашении к еде, для черепашки Грея В. Уолтера – информацией о наличии препятствия впереди, для милиционера – призыв на помощь. А теперь ответьте, пожалуйста, сколько и какой информации передает сообщение «свисток»? А какую информацию для постороннего человека несет узелок, завязанный кем-то «на память» на носовом платке? Поэтому наличие информации в любом сообщение всегда относительно и зависит от получателя-интерпретатора. Формула К. Шеннона описывает лишь законы кодирования и передачи сообщений по каналам связи, но не количество передаваемой информации. Поскольку информация не энергия и не материя, представляется разумным вообще отказаться от попыток ее количественного измерения. В противном случае нам придется отвечать на вопрос, где больше информации в законе Ома или в теореме Пифагора.

Наряду с понятием информация часто употребляется термин знание, «проверенный практикой результат познания действительности, верное её отражение в сознании человека» [7]. Однако, нет никаких формальных оснований для того, чтобы различить информацию и знание. Например, геоцентрическая модель Вселенной Птолемея в течение двух тысяч лет неплохо подтверждалась практикой, но неверно отображала действительность. Это что? Знание или информация? Или другой пример: «Волга впадает в Каспийское море». Это что? Единичный факт отражения действительности или знание – продукт познавательной деятельности? А таблица умножения это знание или просто информация? Термин знание я бы предложил использовать в его общепринятом бытовом смысле: знаю или не знаю. Например, я знаю таблицу умножения и не знаю, что означает данный свисток. Другой пример общественное знание — информация, материализованная в произведениях искусства, науки и техники. Наконец, информация, занесенная в память ЭВМ, это тоже знание. Таким образом,

Определение 2. Знание это зафиксированная информация.

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

Определение 3. Данные это информация, представленная на определенных материальных носителях и в знаковой системе, которые предназначены для автоматической передачи, обработки и хранения с использованием компьютера.

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

Определение 4. Программа = Задача + Модель + Алгоритм.

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

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

Алгоритм, безусловно, служит основополагающим понятием вычислительного процесса, но алгоритм уже утрачивает свое первостепенное значение. «Вопреки привычной точке зрения, алгоритм естественен только для профессиональных программистов и разработчиков вычислительных методов. Что же касается задач, решаемых с помощью компьютера, то природа алгоритма в определенном смысле аналогична программированию в кодах. Контраст в уровнях спецификации между ними оказывается несущественным по сравнению с фундаментальным различием между традиционным алгоритмическим подходом и моделью, которая является наиболее естественной формой спецификации реальной задачи. …Через 10 -15 лет алгоритм ожидает судьба ассемблеров и программирования в кодах: потеря сегодняшних ключевых позиций и место в сравнительно тонком, базовом уровне будущей технологии программирования». [8]

Ключевым понятием в определении программы является задача. Как неразумно обсуждать техническую систему в отрыве от задачи, которую она решает, так бессмысленно рассматривать программу вне целей, для которых она создается. Можно конечно рассуждать о достоинствах микроскопа в качестве инструмента для забивания гвоздей. Но, (ИМХО, разумеется) лучше попросить у соседа молоток.

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


1. Н. Винер, Кибернетика и общество, Издательство иностранной литературы, Москва, 1958
2. Шеннон К. Математическая теория связи. Работы по теории информации и кибернетике. М., 1963.
3. Ветров А.А., Семиотика и ее основные проблемы, Издательство политической литературы, Москва . 1968
4. Плыкин В.Д. «В начале было слово…» или След на воде, Ижевск,1997. (http://lib.rin.ru/doc/i/85040p.html)
5. Е. Горный, История информации в кратком изложении, Русский Журнал, 30.08.2001 (http://www.zhurnal.ru/staff/gorny/texts/information.html)
6. Дж.Р.Сирл, Разум мозга — компьютерная программа? В МИРЕ НАУКИ. (Scientific American. Издание на русском языке). 1990. № 3
7. «Большая советская энциклопедия», 3-е изд., Москва, «Советская энциклопедия», 1969 — 1978
8. А.С. Нариньяни, Модель или алгоритм: новая парадигма информационной технологии, "Информационные технологии" N4, 1997.

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

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

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

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

Вопрос не в использовании знания, а в его приобретении.
Если бы ОТО была того же объема, что и арифметика, ее бы преподавали в 3-ем классе средней школы.
Что там было бы понимать, если бы ОТО была объемом с арифметику?
Если принять арифметику, скажем, в 100 бит, и если принять что ОТО тоже укладывается в эти 100 бит, то почему бы не понять ОТО третьекласнику?
В 100 бит уложится столько же фактов из ОТО, столько туда уложилось фактов из арифметики.
Пусть потом люди забывают ОТО за ненадобностью, но не было бы проблем в понимании ОТО.

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

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

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

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

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

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

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

Для эксперта обе модели одинаковы.
У него в голове вся предметная область.
Обе модели показывают экперту его же предметную область в разной детализации.
Экперт знает еще поболее чем эти две модели.
Я могу продолжить твой ряд третьей моделью, в которой будут учтены свойства материалов, и пр. т.е. третья модель будет еще более детальней.
Но эксперту даже такая модель ничего не дает, это все та же область знаний.
Для эксперта любая модель понятна, главное чтобы в модели были факты только из предметной области.

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

m_n>Если на то пошло, для вас данные как минимум были источником информации.

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

m_n>Информацию вы получили, ее можно измерить. А данные больше не является для вас источником информации.

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

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

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

m_n>Вы Википедию признаете?

Признаю. Но если там ошибка или просто одна из возможных трактовок — то это ничего не меняет.

m_n>

m_n>Бит
m_n>Материал из Википедии — свободной энциклопедии
m_n>Бит (от англ. binary digit; также игра слов: англ. bit — немного) м. скл

m_n>3. Базовая единица измерения количества информации, равная количеству информации, содержащемуся в опыте, имеющем два равновероятных исхода. Это тождественно количеству информации в ответе на вопрос, допускающий ответы «да» либо «нет» и никакого другого (то есть такое количество информации, которое позволяет однозначно ответить на поставленый вопрос). В одном двоичном разряде содержится один бит информации.

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

По вашему, если я зашифровал данные, то для человека, не знающего ключ, данные всё равно содержат информацию, ровно такую же, как и в незашифрованном виде.

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

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

В общем, спор по теме определения информации закрыт: "Осторожно, религиозные войны!". Это всё равно не в тему.

Посмотрите, где разница:
Базовая единица измерения количества данных, равная количеству данных, содержащемуся в опыте, имеющем два равновероятных исхода. Это тождественно количеству данных в ответе на вопрос, допускающий ответы «да» либо «нет» и никакого другого (то есть такое количество данных, которое позволяет однозначно ответить на поставленый вопрос). В одном двоичном разряде содержится один бит данных?

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

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

m_n>>Если на то пошло, для вас данные как минимум были источником информации.

FDS>Естественно, данные могут быть источником информации. А могут и не быть.

А я и не говорил что данные должны быть источником информации.

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

Откуда такое утверждение о невозможности измерения информации?

m_n>>Информацию вы получили, ее можно измерить. А данные больше не является для вас источником информации.

FDS>Вся проблема в том, что информация интуитивное понятие, не имеющее сторого определения. Я, например, понимаю информацию как количество новых знаний, которые можно извлечь из данных. Для каждого человека она разная для одних и тех же данных. Некоторые понимают её как энтропию. Или, например, вероятность — мера нашего незнания. Т.е. количество информации зависит от вероятностей (некоторые так считают)

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

Вот это я бы изменил, ибо меня поняли что "данные" это синоним "информации".
Согласен, фраза корявая.
Я ведь не спроста начал уточнять про источник информации.
Информации вне приемника не существует, — с этим видимо и Вы согласитесь.

m_n>>>>А что Вы понимаете под "данными"?

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

m_n>>Вы Википедию признаете?

FDS>Признаю. Но если там ошибка или просто одна из возможных трактовок — то это ничего не меняет.

Определение в вики — это чье-то мнение, одна из возможных трактовок.
Если Вы подходите к чьему-либо мнению с позиции "если там ошибка",
ваше собственное мнение (которое ничем не лучше из вики по данной проблеме),
рассматривайте с таких же позиций, "если там ошибка".
Вы собственное определение проверяли на ошибочность?

Так что говорить об ошибках в чьих-то определениях не уместно, контр-аргументируйте.

m_n>>

m_n>>Бит
m_n>>Материал из Википедии — свободной энциклопедии
m_n>>Бит (от англ. binary digit; также игра слов: англ. bit — немного) м. скл

m_n>>3. Базовая единица измерения количества информации, равная количеству информации, содержащемуся в опыте, имеющем два равновероятных исхода. Это тождественно количеству информации в ответе на вопрос, допускающий ответы «да» либо «нет» и никакого другого (то есть такое количество информации, которое позволяет однозначно ответить на поставленый вопрос). В одном двоичном разряде содержится один бит информации.

FDS>Как я уже сказал — это одно из пониманий информации. Причём безграмотное. Если я знаю ответ на вопрос, то его ответ уже не содержит для меня информации. Отсюда можно даже размышлять об информационной безопасности.

Не хочется заострять на этом внимание. но Вы опять высказываетесь о мнении отталкиваясь от своего мнения,
грамотного, как я полагаю.
Если Вы не согласны с мнением из вики, приведите какие-то доводы вашего несогласия.

FDS>По вашему, если я зашифровал данные, то для человека, не знающего ключ, данные всё равно содержат информацию, ровно такую же, как и в незашифрованном виде.

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

FDS>По моему, получаем, что пока человек не получил и зашифрованные данные, и ключ, он не имеет ни грамма информации: он не может извлечь из зашифрованного текста никаких знаний — он ему бесполезен. А мы не теряем никакой информации, даже если опубликуем этот текст по телевидению. Даже если у него есть и ключ и зашифрованные данные, он всё равно не сможет получить расшифровку, если не знает нужного алгоритма шифрования или у него нет соотв. выч. техники.

FDS>Если вы понимаете информацию тождественно данным, лучше употребляйте слово данные: так будет меньше путаницы.

см. выше

FDS>В общем, спор по теме определения информации закрыт: "Осторожно, религиозные войны!". Это всё равно не в тему.

FDS>Посмотрите, где разница:
FDS>Базовая единица измерения количества данных, равная количеству данных, содержащемуся в опыте, имеющем два равновероятных исхода. Это тождественно количеству данных в ответе на вопрос, допускающий ответы «да» либо «нет» и никакого другого (то есть такое количество данных, которое позволяет однозначно ответить на поставленый вопрос). В одном двоичном разряде содержится один бит данных?

В одном двоичном разряде может содержаться один бит информации.

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

m_n>Да, я считаю, что в данном примере разница конкурирующих моделей (решений) только в оптимизации.

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

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

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

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

Выделенное — это грубейшая ошибка. Как глаза должны только передавать мозгу полученную информацию, а не говорить что ему делать, так и модель должна решать поставленные задачи, а не ставить новые или отменять старые. Несоблюдение этого правила приводит в результате к появлению уродцев, в которых приоритет функциональных требований понижен до плинтуса и ими жертвуют направо и налево. А во главу угла ставится polymorphic behaviour, nice object model и прочие мелочи имплементации.

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

IT>Выделенное — это грубейшая ошибка.

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

IT> Как глаза должны только передавать мозгу полученную информацию, а не говорить что ему делать, так и модель должна решать поставленные задачи, а не ставить новые или отменять старые.

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

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

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

Боюсь, что если я попрошу тебя привести пример, то сам быстро убедишься, что задачи будут разные.

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

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

Ну и в чём здесь противоречие с утверждениями m_n? Ты здесь говоришь о том, что он называет оптимизацией.

FDS>Т.е. вы хотите сказать, что в обсуждаемой предметной области такого понятия как, скажем, IP-адрес или кук — нет?

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

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

IT>>Выделенное — это грубейшая ошибка.

AVK>Отнюдь. Как я уже говорил, нас интересует не начальное состояние системы "предмет автоматизации — автоматизация", а конечное. И думать, что мы можем предсказать это состояние несколько самонадеянно, и именно это и является грубейшей ошибкой. Поэтому agile-методики предлагают последовательный процесс достижения оптимального дизайна.

С этим как раз никто не спорит.

IT>> Как глаза должны только передавать мозгу полученную информацию, а не говорить что ему делать, так и модель должна решать поставленные задачи, а не ставить новые или отменять старые.

AVK>А она их и решает. Только вот в случае софтовых систем модель часто сама является частью предметной области.

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

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

AVK>Коль скоро модель является частью предметной области, то она должна в себе содержать модель самой себя.

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

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

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

[skip]

С вышесказанным в принципе согласен.

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

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

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

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

К сожалению, от этого не всегда можно избавиться. Хотя минимизировать такие вещи нужно максимально. Здесь я бы тоже поговорил о приоритетах. Простота/понимаемость/сопровождаемость кода это всё вещи нужные, но часто находящие по приоритету ниже нефункциональных требований или на одном с ними уровне, если они не входят в противоречие. Что в каком-либо конкретном случае случае более важно? Понимаемость и простота кода или его быстродействие? Если оптимизация позволит существенно ускорить какую-либо нефункциональную характеристику системы, то такая оптимизация нужна и оправдана. Если нет, то простота кода значительно важнее.

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

1. functional requirements
2. nonfunctional requirements
3. maintainability

Всё остальное вторично и должно следовать вышеобозначенным приоритетам.

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

+1

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

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

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

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

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

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

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

AVK>>А она их и решает. Только вот в случае софтовых систем модель часто сама является частью предметной области.

IT>И как раз это является грубейшей ошибкой. Модель — это производная от наших знаний о предметной области.

Я разве с этьим спорю?

IT> Меняется качество и состав этих знаний — меняется модель.

Конечно.

IT> Но ни в коем случае не наоборот.

В коем случае. Именно так и происходит, коль скоро мы понимаем, что готовая система есть часть предметной области.

IT> Наоборот — это смена приоритетов и в результате мы уже будем разрабатывать софт не под предметную область и функциональные трубования, а подстраиваться под модель и её ограничения.

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

IT>

AVK>>Коль скоро модель является частью предметной области, то она должна в себе содержать модель самой себя.

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

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

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

IT>> Меняется качество и состав этих знаний — меняется модель.
AVK>Конечно.
IT>> Но ни в коем случае не наоборот.

AVK>В коем случае. Именно так и происходит, коль скоро мы понимаем, что готовая система есть часть предметной области.

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

AVK>Заметь, про приоритеты упомянул ты. Я про приоритеты ничего не говорил. И про функциональность тоже ничего не говорил. Мне кажется, ты говоришь просто о другом. Те мысли, которые я писал, их нельзя воспринимать как руководство к действию, ты же их пытаешься именно так трактовать.

А как их следует тогда тракторвать?

AVK>Я пишу о начале проектирования, о том как вобще этот процесс выглядит, а ты уже говоришь о деталях.

Так о начале проектирования или о готовой системе? Ты уж сам определись сначала. Что касается деталей, то я всегда готов о них говорить, если эти детали влияют на процесс проектирования. Сам процесс проектирования — это и есть процесс выяснение деталей.

AVK>При чему тут функциональность? Оторвись от деталей, попробуй взглянуть чуть шире. То, что функциональные требования надо соблюдать, тут никто возражать не будет, ты споришь сам с собой. Речь о другом — выполнить функциональные требования недостаточно.

Это и так понятно. Только вот недостаточно не означает необязательно.

AVK>Понимаешь, вот RUP, к примеру, при соблюдении всех танцев с бубном, вроде как говорит что будет все хорошо. Однако на практике мы видим иное — даже при 100% соблюдении всех функциональных требований успешное внедрение не гарантированно. Вот и попробуй подумать почему и как с этим бороться. А изрекать банальность мы тут все умеем.

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

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

IT>Кто это мы и при чём тут вообще готовая система?

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

IT> До неё ещё дожить надо. А пока мы до неё доживём модель должна оставаться моделью и покорно следовать за предметной областью.

Видишь ли, в исходном топике не говорится ничего про сначала и потом. Не стоит уводить тему в сторону.

IT>А как их следует тогда тракторвать?

В контексте исходного топика.

AVK>>Я пишу о начале проектирования, о том как вобще этот процесс выглядит, а ты уже говоришь о деталях.

IT>Так о начале проектирования или о готовой системе?

О модели.

IT> Ты уж сам определись сначала. Что касается деталей, то я всегда готов о них говорить, если эти детали влияют на процесс проектирования.

А я в данном топике нет, ибо тема другая.

IT> Сам процесс проектирования — это и есть процесс выяснение деталей.

Не все методологии с твоей точкой зрения совпадают. Так что вопрос спорный. Хотя я, с оговорками, с тобой и соглашусь.

IT>Это и так понятно.

Вот это и есть моя главная мысль. А вторая мысль — что заметную часть этой неопределенности как раз и вносит рекурсивный характер хорошей модели.
Вернемся к твоему примеру. Ты правильно заметил, что нефункциональные требования иногда переходят в функциональные. Но, скажем, зачастую то же требование перформанса не всегда можно заранее предсказать. Бывает, что проблемы вылазят по ходу проектирования или даже разработки. Некоторые это все списывают на безрукость архитекторов, но моя ИМХА, это то, что подобные ситуации фундаментальны, и надо не пытаться все и сразу удовлетворить в первом же прототипе модели.

IT> Только вот недостаточно не означает необязательно.

А я этого и не говорил. Я ж говорю — ты сам с собой сспоришь. Или, как вы с Владом любите говорить, борешься со своими фобиями. По мне так в своей области я последние года 3-4 с явлением overframeworked не сталкиваюсь, чаще вылазят орлы, которые идею делать все просто доводят до полного маразма.
Тут есть другой момент — четкие функциональные требования бывают, только когда ты работаешь по контракту . Когда же работаешь напрямую с заказчиком софта, то требования как правило крайне нечеткие и по ходу дела уточняются не раз, отнюдь не только по инициативе разработчика. Кастомеру рабочие прототипы тоже позволяют лучше взглянуть на свои собственные потребности. И в этом нет ничего нового и удивительного. Надо только понимать, что в таких условиях ни о какой детерминированности модели или о существовании единственной серебряннопульной модели речи быть не может.

IT>Лучше уж изрекать банальности, но чётко знать о чём говоришь, чем смешать всё в кучу и рассуждать то ли о готовой системе, то ли о начале проектирования

Я ничего в кучу не смешивал, это ты смотришь на мой пост сильно в разрезе своих граблей. Заметь, о функциональных требованиях я ни слова не сказал, а ты о них через слово поминаешь. И я еще при этом виноват.

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

AVK>Действительно при чем? Видишь ли, в конечном итоге нужны не шашечки ввиде супер-пупер программы (если, конечно, мы не окоробке говорим), а ее работа и эффект от ее внедрения.

Да ты что? Приятно слышать. Растём, растём

AVK>Так вот, работать она будет именно в условиях готовой системы, а не в условиях системы, которая была на момент обследования. Этот простой факт я и хотел описать как обоснование недетерминистичности модели на начальном этапе проектирования.

И что дальше? Вывод какой?

IT>> До неё ещё дожить надо. А пока мы до неё доживём модель должна оставаться моделью и покорно следовать за предметной областью.

AVK>Видишь ли, в исходном топике не говорится ничего про сначала и потом. Не стоит уводить тему в сторону.

Именно по-этому ты говоришь и о том и о другом одновременно?

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

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

AVK>Вернемся к твоему примеру. Ты правильно заметил, что нефункциональные требования иногда переходят в функциональные. Но, скажем, зачастую то же требование перформанса не всегда можно заранее предсказать. Бывает, что проблемы вылазят по ходу проектирования или даже разработки. Некоторые это все списывают на безрукость архитекторов, но моя ИМХА, это то, что подобные ситуации фундаментальны, и надо не пытаться все и сразу удовлетворить в первом же прототипе модели.

Ну? И причём здесь модель? Ты описал процесс изучения предметной области, в течении которого корректировка функциональных/нефукнциональных требований неизбежна. Подкорректировали требования, привели в соответсвие модель, поехали дальше.

IT>> Только вот недостаточно не означает необязательно.

AVK>А я этого и не говорил. Я ж говорю — ты сам с собой сспоришь. Или, как вы с Владом любите говорить, борешься со своими фобиями. По мне так в своей области я последние года 3-4 с явлением overframeworked не сталкиваюсь,

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

AVK>чаще вылазят орлы, которые идею делать все просто доводят до полного маразма.

Идею делать всё просто довести до маразма нельзя по определению, т.к. слишком просто сделать нельзя. Можно сделать "слишком просто" (именно в кавычках). Но какое это имеет отношение к теме топика?

AVK>Тут есть другой момент — четкие функциональные требования бывают, только когда ты работаешь по контракту .

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

AVK>Я ничего в кучу не смешивал, это ты смотришь на мой пост сильно в разрезе своих граблей. Заметь, о функциональных требованиях я ни слова не сказал, а ты о них через слово поминаешь. И я еще при этом виноват.

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

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

AVK>>Так вот, работать она будет именно в условиях готовой системы, а не в условиях системы, которая была на момент обследования. Этот простой факт я и хотел описать как обоснование недетерминистичности модели на начальном этапе проектирования.

IT>И что дальше? Вывод какой?

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

AVK>>Видишь ли, в исходном топике не говорится ничего про сначала и потом. Не стоит уводить тему в сторону.

IT>Именно по-этому ты говоришь и о том и о другом одновременно?

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

IT>А моя главная мысль в том, что ты подменяешь понятие познание предметной области, понятием модели.

Нет, не подменяю. Я вобще о познании предметной области не говорю.

IT> Рекурсивный характер носит не модель, а процесс познания предметной области.

Прочти еще раз то, что я написал внимательно, а не выхватывая отдельные слова.

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

Зачем ты пытаешься ее до меня донести? Я не об этом вобще речь вел.

IT>Ну? И причём здесь модель?

При том, что разговор в этом топике был о модели.

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

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

IT>Проблема в том, что пока варишься в собственном соку собственного же приготовления, то этого не видно.

А я не варюсь в собственном соку, такое дело.

AVK>>чаще вылазят орлы, которые идею делать все просто доводят до полного маразма.

IT>Идею делать всё просто довести до маразма нельзя по определению,

Можно. И определение тут не при чем.

IT>т.к. слишком просто сделать нельзя.

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

IT> Можно сделать "слишком просто" (именно в кавычках). Но какое это имеет отношение к теме топика?

А какое отношение имеет к теме топика твои рассуждения о жутких программерах, которые пишут крутые фреймворки и не реализуют функциональных требований?

AVK>>Тут есть другой момент — четкие функциональные требования бывают, только когда ты работаешь по контракту .

IT>Гы-гы. Ты пробовал?

Да.

IT>Естественно поминаю. Функциональные требования — это формальное определение предметной области,

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

IT> по которой потом строится модель. Нет требований, нет связи между областью и моделью. Есть только пустое место и абстрактные разговоры о нём.

Видишь ли, топик начался с абстрактных разговоров. Хочешь поговорить о конкретике — нет проблем, заводи отдельный топик, поговорим. Только, сдается мне, спорить при этом окажется не о чем.

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


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

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

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

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

Вроде все сошлось
(прикольно так зашли с другой стороны к банальным вещам)

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

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

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


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

Да, именно так.

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

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

Модель — это представление знаний о предметной области. Модель появляется в результате изучения предметной области разработчиком модели.
Т.е. модель это форма, в которой разработчик фиксирует знания о предметной области.
В процессе построения модели в предметную область ничего не добавляется и модель не становится частью предметной области:
ведь разработчик модели только берет знания из предметной области, а добавить в нее ему пока нечего.
Разработчик в конечном итоге становится носителем (еще одним) знаний из предметной области или ее части.

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

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

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

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

V>А если попытаться слово "приоритет" заменить на "абстракция"?

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

Вот представь. Допустим мы с тобой начинаем вместе разрабатывать сайт для домохозяек. Я предлагаю кроме собственно веб интерфейса сделать ещё и оффлайн клиент, назовём его, к примеру, айтинус. Мне эта задача более интересна чем сам сайт. В процессе обсуждения я предлагаю использовать передовую технологию WCF, которая здорово подходит для айтинуса и вообще правильнее будет использовать её максимально широко, т.к. это даст нам такие и сякие преимущества перед конкурентами, в частности унифицированный интерфейс к серверной части приложения. Ты соглашаешься и пробуешь применить WCF для веб сайта. Со временем ты понимаешь, что для веб сайта эта технология является неудобной и громоздкой. Ты делишься своими соображениями со мной и тут, ВНИМАНИЕ!, я предлагаю вообще отказаться от веб морды в нашем приложении, ведь веб морда не главное в этой жизни, айтинус может всё это с успехом заменить

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

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

И хоть это всё и звучит банально, но эти ошибки делаются и делают их в том числе и те, кто обвиняет меня в банальности суждений.

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

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

V>В общем, блин, все-равно в человеческий фактор упираемся. Хренушки получится полностью формализовать алгоритм проектирования моделей в приемлимом для человека виде...

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

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


V>>А если попытаться слово "приоритет" заменить на "абстракция"?

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

И все же, я настаиваю. Далее попытаюсь обосновать. В любом месте просьба подразумевать, что приоритет расставлен так:
1. реализация целевых функциональных требований;
2. минимизация суммарных задействованных ресурсов;

От этого и пляшем.


IT>Что для нас важнее, функциональные требования или повышение абстракции, простота кода или быстродействие. Пользуясь приоритетами на все эти вопросы довольно просто дать однозначный ответ.

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

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

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


IT>Вот представь. Допустим мы с тобой начинаем вместе разрабатывать сайт для домохозяек. Я предлагаю кроме собственно веб интерфейса сделать ещё и оффлайн клиент, назовём его, к примеру, айтинус. Мне эта задача более интересна чем сам сайт. В процессе обсуждения я предлагаю использовать передовую технологию WCF, которая здорово подходит для айтинуса и вообще правильнее будет использовать её максимально широко, т.к. это даст нам такие и сякие преимущества перед конкурентами, в частности унифицированный интерфейс к серверной части приложения. Ты соглашаешься и пробуешь применить WCF для веб сайта. Со временем ты понимаешь, что для веб сайта эта технология является неудобной и громоздкой. Ты делишься своими соображениями со мной и тут, ВНИМАНИЕ!, я предлагаю вообще отказаться от веб морды в нашем приложении, ведь веб морда не главное в этой жизни, айтинус может всё это с успехом заменить

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

В данном случае подмена приоритетов означала отказ от выполнения базовых функциональных требований. Разумеется, клиника, и обсуждать нечего.


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

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

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

IT>И хоть это всё и звучит банально, но эти ошибки делаются и делают их в том числе и те, кто обвиняет меня в банальности суждений.

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


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

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

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


IT>Именно. Человеческий фактор стремится заниматься тем, что ему более интересно. А в случае просчётов старается до последнего не видеть своих ошибок и доказывать свою правоту.

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