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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

Здравствуйте!

Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой ОС. Причём не только русской, но и всего русскоговорящего населения? Присоеденились бы вы к такому проекту?

Прошу не относить к флейму. Речь идёт о уже существующем проекте.

С уважением,

VICH

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

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

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


Всего в теме 5452 сообщения



Отслеживать это обсуждение
<<<... | 2832—2823 | 2822—2813 | 2812—2803 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 264


№ 2822   14-09-2007 11:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Жуткое упрощенчество в изложении Паранджарова п.2-4. Так сказать, укрепление вертикали :)
Ну что это за принципы!
>>> Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов
Слава Аллаху!
А вот ограничение на “сочленение”, “выбор”, “повторение” замечательно.
Я бы даже пошёл дальше - ограничиться одним элементом: два входа - два выхода.
Три дейкстровских получаются как частные случаи коммутации
выходов, входов, входов и выходов соответственно.

Но что-то не вижу ограничения для линий коммутации. Где "нельзя пересекать"?
---
Смотрю я любителей разных моделей на каждый чих много. Эхе-хе. Традиция аддитивности.
Горькие плоды торжества линейных подходов в нашем нелинейном мире.

В русле единой модели идут ГИС программы, где коммуникации, здания и т.п. указываются совместно.
А "проектно-сметная документация" это хоть вещь жутко важная в нашем государстве победившей
бюрократии, но к практической инженерии имеет опосредованное отношение.
Затраты на все утряски стали уже превосходить собственно работы :(
---
Аргумент о том, что графика хороша лишь для пространственно распределённых задач
имеет под собой то основание, что здесь преимущества графики очевидны.
Однако, временные и логические последовательности также удобны для графического представления.
Именно из-за этого UML пал жертвой. Он превратился из универсального языка моделирования
в средство сопровождения проекта и контроля за его исполнением.
Менеджеры его используют, чтобы "пасти котов" за счёт их же непроизводительного труда.
Естественно, что к UML в среде программистов негатив полный.

Меня же интересует применение графики именно для моделирования. И, конечно, не везде и всюду.
Кроме блоков и линий-коннектов надо предусмотреть разъёмы и условия на вход выход,
что почти одно и то же.


№ 2821   14-09-2007 09:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2818« (Сергей Перовский)
___________________________

Ответ на »сообщение 2794« (Beginner)
___________________________
Мне очень понравилось высказывание академика Н. (приводилась недавно ссылка Р Богатырёвым) о том, что современное состояние дел похоже на Океанию, где освоены лишь небольшие островки. Задачи "в море" каждый за уши притягивает к своему островку, который он умеет решать.
Это нормально?
С точки зрения психологии нормально :(
Так уж устроен наш мозг.
А то, что это неэффективно, и требует преодоления, так это в ветку про научную методологию - проверка области применимости всех используемых методов и средств должна стать абсолютно естественной привычкой.
Дискуссия о интерфейсах растет из той же проблемы: "вот посмотрите, как с помощью этого представления быстро решаются мои задачи - значит будут решаться и ВСЕ остальные". С какой стати все?
Интерфейс аксесса более-менее удачно соответствует тем задачам, для которых аксесс предназначен. Почему из этого следует, что подобный интерфейс будет удобен во всех случаях?


Ну, зачем же так походя пинать хороший продукт, не Вами сделанный? Использованные в нем элементы интерфейса годятся для очень широкого круга задач, не ограниченного предназначением самого програмного продукта. Вы ведь не станете утверждать, что диалог Файл-Сохранить как... должен использоваться только в том программном продукте, в котором он изначально появился. Почему бы не заимствовать лучшие решения для того, чтобы решить похожие проблемы?


№ 2820   14-09-2007 08:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Цитируя Паронджарова...
Попытаемся еще раз заглянуть в темные переулки истории и внимательно перечитаем классический труд Дейкстры “Заметки по структурному программированию”. К немалому удивлению, мы обнаружим, что основной тезис о структурных управляющих конструкциях (для обозначения которых названный автор вводит термины “сочленение”, “выбор”, “повторение” [2]) излагается с прямой апелляцией к визуальному языку блок-схем! Непосредственный анализ первоисточника со всей очевидностью подтверждает: дейкстрианская “структурная революция” началась с того, что Дейкстра, использовав блок-схемы как инструмент анализа структуры программ, предложил наряду с другими важными идеями четыре принципа структуризации блок-схем, которые в дальнейшем были преданы забвению или получили иное, по нашему мнению, слишком вольное толкование. Эти принципы таковы.
1. Принцип ограничения топологии блок-схем. Структурная программа должна приводить “к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись ...тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине” [2].
2. Принцип вертикальной ориентации входов и выходов блок-схемы. Имея в виду шесть типовых блок-схем (if-do, if-then-else, case-of, while-do, repеat-until, а также “действие”), Дейкстра пишет: “Общее свойство всех этих блок-схем состоит в том, что у каждой из них один вход сверху и один выход снизу” [2].
3. Принцип единой вертикали. Вход и выход каждой типовой блок-схемы должны лежать на одной вертикали.
4. Принцип нанизывания типовых блок-схем на единую вертикаль. При последовательном соединении типовые блок-схемы следует соединять, не допуская изломов соединительных линий, чтобы выход верхней и вход нижней блок-схемы лежали на одной вертикали.
Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов, они однозначно вытекают из имеющихся в его работе иллюстраций [2]. Чтобы у читателя не осталось сомнений, мы приводим точные копии подлинных рисунков Дейкстры (рис. 131, средняя и левая графа)1.


№ 2819   14-09-2007 08:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2811« (Beginner)
___________________________

Ответ на »сообщение 2809« (Beginner)
___________________________
Я чётко понимаю, что специализированные модели (той же принципиальной схемы сигнализации) делать легче, проще, а потому как бы правильнее. Но при этом теряется слишком многое - учёт взаимного влияния, материальность моделируемого объекта, практичность модели.

Контрольный вопрос по курсу имитационного моделирования:
какие типы объектов нужно описать для создания модели аэропорта?
Наиболее распостраненные ответы: самолеты, пассажиры, кассы, багаж...
Правильный ответ: а какие задачи нужно решать при помощи этой модели?

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


№ 2818   14-09-2007 08:13 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2794« (Beginner)
___________________________
Мне очень понравилось высказывание академика Н. (приводилась недавно ссылка Р Богатырёвым) о том, что современное состояние дел похоже на Океанию, где освоены лишь небольшие островки. Задачи "в море" каждый за уши притягивает к своему островку, который он умеет решать.
Это нормально?

С точки зрения психологии нормально :(
Так уж устроен наш мозг.
А то, что это неэффективно, и требует преодоления, так это в ветку про научную методологию - проверка области применимости всех используемых методов и средств должна стать абсолютно естественной привычкой.
Дискуссия о интерфейсах растет из той же проблемы: "вот посмотрите, как с помощью этого представления быстро решаются мои задачи - значит будут решаться и ВСЕ остальные". С какой стати все?
Интерфейс аксесса более-менее удачно соответствует тем задачам, для которых аксесс предназначен. Почему из этого следует, что подобный интерфейс будет удобен во всех случаях?


№ 2817   14-09-2007 08:11 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2809« (Beginner)
___________________________

Бывает повторное использование кода, а я о повторном использовании модели. Я думал, что модель объекта едина. Все инженерные коммуникации проводятся в тех же стенах.

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

Почитайте СНиП 11-01-95 "Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений" -- http://www.vashdom.ru/snip/1101-95/
Можете попробовать отобразить это на то, как в итоге может быть воплощено в промышленном программировании.


№ 2816   14-09-2007 07:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2806« (Илья Ермаков)
___________________________
>>>Мое сообщение 2778 - о том, что Дейкстра сформулировал принципы структурного программирования именно для блок-схем.

В какой работе?


№ 2815   14-09-2007 07:38 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2813« (Beginner)
___________________________

Ответ на »сообщение 2811« (Beginner)
___________________________
учёт взаимного влияния

Было такое - наложили схему теплотрасс на схему трамвайных путей и силовой проводки и выяснили, что блуждающие токи ускоряют коррозию на порядок. Под влиянием путей подразумевали тряску и соответсвенно сторожились её. А надо было делать спецзазамление и электроизоляцию.

Подобные случаи и есть естественное применение графики. Когда показывется нечто физически-пространственное, то тут и говорить не о чем.
А вот когда пытаемся рисовать нечто "эфемерное", как программная система или многомерные топологии на кристалле - вот тут-то и начинается самое интересное :-) Я не говорю, что это невозможно, но подобрать адекватное граф. представление сложнее на порядок. Из 10 предложенных представлений все 9 точно пойдут в корзину... А чтобы туда не пошло 10-е, оно должно быть не от балды придумано, а долго и упорно взращено из практики.


№ 2814   14-09-2007 07:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Удивительно, но объёмная схема лучше воспринимается, когда она ещё и крутится.
В случае статики объем лучше передавать градациями серого, а не спектром, хотя цвет более информативен.


№ 2813   14-09-2007 07:03 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2811« (Beginner)
___________________________
учёт взаимного влияния

Было такое - наложили схему теплотрасс на схему трамвайных путей и силовой проводки и выяснили, что блуждающие токи ускоряют коррозию на порядок. Под влиянием путей подразумевали тряску и соответсвенно сторожились её. А надо было делать спецзазамление и электроизоляцию.


<<<... | 2832—2823 | 2822—2813 | 2812—2803 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 264




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

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

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

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

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