Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  21:27[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4006—3997 | 3996—3987 | 3986—3977 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 227


№ 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 Ответить на это сообщение Ответить на это сообщение с цитированием
Как все же мы любим применять инсрументы не по назначению.:-)
Складки задумывались как средство литературного программирования. (http://www.ssw.uni-linz.ac.at/Research/Projects/ActiveTexts.html)
А для организации версий есть селекторы, которыми можно управлять и в "пакетном режиме".


№ 3987   16-04-2007 23:15 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3968« (AVC)
___________________________
Не так уж плохо иногда отвлечься от деталей и посмотреть на общую, панорамную картину.
Да, конечно.

Примерно такую встряску устроил нам ASU, и полагаю, что из этого можно извлечь некоторую пользу.
Хотелось бы...

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

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

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

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

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

Отметьте, что Ваш и «мой» вопросы принципиально отличаются!..

Второй вопрос: как должен решаться конфликт имен? Или программист должен отслеживать все имена в системе, чтобы избежать ошибок?
Нет... Все гораздо... проще... на несколько порядков...

Во всех языках, рассчитанных на создание крупных программных систем, для решения этой проблемы были введены специальные механизмы. В тех языках, где нет явных модулей, были введены пространства имен (например, в C++ и C#). Но ASU не говорит ни слова об этих мезанизмах.
В силу их бесполезности...

У меня также создалось впечатление (вероятно, ошибочное), что ASU отрицает иерархическое устройство систем (это было бы очень странно). Мол, части системы взаимодействуют, ничего не зная друг о друге, без всякого иерархического соподчинения.
Это ошибочное суждение. Любая система иерархична... по определению.

Да, такое может быть, но только если о взаимодействии этих двух несведующих частей системы позаботилась третья, более осведомленная.
Правильно... позаботиться должна система... (та самая третья «сила»).

Поэтому я считаю, что сам вопрос, поднятый ASU, возник вследствие недоразумения, но обсуждение этого вопроса вполне может оказаться полезным, устраняя подобные недоразумения.
Недоразумения?.. Хм... Если и есть какое-то недоразумение, то оно порождено не вопросом, а восприятием... IMHO... :)


<<<... | 4006—3997 | 3996—3987 | 3986—3977 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 227


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

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

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования