Ответ на »сообщение 4078« (ASU)
___________________________

Если Вам так интересно, то почитайте работы на эту тему, или подумайте на предмет того, почему у слесаря 5 разряда тариф выше, чем, например, у слесаря 2 разряда...

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

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

Ответ на »сообщение 4082« (Руслан Богатырев)
___________________________
На самом деле имеем три системы
«Коль пошла такая пьянка»... то не три, а пять, но не систем, а моделей! (Кто больше!!!) :) анализ – проект – план – реализация – эксплуатация.

Так о каких системах мы дальше будем рассуждать? Давайте все же определяться.
О любых...

Ответ на »сообщение 4081« (AVC)
___________________________
А интерфейс "вагончик--рельсы" тот же самый, что и "вагончик--вагончик"?
Или это ошибка проектирования?
Угу... Б_А_Г_А! :)

Ответ на »сообщение 4063« (ASU)
___________________________

Ответ на »сообщение 4025« (MS)
___________________________
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...
Насколько принципиально наличие в этом ряду библиотек и объектов? И именно в этих местах?
см. http://www.alexus.ru/russian/articles.htm

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

Что в приведённой последовательности предсталяет из себя библиотека? Это некий скомпилированный файл, содержащий набор процедур?

Ответ на »сообщение 4077« (ASU)
___________________________

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

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

На самом деле имеем три системы: система-замысел (уровень формулировки требований), система-проект (уровень методологии), система-реализация (уровень языка программирования). Они допускают вариативность на каждом из трех уровней: 1. Можно менять замысел, поскольку формулировка требований -- процесс, в который вовлечены, как минимум, две стороны -- заказчик и исполнитель; он может предусматривать предпроектные изыскания и принятие решений на уровне фиксации/конкретизации тех или иных требований.
2. Можно менять методологию (и отображение замысла на понятийный аппарат методологии).
3. Можно менять отображение проект в формулировке методологии на язык реализации.

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

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

Так о каких системах мы дальше будем рассуждать? Давайте все же определяться.

Ответ на »сообщение 4074« (ASU)
___________________________

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

А интерфейс "вагончик--рельсы" тот же самый, что и "вагончик--вагончик"?
Или это ошибка проектирования?

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

Вот где-то здесь мы и расходимся.
Значит, надо на таких пунктах и концентрироваться.

>>>А Вы что же -- тянете нас в каменный век? ;)
Строго наоборот... Именно к сборке я Вас и тяну... Посмотрите мои сообщения, с самого начала говорилось о том, что система должна конструироваться (собираться). Но это иной процесс, отличный от программирования и не разумно его выполнять из 3GL, нужен специализированный инструмент. Но не менее неразумно развивать 3GL в направлении конструирования систем... ничего хорошо из не может получиться.

Это действительно интересно.

Ответ на »сообщение 4057« (info21)
___________________________
>>>Нет никакой проблемы. И отдельных интерфейсов не нужно.
Нужно - не нужно, вопрос удобства.
Разумеется, вместо интерфейсов можно использовать "пустые" модули.
Вот только удобно ли это. На мой взгляд, разработка интерфейсов и их реализации достаточно сильно отличаются, чтобы не смешивать эти сущности в одной синтасической конструкции.

Ответ на »сообщение 4056« (Руслан Богатырев)
___________________________
>>>Я понимаю Ваше предубеждение в отношении работ Вирта по Оберону, якобы он шел по пути облегчения работы/структуры компилятора.
Кто хоть раз разрабатывал компилятор не может не смотреть на язык с этой точки зрения :)
Чем больше знакомлюсь с Обероном, тем сильнее ощущение, что с синтаксическим минимализмом случился перебор. Но это, конечно, субъективно.

Ответ на »сообщение 4076« (Руслан Богатырев)
___________________________
Проста, говорите? Мне это нужно комментировать? Ok.
Да, нет... Необязательно было комментировать... Понимаете, при нормировании используются не только чистое время, но и различные коэффициенты. Если Вам так интересно, то почитайте работы на эту тему, или подумайте на предмет того, почему у слесаря 5 разряда тариф выше, чем, например, у слесаря 2 разряда... Вы уж простите, что я не всю теорию нормирования и расчета трудозатрат рассказываю... Кстати, в исследованиях того же Тейлора было много поучительных моментов...

Ответ на »сообщение 4075« (Руслан Богатырев)
___________________________
Здесь уже обсуждали пример олимпиадной задачки с последнего чемпионата мира ACM по программированию. Она была решена (вариант на КП) в виде программы (одного модуля). Однако при этом выяснилось, что половину текста загромождает ввод-вывод и работа со строками. Я предложил вынести это со "сцены" в отдельный модуль. Простейшая декомпозиция. Перестала она после этого быть программой? Превратилась в систему? Если мы вынесем в модули еще некую специфику (передав на "аутсорсинг", на субподряд некий функционал), это станет системой?
Вы правильно рассуждаете... эволюционно, так сказать... накапливая количественные изменения... до качественного перехода. В какой-то момент наступит осознание того, что частями программы надо как-то управлять, и это управление к самим частям прямого отношения не имеет. Посмотрите на свой же пример с другой стороны. Есть некий «решатель» и есть некий «вывод», а система ими управляет. Если надо подключить новую часть (модуль, программу...), то не надо ничего менять во всех предыдущих частях, надо только слегка изменить логику управления и... все. Как в простейшем случае можно представить эту логику управления? AVC совершенно справедливо это отметил, например, как командная строка в UNIX, которая связывает выход одной программы со входом другой программы... Это простейший вариант, но... наглядный.

Компилятор -- вроде бы система (а что же еще?), но может быть реализована в виде монолитной программы, а может -- в виде набора модулей или даже совокупности взаимодействующих компонентов/объектов. Так когда же она из не-системы превращается в систему?
Да, конечно... Вы же не думаете, что системы рождаются из ничего...

Ваши комментарии?
См. выше...