Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 3996 17-04-2007 03:07 | |
Ответ на »сообщение 3992« (ASU)
___________________________
Любая система имеет иерархическое строение, поскольку состоит из элементов (которые сами могут быть системами).
Это лишь один из возможных подходов. Существуют системы, не имеющие иерархического строения. И существуют подходы, не исходящие из обязательности такого свойства систем, как иерархичность.
Для того, чтобы элементы двух смежных (и только смежных!) уровней могли взаимодействовать им необходимо знать о соглашениях и придерживаться определенного протокола – суть интерфейсов.
Между интерфейсом и протоколом существует существенное различие. Протокол определяет порядок/логику взаимодействия объектов (сущностей), который может предусматривать наличие соответствующего синтаксиса и семантики (с учетом изменения состояний, как локальных, так и нелокальных). Тогда как интерфейс -- преимущественно совокупность поименованных сущностей и их внешних атрибутов.
Подавляющее большинство так называемых программных интерфейсов (между программными сущностями, а не между человеком и программой/компьютером) специфицируют с той или иной точностью атрибуты/свойства сущностей (имена, типы, способы/режимы передачи параметров и т.п.), но не то, как (в какой последовательности или асинхронной причинно-следственной зависимости) можно применять эти сущности.
Приведу пример. У нас имеется некий файл a.txt, подлежащий сжатию (упаковке), и есть модуль File, в котором объявлена соответствующая процедура Pack. Модуль File экспортирует (через свой интерфейс) такие сущности, как тип T (абстрактный тип данных, обозначающий понятие "файл"), процедуры Open, Close, Pack.
Нормальный (предусматриваемый разработчиком интерфейса, равно как и разработчиком модуля) порядок выглядит так:
VAR f: File.T;
...
BEGIN
File.Open(f, "a.txt");
File.Pack(f);
File.Close(f)
END MyProc;
Казалось бы, все понятно. Но простите, а кто определил, что Open надо вызывать до Pack и до Close? Мы до этого додумываемся по названию? А если автор интерфейса даст другие названия? Если логика взаимодействия будет сложнее? По документации? А кто контролирует ее соблюдение? Т.е. протокол витает где-то в воздухе и мы должны до него додумываться (когда нет адекватной документации и доступа к исходным текстам)?
В отношении программной системы можно выделять слои/уровни, элементы/компоненты. Но можно и не выделять. Все зависит от подхода. Убежденность в том, что система -- это обязательно иерархическая структура, состоящая из элементов -- заблуждение. Это самый привычный и известный подход к трактовке понятия системы. Но не единственный. И не единственно полезный.
Тем не менее, не прозвучало ничего, что противоречило бы подходам, принятым в Обероне (давайте для определенности зафиксируем язык и не будем привлекать в рассуждения КП). О том, как это происходило в Модуле-2 и как существует в отношении Оберона, я уже ранее довольно подробно пояснял.
Имеет смысл также понимать, что интерфейсы (межуровневые, межэлементные) той или иной реализуемой системы не обязаны отображаться один в один на интерфейсы Оберон-модулей, которые во избежание терминологической путаницы предлагаю называть спецификациями модулей (DEFINITION).
Был выдвинут тезис: квалифицирующий импорт языка Оберон противоречит системности. После всех многичисленных преамбул и недомолвок осталось дождаться четкой аргументации этого тезиса.
№ 3995 17-04-2007 03:06 | |
Ответ на »сообщение 3988« (Trurl)
___________________________
А для организации версий есть селекторы, которыми можно управлять и в "пакетном режиме".
Хм... В смысле "селекторы"?
№ 3994 17-04-2007 02:56 | |
Ответ на »сообщение 3993« (MS)
___________________________
ИМХО это дерево наследования.
Агрегация...
№ 3993 17-04-2007 02:52 | |
Ответ на »сообщение 3992« (ASU)
___________________________
Кратко о поддержке интерфейсов со стороны системы.
Система имеет три части (ипостаси). Первая часть отвечает за разработку и модификацию, вторая часть за настройку и сопровождение, третья часть за работу в своей предметной области. Списки интерфейсы «сужаются» в том же направлении. Наиболее «представительный» список интерфейсов имеет часть разработки, наименее полон список интерфейсов в части использования.
Каждый элемент какого-либо из уровней может обращаться только к своему агрегату, он ничего не должен знать ни о системных службах, ни о смежных элементах. Соответственно, интерфейсы системных служб дополняют межуровневые интерфейсы, так, как будто они принадлежат агрегату. И агрегат имеет возможность перехватывать обращения своих элементов.
В остальном придерживаются строгого правила: интерфейсы локализованы между двумя уровнями. Поэтому не происходит никакой путаницы с именами и не требуется вводить дополнительные правила, поддерживающие пространства имен. Данное требование должно быть «известно» и средствам трансляции, и средствам загрузки, и средствам коммутации.
ИМХО это дерево наследования.
№ 3992 17-04-2007 01:20 | |
Любая система имеет иерархическое строение, поскольку состоит из элементов (которые сами могут быть системами). Или, говоря иначе, любой «вышестоящий» элемент системы агрегирует (инкапсулирует - содержит и сокрывает) в себе элементы нижележащего уровня. Для того, чтобы элементы двух смежных (и только смежных!) уровней могли взаимодействовать им необходимо знать о соглашениях и придерживаться определенного протокола – суть интерфейсов.
Что следует из этого краткого описания? То, что понятие интерфейса появляется в момент разделения (декомпозиции) системы по уровням. Это еще даже не проектное решение, это решение которое создается на стадии анализа и моделирования. Таким образом, интерфейс создается задолго до появления какого бы то ни было программного модуля. Это первое.
Второе. Создании программных элементов происходит в несколько этапов, и на каждом из этапов программный элемент обязан иметь строгое соответствие интерфейсу. Первый этап разработка прототипа. Прототип – это упрощенная реализация (в предельном случае - «заглушка»), поддерживающая декларированный (на стадии анализа и моделирования) интерфейс. Второй этап – разработка опытного экземпляра. Опытный экземпляр имеет полную, но не оптимизированную (и, возможно, не тестированную) реализацию. Третий этап – разработка рабочего варианта. Последующие варианты связаны с разработкой различных модификаций. Появление и развитие модификаций должно анализироваться, поскольку является одним из источников развития интерфейсов. Таким образом, множественность реализаций интерфейсов – это совершенно нормальное явление, в частности, отражающее развитие системы.
Третье. В отличие от реализаций элементов, интерфейсы обязаны быть устойчивыми и неизменными в течении всего жизненного цикла системы. Изменение интерфейсов связана с глубокими переделками и, фактически, означает появление модифицированной или совершенно новой системы. Собственно, понимание семантики системы в целом и каждого ее уровня в отдельности – единственное решение, позволяющие выполнить это требование. Можно с определенной долей осторожности допустить развитие интерфейсов, но не их изменение или удаление. При этом реализации могут меняться постоянно, позволяя улучшать характеристики системы в общем и для отдельно взятых условий (состояний).
Кратко о поддержке интерфейсов со стороны системы.
Система имеет три части (ипостаси). Первая часть отвечает за разработку и модификацию, вторая часть за настройку и сопровождение, третья часть за работу в своей предметной области. Списки интерфейсы «сужаются» в том же направлении. Наиболее «представительный» список интерфейсов имеет часть разработки, наименее полон список интерфейсов в части использования.
Каждый элемент какого-либо из уровней может обращаться только к своему агрегату, он ничего не должен знать ни о системных службах, ни о смежных элементах. Соответственно, интерфейсы системных служб дополняют межуровневые интерфейсы, так, как будто они принадлежат агрегату. И агрегат имеет возможность перехватывать обращения своих элементов.
В остальном придерживаются строгого правила: интерфейсы локализованы между двумя уровнями. Поэтому не происходит никакой путаницы с именами и не требуется вводить дополнительные правила, поддерживающие пространства имен. Данное требование должно быть «известно» и средствам трансляции, и средствам загрузки, и средствам коммутации.
№ 3991 17-04-2007 00:54 | |
Ответ на »сообщение 3983« (Сергей Перовский)
___________________________
>>>Все виды модульности в Обероне слиты в один
Это верно, если говорить об Оберон-системе. Но в компиляторах Оберона, сделанных в "традиционном" стиле, модули используются тоже в традиционном стиле - как едиицы компиляции.
С другой стороны, отождествление единицы компиляции и единицы загрузки не уникально для Оберона. В той же VM/CMS на IBM/370 любая единица компиляции (даже на Фортране) была единицей загрузки.
№ 3990 17-04-2007 00:41 | |
Ответ на »сообщение 3989« (Trurl)
___________________________
Хотя, возможно, более правильно поставить вопрос "интерфейс между чем и чем?".
Как Вы думаете, решение Вирта назвать развернутую спецификацию экспортируемых сущностей DEFINITION (Модула-2, Оберон), а не INTERFACE (Modula-3) не может ли быть связано с глубоким пониманием разницы между спецификацией свойств и объектов абстрагируемой сущности (модуля) и интерфейсом (который, как верно заметили, устанавливается между двумя и более субъектами/объектами)?
№ 3989 17-04-2007 00:24 | |
Ответ на »сообщение 3965« (AVC)
___________________________
>>>Честно говоря, я не очень представляю, как можно говорить об интерфейсе без модуля.
>>>Интерфейс чего?
Процедуры, типа, объекта...
Хотя, возможно, более правильно поставить вопрос "интерфейс между чем и чем?".
№ 3988 17-04-2007 00:10 | |
№ 3987 16-04-2007 23:15 | |
Ответ на »сообщение 3968« (AVC)
___________________________
Не так уж плохо иногда отвлечься от деталей и посмотреть на общую, панорамную картину.
Да, конечно.
Примерно такую встряску устроил нам ASU, и полагаю, что из этого можно извлечь некоторую пользу.
Хотелось бы...
Выяснилось, что о самых простых (фундаментальных) предметах мы думаем (или, по крайней мере, говорим) по-разному.
... все же правильнее... «думаем по разному»...
Александр Сергеевич (ASU) полагает, что квалифицирующий импорт противоречит "слабости" межмодульных связей. Какие, мол, "слабые" связи, если явно указано имя модуля.
Теперь у меня в этом нет ни малейшего сомнения...
Сергей Перовский высказал предположение, что за этой точкой зрения стоит не только абстрактная теория систем, но и некоторая программная реальность, например технология COM.
COM – это паллиатив... Давайте не заслонять концепцию ее реализацией (это к добру и взаимопониманию не приводит).
Возможно, это и так, хотя я скорее усматриваю тут влияние UNIX: отдельные программы-модули работают как фильтры, а в целое (систему) они соединяются с помощью командных скриптов оболочки. В общем, у каждого могут быть здесь свои фантазии. :)
Очень правильное понимание, хотя это очень старая и примитивная (я бы сказал интуитивная) реализация. Но даже в таком варианте, это было удобно и полезно... Можно вспомнить и JCL... :)
Попробуем рассмотреть аргумент Александра Сергеевича по существу.
Обероновскому подходу (с квалифицирующим импортом) он противопоставляет некие непривязанные к модулям интерфейсы. Сразу возникает вопрос чьи это интерфейсы? (Сам ASU спросил бы -- между чем/кем эти интерфейсы?)
Отметьте, что Ваш и «мой» вопросы принципиально отличаются!..
Второй вопрос: как должен решаться конфликт имен? Или программист должен отслеживать все имена в системе, чтобы избежать ошибок?
Нет... Все гораздо... проще... на несколько порядков...
Во всех языках, рассчитанных на создание крупных программных систем, для решения этой проблемы были введены специальные механизмы. В тех языках, где нет явных модулей, были введены пространства имен (например, в C++ и C#). Но ASU не говорит ни слова об этих мезанизмах.
В силу их бесполезности...
У меня также создалось впечатление (вероятно, ошибочное), что ASU отрицает иерархическое устройство систем (это было бы очень странно). Мол, части системы взаимодействуют, ничего не зная друг о друге, без всякого иерархического соподчинения.
Это ошибочное суждение. Любая система иерархична... по определению.
Да, такое может быть, но только если о взаимодействии этих двух несведующих частей системы позаботилась третья, более осведомленная.
Правильно... позаботиться должна система... (та самая третья «сила»).
Поэтому я считаю, что сам вопрос, поднятый ASU, возник вследствие недоразумения, но обсуждение этого вопроса вполне может оказаться полезным, устраняя подобные недоразумения.
Недоразумения?.. Хм... Если и есть какое-то недоразумение, то оно порождено не вопросом, а восприятием... IMHO... :)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|