Здравствуйте, 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-ля. Мы используем готовые окружения, сетевые протоколы и даже эти, как их, парадигмы, со всеми их мощными наработками и необсуждаемыми в рамках конкретного проектика ранее подтвержденными бенефитами. В такой ситуации нефункциональные требования могут вдруг возникать весьма резко и быть при этом связаны лишь очень коссвено с функциональными, и вообще возможна ситуация, когда на каком-то шаге итерации всю модель придется отправить фтопку, по причине обнаружения некоего кол-ва нефункциональных требований, несовместимых с жизнью текущей модели... И тут как всегда первую скрипку начинает играть многострадальный опыт проектировщика, его техническая эрудиция, умение хотя бы мысленно поставить телегу впереди лошади с целью предварительно просчитать варианты и т.д...

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