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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4096—4087 | 4086—4077 | 4076—4067 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 218


№ 4086   18-04-2007 04:59 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4078« (ASU)
___________________________

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

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

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


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

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


№ 4084   18-04-2007 04:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4081« (AVC)
___________________________
А интерфейс "вагончик--рельсы" тот же самый, что и "вагончик--вагончик"?
Или это ошибка проектирования?

Угу... Б_А_Г_А! :)


№ 4083   18-04-2007 04:47 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4063« (ASU)
___________________________

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


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

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


№ 4082   18-04-2007 04:42 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4077« (ASU)
___________________________

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

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

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

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

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

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


№ 4081   18-04-2007 04:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4074« (ASU)
___________________________

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


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

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


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

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


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


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


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


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


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

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

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


<<<... | 4096—4087 | 4086—4077 | 4076—4067 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 218


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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